Make modm::delay compatible with std::chrono

[salkinium]

This adds std::chrono support for the modm::delay() blocking delay implementation.

The implementation duration_casts everything to microseconds by default, unless a specialization is provided:

• modm::delay(std::chrono::nanoseconds), modm::delay_ns(uint32_t): Only implemented for Cortex-M, AVRs always delays 1us, Hosted casts to us (darwin/linux) or ms (windows).
• modm::delay(std::chrono::microseconds), modm::delay_us(uint32_t): implemented for all, except windows (casts to ms).
• modm::delay(std::chrono::milliseconds), modm::delay_ms(uint32_t): implemented for AVR and Hosted. Cortex-M casts to us.

In order to not go crazy from adding using namespace std::chrono_literals, I've added this to <modm/board.hpp> with a guard macro MODM_BOARD_DO_NOT_USE_LITERALS, so you can disable this behavior in your code. (It also adds using namespace modm::literals).

I have a usability question: Should modm::delayMilliseconds(uint16_t) be deprecated? During my refactoring, I had to add a lot of using namespace std::chrono_literals to driver methods, or construct the std::chrono::milliseconds(uint) in place. This is a little verbose. Perhaps the previous methods weren't such a bad idea? Should they perhaps be renamed to modm::delay_ms() for consistency?
Update: I've added modm::delay_[mun]s() functions as well, and it make perfect sense and the naming is good too.

TODO:

• Better documentation
• Add convenience delay_ms(uint), delay_us(uint), delay_ns(uint) methods?
• Decide deprecation behavior
• Double check if I got all delays right

cc @rleh @se-bi @strongly-typed @chris-durand

This PR is in preparation for #217.

[salkinium]

I'm ready to merge this if there are no complaints. I don't think this is very controversial, except perhaps the deprecation of delayMilliseconds etc. Is this deprecation too annoying? I could also make it silently forward to the new functions and simply not document these methods, so that new users don't use them.

[chris-durand]

I agree on deprecating delayMilliseconds.

Maybe we should fix AVR delay_ns. The way it is implemented right now delay_ns(1000) is a no-op, which is kind of surprising. There is a new instrinsic in avr-gcc which could help. It only works on compile time known delays and with optimization turned on, though.
I have tried it and it seems to work fine here.

[salkinium]

There is a new instrinsic in avr-gcc which could help. It only works on compile time known delays.

I know, and I explicitly chose the dynamic implementation with __DELAY_BACKWARD_COMPATIBLE__.
Unfortunately the implementation is horrible. Like they use multiplication and division with floating point numbers… holy shit:
https://www.nongnu.org/avr-libc/user-manual/delay_8h_source.html

void
_delay_us(double __us)
{
    double __tmp ;
    uint8_t __ticks;
    double __tmp2 ;
    __tmp = ((F_CPU) / 3e6) * __us;
    __tmp2 = ((F_CPU) / 4e6) * __us;
    if (__tmp < 1.0)
        __ticks = 1;
    else if (__tmp2 > 65535)
    {
        _delay_ms(__us / 1000.0);
    }
    else if (__tmp > 255)
    {
        uint16_t __ticks=(uint16_t)__tmp2;
        _delay_loop_2(__ticks);
        return;
    }
    else
        __ticks = (uint8_t)__tmp;
    _delay_loop_1(__ticks);
}

[salkinium]

I need to implement this myself it seems, and then I can hack something much more useful together with __builtin_choose_expr and __builtin_constant_p.

[chris-durand]

I just wanted to try the horrible runtime version in compiler explorer and found out _delay_us doesn't compile with -Os with a dynamic value with avr-gcc >= 5.

/opt/compiler-explorer/avr/arduino-1.8.9/hardware/tools/avr/avr/include/util/delay.h:276:40: error: __builtin_avr_delay_cycles expects a compile time integer constant

  __builtin_avr_delay_cycles(__ticks_dc);

                                        ^
Compiler returned: 1

for

int delay = 100;
int main() { _delay_us(delay); }

Maybe we never noticed that this doesn't work anymore because in modm all delays are static. I don't have a C++17 compatible avr-gcc here right now to test with modm.

[chris-durand]

Oh, sorry. It works with #define __DELAY_BACKWARD_COMPATIBLE__. I defined it after including the delay header, stupid me.

[salkinium]

This is what I came up with. I tried it with if constexpr, but that doesn't work, so the ?: operator is chosen: https://gcc.godbolt.org/z/W5LquY

I mean, the fastest this thing will ever go is 32MHz, which is 93ns per loop. At 8MHz, it's 375ns per loop. So the runtime version will be hopelessly over the top.

[chris-durand]

This is what I came up with. I tried it with if constexpr, but that doesn't work, so the ?: operator is chosen: https://gcc.godbolt.org/z/W5LquY

Seems reasonable. The line _delay_loop_1(ns-1 / ns_per_loop); looks off.
Do you mean _delay_loop_1(ns / ns_per_loop - 1);?

I mean, the fastest this thing will ever go is 32MHz, which is 93ns per loop. At 8MHz, it's 375ns per loop. So the runtime version will be hopelessly over the top.

Don't worry, 3 cycles is still a lot better than the 32 bit float multiplication in avr-libc. If someone wants accurate nanosecond timings, they should choose a faster cpu.

[salkinium]

I've implemented a new AVR delay that uses __builtin_avr_delay_cycles for constant values, which is very accurate and for dynamic values a much faster nanosecond delay for AVR, which divides with shifts and thus has a max error factor of 2.

Testing suggests that dynamic ms and us delay are fairly accurate even over an accumulated period, but dynamic ns delay is not super accurate, but also not wildly off. I think this is fine for most applications.