Improved delayMicroseconds().

[GoogleCodeExporter]

What change would like to see?

Switching to delayMicroseconds() code here: 
http://www.arduino.cc/cgi-bin/yabb2/YaBB.pl?
num=1273573826

Why?

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.

Original issue reported on code.google.com by dmel...@gmail.com on 11 May 2010 at 3:28

[GoogleCodeExporter]

I would much rather see something like Han's Heinrichs routines used:
http://www.avrfreaks.net/index.php?module=Freaks%20Academy&func=viewItem&item_id
=665&item_type=project

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.

Original comment by bperry...@gmail.com on 21 May 2010 at 9:18

[GoogleCodeExporter]

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.

Original comment by bperry...@gmail.com on 21 May 2010 at 9:34

[GoogleCodeExporter]

Original comment by dmel...@gmail.com on 11 Aug 2010 at 6:07

• Removed labels: Milestone-0019