sys: xtimer concurrency/robustness improvement

[Hyungsin]

Contribution description

This PR tries to resolve concurrency/robustness problem of xtimer, an attempt to escape from long suffering of xtimer's unrobustness. I personally have experienced frequency system crash due to xtimer. As an embedded OS, RIOT can have a little timing error but must avoid system crash to enable long-term attended operation of embedded devices.

1. All time-sensitive sections are interrupt free.
2. Support various hardware timers including <32 bits
3. Support overflow

The basic idea is to change xtimer operation from "absolute target-based" to "period-based", which is the case of TinyOS. Timer expiry and current time update are based on "offset" rather than "absolute target". An absolute target value is used only for sorting timers chronologically and setting a lltimer. I personally tested this PR with a Hamilton board and xtimer test applications in 'tests' folder. But further test might be needed.

I'm aware of other ongoing effort for fixing xtimer. I'm just throwing another option here since I have some time to focus on this issue now, and leave the decision whether to merge this PR with reviewers. @kaspar030, @gebart, This PR is the one I mentioned earlier about xtimer.

The next step would be reworking on #7053, with a simpler implementation.

Issues/PRs references

#5428, #6937, #9211, #9491

[fjmolinas]

@Hyungsin this will fix the last failing build in murdock:

git diff tests/
diff --git a/tests/pkg_semtech-loramac/Makefile b/tests/pkg_semtech-loramac/Makefile
index 227cab7e02..cd2eaca5eb 100644
--- a/tests/pkg_semtech-loramac/Makefile
+++ b/tests/pkg_semtech-loramac/Makefile
@@ -2,9 +2,14 @@ BOARD ?= b-l072z-lrwan1
 
 include ../Makefile.tests_common
 
-# waspmote-pro and arduino-meag2560 don't have enough RAM to support another
-# thread dedicated to RX messages
-BOARD_WITHOUT_LORAMAC_RX := arduino-mega2560 waspmote-pro i-nuncleo-lrwan1
+# The following boards don't have enough RAM to support another thread dedicated
+# to RX messages
+BOARD_WITHOUT_LORAMAC_RX := \
+    arduino-mega2560 \
+    i-nuncleo-lrwan1 \
+    stm32f0discovery \
+    waspmote-pro \
+    #
 
 LORA_DRIVER ?= sx1276
 LORA_REGION ?= EU868

[Hyungsin]

All checks have passed.

[fjmolinas]

@MichelRottleuthner so would you say this is ready now?

[MichelRottleuthner]

@MichelRottleuthner so would you say this is ready now?

Yes let's finally do this. I give my ACK.
Thank you all for helping!
We should still have a close look and watch out very carefully for any suspicious behavior that could be related to regressions or hidden bugs in the upcoming release tests.

[fjmolinas]

ACK!

[fjmolinas]

We should still have a close look and watch out very carefully for any suspicious behavior that could be related to regressions or hidden bugs in the upcoming release tests.

For sure. Thanks for all the work and patience @Hyungsin!

[fjmolinas]

@MichelRottleuthner I let you pull trigger!

[JulianHolzwarth]

@MichelRottleuthner this PR removed #11992
This should not be the case! #11992 is an important bug fix.

[MichelRottleuthner]

Can you file a PR for that again? We need a proper automated regression test for that.