delayMicrosceconds limitations using teensyduino?

Status
Not open for further replies.
N

nils1982ks

Member
Hey,

I just found the teensy 3.0 and I am very impressed, so that I ordered 2 of them. I found that many functions are improved compared to the standard arduinos, but I wonder if it is possible to have delayMicroseconds for longer periods? It seems that it only works in [0:16383] us which is a little disappointing, since I would need precise intervals of 200us-15s. Is there a clear limitation, why intervals can not be defined to longer than 16.3 ms? On the little atmega328 and others I do understand, but the teensy 3.0 should be able to do better I guess?

Would it be possible to combine different delays, for example first a delay(interval / 1000) and afterwards delayMicroseconds(interval % 1000)? Probably one has to expect significant uncertainty in the duration?

Best regards,
Nils
 
On Teensy3, delayMicroseconds() actually works up to 134217727 microseconds, or about 134 seconds.

However, it's not a good idea to use such long delays. On AVR, the limit is 16383, so if you use longer delays, you code won't work if someone uses it on other boards. Even if you only ever use it on Teensy3, delayMicroseconds is implement with a busy loop, with the intention you want very short delays. Interrupts will lengthen the delay time. Using delay() is mostly insensitive to interrupts, because it checks the millis() count as it goes.

I am considering a change in delayMicroseconds() that would restrict the longest delay on Teensy3 to approximately 35 seconds. When this change might happen, if ever, is still unknown. But if you do use large numbers with delayMicroseconds(), I'd recommend keeping them under 35 million
 
Thank you very much for the super fast reply, and all the work you invested, that now allows idiots like me to use fast hardware. Unfortunately, I do not know how else I can program well defined intervals of 200 us - 2 s with us precision, that should start at a certain point and just run once. Maybe the IntervalTimer can be used for this purpose. I will try it, as soon as I receive the hardware.
Best,
Nils
 
IntervalTimer will give you the best performance, but then you need to deal with the difficulty of interrupt context programming.

elapsedMicros might be another way, avoiding the interrupt context issues.
 
Interrupt context programming might solve the problem, I tried it with the arduino and used the timer and a compare match. I had to preload the timer and start it, when ever the period should begin. Probably it would be enough to stop the timer after one cycle, reset it and with a little math adjust it to the new period and start it in the next cycle. I guess that the IntervalTimer should do the same on teensy 3.0, but at which value does the counter for the IntervalTimer start after e.g.
Code: 
myTimer.begin(blinkLED, 150000);
and is it possible to disable only the Interrupt of the IntervalTimer, so that other interrupts are not effected?
 
nils1982ks said:
Interrupt context programming might solve the problem, I tried it with the arduino and used the timer and a compare match. I had to preload the timer and start it, when ever the period should begin. Probably it would be enough to stop the timer after one cycle, reset it and with a little math adjust it to the new period and start it in the next cycle. I guess that the IntervalTimer should do the same on teensy 3.0, but at which value does the counter for the IntervalTimer start after e.g.
Code: 
myTimer.begin(blinkLED, 150000);
and is it possible to disable only the Interrupt of the IntervalTimer, so that other interrupts are not effected?
Click to expand...
If your delays are in the order of 10's of microseconds, maybe low 100's, then you need to be using hardware timers, not delay loops, because interrupts of any kind, of course, affect CPU cycles vs. real time.
 
Thanks for your hind, but the delays are between 100 us and a few seconds, which is fairly larger than 100's of microseconds. Do you know how to reset IntervalTimer? Probably one has to directly access the microcontroller's counter and interrupts as it is with the avr.
 
IntervalTimer automatically calls your function at the interval you selected. No reset or other work is needed (as would be the case with an AVR timer). Of course, your function should return quickly to avoid interfering with other stuff, or at least it shouldn't take longer than the interval you've set.
 
Status
Not open for further replies.
Back
Top