Follow-up Comment #3, bug #17216 (project avr-libc):
Is is possible to move this forward?
The existing delay macros/functions do have problems.
For example, when using _delay_us(), if the delays are short, the code is
too simple and will insert too many cycles by using a loop count of 1 on a 3
cycle delay loop instead of a variable number of NOPs. This means you can
never get a delay shorter than 3 cycles.
Also, when calculating the number of loops for the 3 cycle delay function,
truncation instead of rounding up occurs, which means that the delay can be
shorter than requested. The remaining 1 or 2 cycles needed are simply lost.
This function does not properly handle the delay when the number of cycles
needed is not a multiple of 3.
_delay_ms() is also too simple. When the delay is long, it drops into a loop
calling a routine that is using a fixed number of clocks. Since the delay
inside each interation of the loop is not exact, the divergence between the
desired delay and the actual delay expands with each iteration through the
loop. Unfortunately the fixed number of clocks chosen is a short delay, which
means there will be many iterations of this loop.
The same rounding error as described above in _delay_us() also exists in this
routine other than the multiple is 4 rather than 3.
The new versions of the delay functions, treat the delay cycles in their
entirety so they don't suffer from those types of problems and are able to
achieve delays accurate to within 1 clock cycle.
IMHO creating the needed documentation for the new delay.h should not be a
roadblock as it is fairly simple and straightforward.
As far as the sbiw instruction goes, this is already being used by the
existing implementation.
The existing implementation calls _delay_loop2() which uses sbiw
What is needed to get the ball moving again?
_______________________________________________________
Reply to this item at:
<http://savannah.nongnu.org/bugs/?17216>
_______________________________________________
Message sent via/by Savannah
http://savannah.nongnu.org/
_______________________________________________
AVR-libc-dev mailing list
AVR-libc-dev@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-libc-dev
