5 Replies Latest reply on Feb 6, 2019 2:30 PM by niprc_2224616

    Autonomous timer functionality on PSoC 5LP

    niprc_2224616
    niprc_2224616 Dec 7, 2018 2:59 PM

      Hi,

       

      I have been racking my brain on how to properly utilize the timer component without wasting time in an ISR (outside of my standard housekeeping routines).  I have been experimenting in two separate applications with this timer component, but it seems to be missing some of the standard functions I am used to on other ARM processors (which is likely due to my ignorance).

       

      In the first application, I am reading a tachometer to measure speed via a 24-bit clock timer.  Right now the timer is configured to reload automatically on TC, but I have had no way of reloading the timer autonomously when a capture event occurs (i.e. Capture event mirrors TC event to move on and time next pulse while storing current value for read in frame machine/standard housekeeping ISR).  To get around this, I am generating a separate ISR "on capture" event and reading the capture within the ISR.  This seems clunky, since I am used to seeing reloads on capture and housekeeping by reading status flags and capture values without a separate ISR on other ARMS/TI procs.

       

      I played around with running the "Capture" Hardware bit through two flip flops back into the "Reset" port of the timer as I had seen on adjacent threads, but in testing that appears to clear my status flags and the capture register.  It may be important to note that I have relied on testing to verify some of this functionality since some of the finer details related to reset and register status are not defined in the Timer datasheet or the TRM via sections 26.3.3.2 and 26.3.3.3.  My assumptions from the TRM are that the UDB hardware reset should only reload the counter value and leave status/capture registers alone (At least in this case it would be ideal).

       

      Random things to mention: I was originally running this block at 32MHz, 32-bit, but ended up slowing things down and decreasing the field-width since the Timer datasheet mentions possible timing concerns at that range.

       

      Circling back, my main question is.. Is it possible to run the timer block to reload autonomously on capture without clearing status bits.  Is there a datasheet or TRM that defines this exact behavior?  I am attaching pictures of an example of 1 of 3 implementations I have played with to help out and I have no problem showing example sources.

       

      In the second application, I am reading a PWM input and the timer/capture block requires a bit of processor time to dynamic process period count and duty cycle, even using the "Pulse Width Mode" and "Period Mode" defined on 218 and 219 of the TRM for the PSoC 5LP (Document No. 001-69820 Rev. *D, 001-78426 Rev. *F).  Is there a way to do this autonomously so that all I am doing is reading captured values from two separate timers in my primary housekeeping ISR?  I assume if I am missing something in the first question, this will be answered there.

       

      Thank you for the time,

      Nick

      • 146 Views
      • Categories: PSoC 5 Device Programming, PSoC 5 Architecture
      • Tags:
        • 1. Re: Autonomous timer functionality on PSoC 5LP
          niprc_2224616
          niprc_2224616 Dec 7, 2018 6:55 PM (in response to niprc_2224616)

          I found something that works via the counter module, though it would be nice to rely on a single clock.

           

          Attached is the example circuit plus the settings.  I assume the advanced menus in PWM x2 modules will get me my other answer, but I will post when I find since examples were semi scarce for this exact problem.

           

          the_new_circuit.png

          the_new_settings.jpg

           

          I added the DFF for asynchronous warnings but I do not believe it is necessary.

           

          -Nick

          • 2. Re: Autonomous timer functionality on PSoC 5LP
            JoMe_264151
            JoMe_264151 Dec 8, 2018 2:25 AM (in response to niprc_2224616)

            The counter generates a single interrupt and it is up to you to act on the current reason. (btw: There is no interrupt allowed in your last post)

            The DFF is needed to avoid timing issues, you could have used a Sync component.

            It is always easier to help you when you 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.

             

            Bob

            • 3. Re: Autonomous timer functionality on PSoC 5LP
              niprc_2224616
              niprc_2224616 Dec 8, 2018 10:16 AM (in response to JoMe_264151)

              Bob,

               

              In the first example I was checking values off of the Speed_in ISR and setting a few flags to guaranteee timing.  It worked.

               

              Though this counter example above is working for me no problem (assuming I have a decay function on decel) without any extra time used in my code.  There is separately timed ISR at 1ms that is reading the capture and counter value on decay.

               

              I will attach a revised example when push comes to shove but my current project has some of my PID libraries in them that I would prefer to keep to myself. 

               

              Nick

              • 4. Re: Autonomous timer functionality on PSoC 5LP
                niprc_2224616
                niprc_2224616 Jan 5, 2019 2:28 PM (in response to niprc_2224616)

                So I finally made my way back to the PWM timing and I am running into quite the snag.  The goal is to measure a variable pulse width (high accuracy [~1-2 clock cycles]).  I am able to measure the period of the pulse with the Counter_CMD configuration, however, the PWM_CMD configuration below is returning shorted values.

                PWM Calc.jpg

                config.jpg

                 

                The assumption with this module is that it will be enabled for counting while the pulse is high and there will be a capture/reload on a falling edge prior to the system disabling before the next rising edge.  The capture register appears to always return 100-200 counts when I am transmitting a fixed 50% DC pulse (The result should be closer to 6000 cnts with a 1ms period).

                 

                Any ideas?  Again, the assumption is that there is no intervention via code aside from:

                 

                // pulse width in 12MHz cnts

                pulse_width = PWM_CMD_ReadCapture();

                 

                I have tested similar architecture's with the PWM module (Trigger on rising edge and capture on falling edge) and have similar results.

                • 5. Re: Autonomous timer functionality on PSoC 5LP
                  niprc_2224616
                  niprc_2224616 Feb 6, 2019 2:30 PM (in response to niprc_2224616)

                  This problem was resolved by making the count register larger than 8-bits.  I guess that is one of those things you do not see when you did the first bit correctly...