Unify behaviour of wait on AVR

[zvecr]

Description

wait_ms/wait_us on AVR cannot handle dynamic values like the ChibiOS abstraction can.

This leads to code that bleeds implementation details outside of tmk_core. For example;

#if defined(__AVR__)
        for (uint16_t i = delay; i > 0; i--) {
            wait_ms(1);
        }
#else
        wait_ms(delay);
#endif

Hopefully the __builtin_constant_p magic should catch a lot of the existing cases, limited testing shows the same firmware sizes.

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).

[sigprof]

This implementation would probably be grossly inaccurate because of the loop overhead (note that 1µs is just 8 cycles if this code runs on a 8 MHz chip). Hope that nobody actually tries to use this wait_us() with non-constant arguments, otherwise someone might need to implement something better instead of this.

This function is also sometimes used with some rather large values which won't fit into uint16_t (does not matter while they are compile time constants though):

keyboards/handwired/dactyl/matrix.c:        wait_us(1000000);
keyboards/handwired/pterodactyl/matrix.c:        wait_us(1000000);
keyboards/hotdox/left.c:        wait_us(1000000);

[zvecr]

This implementation would probably be grossly inaccurate because of the loop overhead

It would have been anyway, as they would have done the gross platform check loopy loop per my example in the docs.

When there becomes a need to do a super accurate us wait, across all platforms, we would have an issue with getting that behaviour consistent on ChibiOS. A bridge to cross at some point, maybe something for docs in the short term.

on the use of wait_us(1000000);, those look like general code smell to me and could do with a tidy up.

Either way they will have to be tackled as a future iteration.