AVR C Runtime Library - Bugs: bug #59884, _delay_ms() documentation wrongly...
You are not allowed to post comments on this tracker with your current authentication level.
bug #59884: _delay_ms() documentation wrongly states delay can end up as 0 ms in certain situation
Submitter: | None | ||
Submitted: | Fri 15 Jan 2021 11:33:02 PM UTC | ||
Category: | None | Severity: | 3 - Normal |
Priority: | 5 - Normal | Item Group: | Documentation |
Status: | None | Percent Complete: | 0% |
Assigned to: | None | Originator Email: | -email is unavailable- |
Open/Closed: | Open | Release: | 2.0.0 |
Fixed Release: | None |
No files currently attached
Depends on the following items: None found
Items that depend on this one: None found
Carbon-Copy List
No changes have been made to this item
On a 16 MHz Arduino Mega 256, this code:
__builtin_avr_delay_cycles (100.0); // Compiles, so we apparently have it
debug_led_on ();
_delay_ms (290000.0);
debug_led_off ();
assert (0);
leaves the debug led on for about 269 s. Same for larger arguments to _delay_ms (e.g. 350000.0). This is different from what this documentation implies will happen:
If the avr-gcc toolchain has __builtin_avr_delay_cycles() support, maximal possible delay is 4294967.295 ms/ F_CPU in MHz. For values greater than the maximal possible delay, overflows results in no delay i.e., 0ms.
A discussion on the avr-libc mailing list made clear that the problem is that the documented behavior depends on undefined behavior as described here:
https://lists.nongnu.org/archive/html/avr-libc-dev/2020-01/msg00009.html
Rather than document the particular behavior I would change the documentation for _delay_ms() (at least, not sure if _delay_us() or others might also need attention) to state the behavior in that circumstance is undefined ("propagate" the undefined).