URL:
<https://savannah.nongnu.org/bugs/?59884>
Summary: _delay_ms() documentation wrongly states delay can
end up as 0 ms in certain situation
Project: AVR C Runtime Library
Submitted by: None
Submitted on: Fri 15 Jan 2021 11:33:02 PM UTC
Category: None
Severity: 3 - Normal
Priority: 5 - Normal
Item Group: Documentation
Status: None
Assigned to: None
Percent Complete: 0%
Originator Email: britton.ke...@gmail.com
Open/Closed: Open
Discussion Lock: Any
Release: 2.0.0
Fixed Release: None
_______________________________________________________
Details:
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).
_______________________________________________________
Reply to this item at:
<https://savannah.nongnu.org/bugs/?59884>
_______________________________________________
Message sent via Savannah
https://savannah.nongnu.org/
