When hooking up the mrf24j40 to a bluepill board, the driver would
always get stuck on init.
Debugging revealed that it would get stuck in the mrf24j40_reset_state_machine()
function because it expects the RFSTATE to have a special value after reset.
However, the data sheet does not mention this in section 3.1 Reset.
Waiting 192µs should be enough - the value of the RFSTATE is not specified.
The Linux driver also does not wait for the RFSTATE register.
And even without the loop, the driver is functioning fine.
Two Functions cmd_test_xtimer_mutex_lock_timeout_low_prio_thread and thread_low_prio_test are added.
This testfunction will test xtimer_mutex_lock_timeout with two threads (main thread and lower prio than main thread).
The main thread creates another thread and sleeps. While the main thread sleeps the other thread takes the mutex
and wakes the main thread up.
Then the main thread calls xtimer_mutex_lock_timeout and the second thread unlocks the mutex and
the main thread gets it and waits for the created thread to end.
Has test messages showing the thread count. To make sure the created thread ends.
(test messages may be removed in the future)
Removing the periph_timer feature requirement, which isn't
directly required by this examples but rather by xtimer.
The latter set this requirement already in Makefile.dep
hence, it is duplicated and not necessary here.
The IPv6 (extension) headers of the first fragment received are re-used
for the reassembled packet, so when receiving a subsequent packet we
need to distinguish, if we just want to release the payload or all of
the packet after the packet data was added to the reassembly buffer.
Adds a test case for when the following conditions cause a crash:
- a subsequent fragment is received before the first
- the reassembly buffer is currently filled up when another fragment of
a different datagram arrives and thus needs to be cached out to make
room for the new reassembly
This allow configuring the flash targets in the same way as the
compilation and test targets.
This is part of trying to flash with docker using a different flash target.
Right now the gain and reference are hard coded. Until it is configurable
at runtime prefer the same default as with Arduino Core. That is,
GAIN_DIV2 and REFSEL_INTVCC1. This way we can properly measure the
battery voltage.
This is still currently a hack to hardcode it as the value can be deduced
from the `BOARD_MODULE` daughter board name.
But it requires more cleanup and could come in a separate step.
Part of moving CPU/CPU_MODEL definition to Makefile.features to have it
available before Makefile.include.
