Forum Rule: Always post complete source code & details to reproduce any issue!
Results 1 to 5 of 5

Thread: pulse delay generator: teensy 4

  1. #1
    Junior Member
    Join Date
    Sep 2019
    Posts
    2

    pulse delay generator: teensy 4

    Hello

    I am planing to build a pulse delay generator based on Teensy4. The requirements are: programmable delay from the external pulse edge in the range of 0.1us up to 1 ms with an accuracy of 100ns or better, the output pulse width: programmable from 100ns up to 500 us. Could you please advise if the T4 is capable to do this, are there any standard libraries, or it requires register level programming?

  2. #2
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    9,321
    Should be possible - posted a delayCycles() sample on T4_Beta thread.

    while(!(triggerpin==???) //watch pin for indicated change
    delayCycles(a)
    digitalwritefast(pinout, high)
    delayCycles(b)
    digitalwritefast(pinout, low)

    That should run +/- 2 cycles where 'a and b' are the CPU cycles to elapse

  3. #3
    Junior Member
    Join Date
    Sep 2019
    Posts
    2

    pulse delay

    thanks for reply. Is the delayCycle() function only for T4 or it will work with T3 series as well?
    To capture the input pulse I would prefer to use a non blocked method as the input pulse event is very rare. Could you please tell what is the external pin interrupt latency/jitter I could expect from T4?

  4. #4
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    9,321
    The delayCycle will work on T_3.6, but it does not start the cycle counter running before setup() like the T4 does, so the code to start that would be needed.

    I didn't test on T_3.6 to see where the 'magic' number falls with giving the first usable value and the behavior after that - I should try that. Will have to go find that code ...

    Funny last time a timing thing came up I wrote an _isr for it and Paul posted a blocking example and I think it may have been used that way - so I did that.

    That that example as shown precluded adjusting the programmable feature of the times 'a' and 'b' - but it was 3am I see and a bit later than I should have been here. No idea how the programmable nature was to be incorporated.

    The _isr will have some delay and jitter - offhand I can't give a number - it will be ~20 ns response time AFAIK. If you have a scope you could measure that - none here.

    Running from T4 RAM without much else going on - or setting priority higher the jitter should be some few ns.

  5. #5
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    9,321
    Started the cycleCounter on T_3.2 and T_3.6:
    Code:
    void cyclesCntStart()
    {
      if ( ARM_DWT_CYCCNT == ARM_DWT_CYCCNT ) {
        ARM_DEMCR |= ARM_DEMCR_TRCENA; // Enable CPU Cycle Count
        ARM_DWT_CTRL |= ARM_DWT_CTRL_CYCCNTENA;
      }
    }
    Then running code to test across a range of values it looks good on T_3.2 { jumps 6 cycles at a time at 96 and 120 MHz } test sees a value that seems 'centerable' to that window with hardcoded 'Overhead Factor for execution' or 'magic' number.
    Code:
    static inline void delayCycles(uint32_t cycles)
    { // MIN return in 7 cycles NEAR 20 cycles it gives wait +/- 2 cycles - with sketch timing overhead
      uint32_t begin = ARM_DWT_CYCCNT - 12; // Overhead Factor for execution
      while (ARM_DWT_CYCCNT - begin < cycles) ; // wait
    }
    Was chasing the center on T_3.6 as far as I tested - but it was similar to T_3.2 - +/-3 cycles or a window of 6.

    Putting this in setup() for the desired INT_PIN to call a startPDG() function to run once or arrange to run continuously.
    Code:
      pinMode( INT_PIN, INPUT );
      attachInterrupt( INT_PIN, startPDG, RISING );

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •