Improve avr wait_us()

[mtei]

Description

The execution time of wait_us() has been made accurate.

The test code is here

https://github.com/mtei/qmk_firmware/blob/3fb33b713ce97633a9d944ebb27ceeb609ab04ce/keyboards/helix/rev2/keymaps/five_rows/wait_test.c#L17-L58

Test Results (16MHz AVR)

• wait_us(constant): wait_us(2000)

* wait_us(variable): x=2000; wait_us(x)

* old version wait_us(variable): x=2000; wait_us(x)

Types of Changes

• Core
• Bugfix
• New feature
• Enhancement/optimization
• Keyboard (addition or update)
• Keymap/layout/userspace (addition or update)
• Documentation

Checklist

• My code follows the code style of this project: C, Python
• I have read the PR Checklist document and have made the appropriate changes.
• My change requires a change to the documentation.
• I have updated the documentation accordingly.
• I have read the CONTRIBUTING document.
• I have added tests to cover my changes.
• I have tested the changes and verified that they work and don't break anything (as well as I can manage).

[zvecr]

Outside of correctness, do we actually care if wait_us is incorrect for non constant values?

[mtei]

I think it is very rare that we need to give a variable to wait_us. Frankly speaking, I think it is sufficient to specify only constants for wait_us.

Nevertheless, if variables were allowed, people would expect them to be precise.

EDIT:
I don't even think it needs to be strictly accurate.
However, as you can see from the test results above, the current wait_us waits 1.5 times longer than the specified value. This is too imprecise.

[drashna]

I think what zvecr is trying to get at is: is there an impact for the wait_us being more accurate? Eg, is there a specific gain or behavior correction that this introduces?

[zvecr]

I think what zvecr is trying to get at is: is there an impact for the wait_us being more accurate? Eg, is there a specific gain or behavior correction that this introduces?

If we are taking into account the overhead of loops at this lower level then is the consumer of the wait_us API really going to account for their overhead too. I would say they are unlikely to do so, and wonder what use cases actually need to be covered by this code.