3 Replies Latest reply on Dec 18, 2018 12:21 AM by ScDe_1334511

    Timer, configuration / API problem for pulse to pulse time of quadrature signal.


      Hi, I'm a novice PSoC 3, PSoC Creator user & C programmer (a 'gear head', electronics guy, as it were) and am having trouble configuring a Timer component to do what I believe is one of the functions for which it's designed, namely, measuring the time between rising edges of a pulse train (in this case, SIN of a Quadrature encoded sensor). I suspect I'm just missing something in Cypress documentation. The pulse train is coming from a quadrature encoded sensor on a rotating shaft at 0-300 RPM (one pulse of SIN per revolution). With this maximum speed, the pulse to pulse time can vary from near infinity (0 RPM) down to  about 200mSec. I chose a 16bit Timer running continuously and clocked at 100Hz to provide nearly 11 minutes before a TC. The plan being that the Timer would be started and the first capture would cause an initial interrupt. This first interrupt would provide a 'bogus' count (time) that would be 'counter_read' in the ISR to a variable. Each successive capture thereafter would be the time to the next pulse (rising edge). In the ISR, the intent was to reset the Counter running count to FFFF after each read to allow for a TC to produce 'zero' RPM after the ~11 minutes as well as avoid having to deal with the wrap around at counter=zero producing negative numbers.  The only 'reset' of the counter I'm seeing is to '_INIT' and then '_START'. Thusly:

          CY_ISR(Sens0_Timer_interrupt_Handler)           // Macro ISR declaration, interrupts on TC and Capture


              Flag_Timer_Sen0=Timer_Sens0_ReadCounter();  // Sets Flag to the capture value of the timer;

              Timer_Sens0_Init();                                                 // Resets counter to hardware initial state (0xFFFF)

              Timer_Sens0_Start();                                              // Restarts Timer

              k=Timer_Sens0_ReadStatusRegister();         // Clears interrupt (according to Timer datasheet and AN54460)


      The problem comes in that '_Init' and '_Start' behave differently for a FF or UDB implementation and without a reset of the counter, 11 minutes comes every 11 minutes regardless of current RPM.

      Any solutions out there that someone would be willing to share?


      Scott DeBruyn

      Dutchman Electronics LLC

        • 1. Re: Timer, configuration / API problem for pulse to pulse time of quadrature signal.

          Can you please post your complete project so that we all can have a look at all of your settings. To do so, use

          Creator->File->Create Workspace Bundle (minimal)

          and attach the resulting file.


          Another solution would  be to use a counter component, UDB based for which you can select automatic reload at capture or TC.



          • 2. Re: Timer, configuration / API problem for pulse to pulse time of quadrature signal.

            user_1377889 <https://community.cypress.com/people/user_1377889?et=watches.email.thread> ,




                           Thanks for getting back to me. The settings aren't really the problem, it's the missing ability to reset the counter in the timer upon capture. The obvious solution would be to, set the counter to the period, start the counter (or have it running continuously), capture the counter contents upon an event and be able to reset the counter to the period, to allow the start of timing to the next event (rising edge, in this case). There doesn't seem to be any smooth way to do that. One can capture and save a 'last', then capture the next event and do the math to find the difference as you would do here between the period and captured event, but without a reset, one must deal with the rollover at zero. Meaning, dealing with subtracting a negative number in the one special case of the roll over. i.e. one event happens before TC and the next happens after the TC and now the last is smaller than the current and the difference is greater than it really is, meaning some sort of two's complement technique for the special case. It's what I'm likely going to have to do, but thought I'd see if anyone saw something I did not or had a trick way of doing it.




                           I spoke to a CyPro friend/acquaintance/resource about this last night and his take was, that I was right, there isn't a simple way to handle the rollover (like a reset would solve) without using the hardware reset (no API), which, adds another signal to drive the reset and adds a measure of inaccuracy to it because of the 3 cycle delay after reset before the timer restarts (not that that is a big deal in this case).




                           There is a bit of a proprietary nature to my project, so don't want to post the entire project and the time to re-create just this piece of it is likely more time consuming than just bulling my way through the problem. If anyone that has used the Timer component for processing a tach signal like this and noted this problem has any suggestions, I'd be appreciative.




            Scott DeBruyn




            Dutchman Electronics LLC


            Forest Grove, Oregon



            • 3. Re: Timer, configuration / API problem for pulse to pulse time of quadrature signal.





              I finally found a link to a user forum where you responded to another user about this precise problem. As the other user did, and as you suggest here, I used a counter component and configured it for capture and TC. I put interrupt pins on both the interrupt and the TC outputs. This allowed me to separately interrupt on a TC or the capture event. In the component config, I set interrupt for only the Capture.




              The other problem I was having was getting a count input signal to the beast. I took the suggestion from the other users post (your reply) and added Sync components to counter’s count input. The user had used a DFF, I believe. Clocking the sync at 3kHz and providing a 1kHz clock to the count input set me up for a mSec granularity on a shaft spinning @ 0-1000 RPM (Quadrature Decoder component). Kind of wish the QD component had a counter driven interrupt though, as it sucks to have to do Last/Current comparisons of the count to see if the shaft turned. 


              Anyway, Thanks for your input and like your other user, sorry that I wasn’t predisposed to sharing my entire project on a user forum. If I hadn’t been time constrained, I’d have clipped out the timer/counter problem child and sent it… although it would have meant sending several configurations that didn’t work.








              Scott DeBruyn


              Dutchman Electronics LLC