Compatibility of delayMicroseconds

[cburstedde]

Arduino specifies a maximum input value to delayMicroseconds of16383. For several of the functions here, the limit is lower since we multiply by numbers greater than 4 (such as 4.125, 5, 6). These roll over, which produces spurious delays.

It would be relatively easy to fix this by adding NOPs to the busy loop and calling it less times, and I wouldn't mind looking into it. It would mean another test cycle for most of the higher clock frequencies though.

I also have three more exact frequencies, namely 16.5 MHz (favorite for overclocking, and contrary to 16 Mhz millis never jumps by 2), 10 MHz (wouldn't have done it but there were comments that needed fixing) and 6 MHz (there is currently a large gap between 7.37 and 4 MHz). Might do this at the same time so we only have to test everything once.

[MCUdude]

It would be relatively easy to fix this by adding NOPs to the busy loop and calling it less times, and I wouldn't mind looking into it. It would mean another test cycle for most of the higher clock frequencies though.

Would be great if would like to look into it! Compatibility is always nice, but let's hope it doesn't affect the "low number" microsecond times.

I also have three more exact frequencies, namely 16.5 MHz (favorite for overclocking, and contrary to 16 Mhz millis never jumps by 2), 10 MHz (wouldn't have done it but there were comments that needed fixing), and 6 MHz (there is currently a large gap between 7.37 and 4 MHz). Might do this at the same time so we only have to test everything once.

I'm always open to adding new and clock frequencies to the core! Provide a PR, and I'll test them 👍

[cburstedde]

It would be relatively easy to fix this by adding NOPs to the busy loop and calling it less times, and I wouldn't mind looking into it. It would mean another test cycle for most of the higher clock frequencies though.

Would be great if would like to look into it! Compatibility is always nice, but let's hope it doesn't affect the "low number" microsecond times.

It should work fine, but I'll have to put delayMicroseconds on the back burner for a while.

I also have three more exact frequencies, namely 16.5 MHz (favorite for overclocking, and contrary to 16 Mhz millis never jumps by 2), 10 MHz (wouldn't have done it but there were comments that needed fixing), and 6 MHz (there is currently a large gap between 7.37 and 4 MHz). Might do this at the same time so we only have to test everything once.

I'm always open to adding new and clock frequencies to the core! Provide a PR, and I'll test them +1

Cool, see PR #31!

[cburstedde]

I still don't see me having time for extended work on delayMicroseconds(), sadly, but I'm wondering whether cburstedde/MCUdude_corefiles@e7f5be0 effects a closer timing of delay() for (only!) the odd frequencies. This is about a constant offset (not the scaling that is accurate). The effect becomes increasingly noticeable for slower clock frequencies.

Right now I'm estimating 180 cycles of overhead to remove; please feel free to adjust the source. Larger values make delay return sooner and vice versa.

The only downside is that delay(0) will take a couple cycles longer to return. There is some jitter due to interrupts by the conception of the delay function, but that is independent of this commit. A possible goal would be to have the error average to 0 over multiple measurements.