My favorites | Sign in
Project Home Downloads Wiki Issues
New issue   Search
  Advanced search   Search tips   Subscriptions
Issue 256: Improved delayMicroseconds().
3 people starred this issue and may be notified of changes. Back to list
Project Member Reported by, May 11, 2010
What change would like to see?

Switching to delayMicroseconds() code here:


Making the function more accurate for compile-time-constant delays and generalizing it for any 
CPU speed.

Would this cause any incompatibilities with previous versions?  If so, how
can these be mitigated?

There could be some issues with very timing sensitive routines.
May 21, 2010
I would much rather see something like Han's Heinrichs routines used:

which are an improved version of the routines in AVR libC <util/delay.h>

Or write a few tiny simple 1 line macro wrappers for the built in GCC function:
extern void __builtin_avr_delay_cycles(unsigned long __n);

to provide the various delay functions for
nanoseconds, microseconds and miliseconds.

The macros are quite trivial.

May 21, 2010
Another thing to keep in mind when creating these delay functions is how they round.
Yes cycle rounding is very important.

The routines can "round" 3 different ways:
- truncate (always down) - which means you get a delay that is as close as possible
                           withoutgoing over but may be shorter than you ask for.

- normal "round"         - which means the delay is rounded to the closest clock
                           cycle which can be up or down.

- always up              - which means you will always get "at least" as long of
                           a delay as you ask for.

The code, which is in wrapper macros around the cycle delay code, to do any of these
roundings is very trivial, but the desired method must be defined/documented.

Alternatively, if you want to create a new function (which would not be backward
compatible) you could pass in the rounding style.

IMHO, for short delays, in the microsecond or sub microsecond range, rounding up
makes the most sense as those delays are typically based on hardware setup times and
hardware generally needs "at least as long as" type delays.

That way, the application is guaranteed to always get delays that will not violate
hardware setup times.

Aug 11, 2010
Project Member #3
(No comment was entered for this change.)
Labels: -Milestone-0019
Sign in to add a comment

Powered by Google Project Hosting