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. It looks like the result is now the maximum delay, rather than 0ms. Perhaps __builtin_avr_delay_cycles() has changed? Also, the documentation for _delay_us() also contains this: If the user requests a delay greater than the maximal possible one, _delay_us() will automatically call _delay_ms() instead. The user will not be informed about this case. If the avr-gcc toolchain has __builtin_avr_delay_cycles() support, maximal possible delay is 4294967.295 us/ F_CPU in MHz. For values greater than the maximal possible delay, overflow results in no delay i.e., 0us. This looks suspicious because if _delay_us() calls _delay_ms() for longer delays, one would expect the same maximum low-resolution delay as for _delay_ms(). And in fact this code behaves as expected (gives 10 seconds with LED on): __builtin_avr_delay_cycles (100.0); // Compiles, so we apparently have it debug_led_on (); _delay_us (10000000.0); // 10 s in us debug_led_off (); assert (0); but this code delays for only 269s: __builtin_avr_delay_cycles (100.0); // Compiles, so we apparently have it debug_led_on (); _delay_us (290000000.0); // 290 s in us debug_led_off (); assert (0); So it looks like with recent avr gcc at least my suspicion is correct. If it would get applied I could prepare a documentation patch for these issues, but I don't know when the __builtin_avr_delay_cycles() behavior changed (assuming that's the cause of the above problem). Britton
