pulse delay generator: teensy 4

[mark_15jan]

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?

 

[defragster]

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

 

[mark_15jan]

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?

 

[defragster]

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.

 

[defragster]

Started the cycleCounter on T_3.2 and T_3.6:

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.

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.

  pinMode( INT_PIN, INPUT );
  attachInterrupt( INT_PIN, startPDG, RISING );