11 Replies Latest reply on Mar 6, 2014 7:20 AM by helic_263931

    Unable to maintain two timer's in Sync


      Hi All,


      I am using two timers T1 and T2 with below configuration, I intend to configure them dynamically at different frequency, However to test i configured them both to generate an interrupt every 500usec.


      T1 -> TC interrupt - Every 500 usec (Input clock - 10 MHz) UDB                                                                                                           T2 -> TC interrupt - Every 500 usec (Input clock - 10 MHz) UDB  


      Timer's are enabled simultaneously(T1 followed by T2), and corresponding digital port's are toggled inside ISR's to measure the timing on scope. I made two observations here


      1) Port 2(T2) is toggled with a delay of 7.8 usec w.r.t Port 1(T1)


      2) Port 1/2 o/p repetition period - 500 ~2 ( plus minus 2 )


      This timing is very crucial for my implementation. I am unable to achieve a consistent delay pattern. I have tried modifying timer 1 counter to compensate for initial delay as mentioned in point (1) above without any success.


      Is there any other way to achieve it, I am struggling with multiple timer's. Can someone suggest an improvement or an alternative way to achieve it.


      I am new new to PSoc and still learning ways to work with it. Any help is highly appreciated. Thanks

        • 1. Re: Unable to maintain two timer's in Sync

          You are measuring two delays here:

          • first, when the two timers are started by your code, there will be a small delay between them (the time needed to execute the _Start() call)
          • second, you measure the time your ISR takes to execute. Remember, only one can be active at any time, so when you are about to set P1 high, you cannot handle P2 at the same time

          So if you want to do stuff with critical timing, do it in hardware. Just route the output pin from the time to your digital output pin.

          • 2. Re: Unable to maintain two timer's in Sync

            There are some different properties you have to consider:


            1st  The frequency of the Internal Main Oscillator (IMO). The precision is given in the datasheet and can be improved by using an external oscillator.


            2nd: the synchronous start of the two timers which cannot be archieved in software directly but may induced by a control-register.


            3rd: The response-time to the interrups which is not zero and the priority each interrupt has got may prevent (for a short time) the handling of the second interrupt. Better will be to connect the outputs of the timer (TC or Interrupt) directly to a pin to prove the stability of the timers.


            4th: The time spent in the interrupt handler can spoil some of your required stability and synchronization. Again I would suggest you to put most of your progect into hardware.




            When you tell us a bit more what you try to perform we probably could give you some advices.





            • 3. Re: Unable to maintain two timer's in Sync

              Hello hli, nice to see that you agree with me, I mage my post while you entered yours





              • 4. Re: Unable to maintain two timer's in Sync

                Yeah, I just managed to come up with a condensed version of what you wrote :)

                • 5. Re: Unable to maintain two timer's in Sync

                  Thanks @hli and @Bob Marlowe for your comments,  I did expected the delay as only one will be active at a time, But I was trying to achieve some sort of consistancy here.


                  Let me explain the project :  I am working towards establishing a PSI5 protocol. I want to handle two sensors with minimum latency using single micro. PSI5 => Data packets to be sent out at desired frequency and in a specific time slot. Say period is 500 us, 250 or anything less than 500 us. Data latency limit is 2.1 us, and I am way off that tolerance level.


                  As correctly mentioned above, ISR execution time is spoiling the required stability. ISR execution time currently is quite high, close to 8us. I am thinking that I'll just set Flags in the ISR and process these flags in seperate timer.


                  Is timer block the only way for performing periodic tasks ?

                  • 6. Re: Unable to maintain two timer's in Sync

                    There is a SysTick timer inherent to ARM m3, but this can only be handled with an interrupt, and is not able to get connected to an internal signal.


                    Since we do not know whether your design will allow for that (although it can be MADE to), did you already consider using DMA for data transfer which will run in hardware, no interrupt needed, no CPU needed, just setup and fire...


                    So, what does your direct interface look like? what data do you need to transfer?? what is the datarate???





                    • 7. Re: Unable to maintain two timer's in Sync

                      I initially did considered DMA, But it doesn't help the cause for following reasons.


                      I am using SPIM block to transmit manchester encoded data, and this data has to be sent every 500us. Lets say I trigger the DMA using a clock at desired freq. I have to Tx a huge chunk of data(10 K bytes for instance). Each data is 16 bits.


                      Burst -2bytes per request , TD chaining => TD 0-  load 2bytes in SPI FIFO. Now i don't have enough resources to load 10 K of data, SO i need to implement rolling buffer or else 2 buffers( 1 being loaded and second being used for TX) . I am unable to achieve it via DMA. ( Moreover two such devices means double the RAM, i'll run short of RAM).


                      Moreover 16 bit DMA transfer to SPIM FIFO induce more complexity, The data o/p need to be formatted.

                      • 8. Re: Unable to maintain two timer's in Sync

                        Thanks Marlowe,


                        I fogot to mention data rate - 125 KHz / 189 Khz (configurable option)

                        • 9. Re: Unable to maintain two timer's in Sync

                          if I understand you right the SPIM is the limiting function within your system. there is no need to collect data faster than you can send them. So to have room for your tight timing it seems best to collect a new set of data while the actual one is transmitted. maintaining a short(!!!) circular buffer could be of some help, alarge buffer (10K as you suggested) does not improve the performance when you continuously send the collected data.


                          SPIM data (as you already did) should be transmitted using DMA and of course you may use two (small) buffers.


                          You did not tell where your transmitted data is generated from, SAR? ADC?? Other sensors??? Does the data collection use (much) CPU MIPS?





                          • 10. Re: Unable to maintain two timer's in Sync

                            Data to be transmitted is read from SD card using emfile component, I am yet to work on this part. I am in initial phase of the project. So I need to read data from SD card and push it to the buffers. I'll work it out in coming days and update you on this. I am hoping that i'll be able to meet the timings somehow.


                            Thanks for your valuable suggestions, I gotta work on this DMA stuff extensively.

                            • 11. Re: Unable to maintain two timer's in Sync

                              If you collect data faster than you can transmit consider averaging as it


                              increases effective resolution, reduces noise contribution. Oversampling


                              does have its benefits.




                              Regards, Dana.

                              • 12. Re: Unable to maintain two timer's in Sync

                                Look at the AppNotes for DMA: http://www.cypress.com/?rID=37793 , http://www.cypress.com/?docID=44514 and http://www.cypress.com/?rID=44335 . What you need is called "ping-pong DMA", Basically its that the DMA automatically switches between two buffers (in the DMA intro, its chapter 5 and called TD chaining).




                                That way you just need the notification about the switch, to fill the unused buffer with new data. The buffers can be small (e.g. 512 bytes == 256 words).




                                Does your SPI need to assert the SS signal for each word separately? The SPI component can do that automatically, so you might get away with 8 bit transfers.