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.
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.
This commit adds an example application showcasing SUIT draft v4
firmware updates.
It includes a test script suitable for local or CI testing.
Co-authored-by: Alexandre Abadie <alexandre.abadie@inria.fr>
Co-authored-by: Koen Zandberg <koen@bergzand.net>
Co-authored-by: Francisco Molina <femolina@uc.cl>
I basically didn't work on `emb6` since 2016 and adapting to the newest
version would mean some major overhaul. However, the development at
their end seems to be stalled [since March 2018][emb6-develop] as well.
All this speaks for deprecating this package.
[emb6-develop]: https://github.com/hso-esk/emb6/tree/develop
