drivers/sx127x: pkg/semtech-loramac: replace xtimer by ztimer

[aabadie]

Contribution description

This PR replaces the xtimer used by the sx127x radio driver and package semtech-loramac by the new ztimer and especially its rtt based backend version.
This should allow lower power consumption, even between the TX and RX windows phases, but it will also allow the use of STOP mode (with RAM retention) on STM32 without the need to disable the duty-cycle check. I tested this particular point with #11237 and this PR and now it works.

Note that to be able to use the RTT backend one cannot rely on usec precision timers. msec precision delays cannot be used with radio reset delays but loramac uses ms precision delays all the time, so it can be used there. As a result, all timeouts that were provided in microseconds are now converted to milliseconds.

Testing procedure

• verify that examples/lorawan and pkg/semtech_loramac are still functional

Issues/PRs references

Will be usefull for #11237

[fjmolinas]

Would be nice if you start posting your test results ouput in the PR description.

[fjmolinas]

I'll run the release tests for both applications :)

[fjmolinas]

All good with tests/pkg_semtech_loramac:

IOTLAB_NODE=st-lrwan1-10.saclay.iot-lab.info make -C tests/pkg_semtech-loramac/ flash test -j3

main(): This is RIOT! (Version: 2020.10-devel-474-g5b8be-pr-14547)
All up, running the shell now
> loramac get devaddr
loramac get devaddr
DEVADDR: 2601107E
> loramac get nwkskey
loramac get nwkskey
NWKSKEY: 6CCC73B2681EC60142C5D4933BFE8D34
> loramac get appskey
loramac get appskey
APPSKEY: 07683C44D66D201B557B0DF7EFEF8391
> TEST PASSED

[fjmolinas]

examples/lorawan is not working for me:

main(): This is RIOT! (Version: 2020.10-devel-669-g2fb7d-HEAD)
LoRaWAN Class A low-power application
=====================================
Starting join procedure
Join procedure succeeded
Sending: This is RIOT!
# Nothing happens here ...

[fjmolinas]

examples/lorawan is not working for me:

Hmm seems to be an issue with iotlab boards, works with locally connected boards:

main(): This is RIOT! (Version: 2020.10-devel-474-g5b8be-pr-14547)
LoRaWAN Class A low-power application
=====================================
Starting join procedure
Join procedure succeeded
Sending: This is RIOT!
Sending: This is RIOT!
Sending: This is RIOT!
Sending: This is RIOT!
Sending: This is RIOT!
TESST PASSED

[fjmolinas]

@aabadie changes make sense and are working, once you take a look at my ztimer comment I'll ACK.

[fjmolinas]

BTW works with st-lrwan1-19.saclay.iot-lab.info but not with st-lrwan1-10.saclay.iot-lab.info'/st-lrwan1-11.saclay.iot-lab.info'at least.

[fjmolinas]

ACK.

[fjmolinas]

@aabadie murdock spotted many conflicts, can you take a look?

[aabadie]

murdock spotted many conflicts, can you take a look?

There were several issues:

• rtc and rtt features are conflicting on efm32 so I blacklisted these platform for examples/lorawan (since it uses both) => 61ab47e
• the xtimer defines for lobaro-lorabox were in the wrong file, this is fixed by 1579614
• for cpu with timer clocked at 250kHZ (Atmega), there was an issue in the ztimer auto_init code. I fixed it in 7c3e14e but I'm not 100% sure of the fix.

I can provide the last 2 commits in separate PRs to ease review if you want.

[fjmolinas]

Suggested change

	USEMODULE += ztimer_periph_rtt
	# If RTT feature is available use the RTT backend of ztimer
	FEATURES_OPTIONAL += periph_rtt
	ifneq (,$(filter periph_rtt,$(FEATURES_USED)))
	USEMODULE += ztimer_periph_rtt
	endif

[aabadie]

I prefer keeping the actual state for the loramac pkg: it's important to ensure that the rtt is used because of the duty-cycle timer. In a deep sleep mode with RAM retention, a regular timer will be stopped but not a rtt based timer.

[fjmolinas]

But why enforce it? Low Power modes are not enabled by default, only examples/lorawan does that.

[aabadie]

ztimer is an internal implementation detail of the package adaption to RIOT. There's no need to enforce developers to add this dependency in their lorawan applications.

[fjmolinas]

I think is a question of keeping flexibility or having things that work out of the box. I think you want the later, that is OK for me since you are maintaining this. Can you then add some documentation to the pkg on the implementation status, I think it would be good to say why rtt is required or when it is required. And in the same sense, what is needed for the pkg to work, what is needed for the pkg to work with sleep modes, etc... For me this is not very clear without having a knowledge of the code/implementation internals.

[fjmolinas]

@aabadie The fact that rtc and rtt are required seems very stm32 specific since with stm32 only rtc can wake up the cpu. It seems like a shame to blacklist architectures because of this.

Don't agree with latest changes.

[aabadie]

with stm32 only rtc can wake up the cpu

only in standby mode. In stop mode, rtt can wakeup the cpu.

It's not stm32 specific, it's just that examples/lorawan is using the rtc as a periodic alarm to send to next message. It could be done differently of course.
But I prefer using the RTC alarm so there's support for standby mode (or any mode without RAM retention) with lorawan. This is an important use case.

[fjmolinas]

It's not stm32 specific, it's just that examples/lorawan is using the rtc as a periodic alarm to send to next message. It could be done differently of course.
But I prefer using the RTC alarm so there's support for standby mode (or any mode without RAM retention) with lorawan. This is an important use case.

Ok I guess this is just an examples, and tests/pkg_semtech_loramac is more flexible.

[fjmolinas]

@aabadie only static tests did not pass, only #14547 (comment) has not yet been addressed

[aabadie]

squashed (to fix static tests) and added documentation to address #14547 (comment)

[fjmolinas]

ACK, lets wait for murdock

[aabadie]

Thanks for reviewing @fjmolinas !