Am 04.02.20 um 23:05 schrieb Joerg Wunsch:
As Georg-Johann Lay wrote:
hmmm. So there is more work to do for double support? We definitely do not
want double here but float instead...
I disagree.
This is all just happening in temporary variables inside of "static
inline" functions, and thus
As Georg-Johann Lay wrote:
> hmmm. So there is more work to do for double support? We definitely do not
> want double here but float instead...
I disagree.
This is all just happening in temporary variables inside of "static
inline" functions, and thus completely optimized away by the compiler.
Joerg Wunsch schrieb:
> No, obviously, the documentation is wrong, and the delay functions
clip the delay value at a __builtin_avr_delay_cycles() value of
UINT_MAX rather than setting it to 0.
However, I just revisited the C standard on this. All this is simply
undefined behaviour: the interna
As Britton Kerin wrote:
> 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.
>
> It looks like the result is now the m
Am 23.01.20 um 23:57 schrieb Britton Kerin:
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 (29.0);
debug_led_off ();
assert (0);
leaves the debug led on for about 269 s. Same for
