The ESP-IDF WiFi interface wrapper always calls `xSemaphoreTakeRecursive` and `xSemaphoreGiveRecursive` for mutexes, regardless of whether they are recursive or not. Instead of an `assert`, the fix now also checks the type of the mutex in the functions for recursive mutexes and then calls the functions for normal mutexes if the mutex is not recursive.
- do not use `bash` in shebang, e.g. containers may not ship bash
- do not use `flock -w <timeout_secs> ...`, but
`timeout <timeout_secs> flock ...` to be portable to even busybox's
flock implementation
- sha512sum is more common on Linux than shasum
On a setup I have on my desk I can reliably get the I2C bus stuck. But
the current unstuck logic will not get it unstuck. Adding a full reset
of the SERCOM does fix the issue, though.
Co-authored-by: crasbe <crasbe@gmail.com>
The `setcontext()` implementation of glibc does restore the signal
mask to the target thread during the switch, libucontext [does not][1]
[1]: https://man.archlinux.org/man/libucontext.3.en#CAVEATS
Instead, we just manually enable signals again just before the call
to `setcontext()`.
With this, tests like `tests/core/mutex_canel` or `tests/core/irq` now
pass on `native64` when using libucontext.
Co-authored-by: crasbe <crasbe@gmail.com>
- split out the detection logic into a static helper function
- replace a forgotten debug `printf()` with `DEBUG()`
- add a `LOG_ERROR()` to when no device is detect to ease diagnosis of
a failing SPI bus / incorrect wiring / broken chip
- use a bullet-proof test:
- First set the modulation type to LoRa
- Then get the modulation type and expect it to be LoRa
Even if the reset of the devices fails (e.g. because the reset signal
is not connected) and the modulation would be different from LoRa, this
now should reliably detect the chip.
During the conversion to SPDX tags a few files that actually should have
been tagged `LGPL-2.1-or-later` got tagged `LGPL-2.1-only`.
This fixes the labels to match the actual file license.
The previous implementation relied on `thread_flag_set()` to defer the
context switch when called with IRQs disabled until `irq_restore()` is
called. This however can only be the case when `thread_yield_higher`
triggers an IRQ and performs the context switch within the ISR. This
allowed the previous implementation to continue calling
`thread_flag_set()` for the remaining group members.
This however is an implementation detail that is not part of the API
contract. Platforms that do not have a service request IRQ may have to
use other means for context switching that do not get deferred until
an `irq_restore()` is called. In that case, the first call to
`thread_flags_set()` even with IRQs disabled may directly trigger a
context switch to the unblocked thread, even if other group members
would also be unblocked and have a higher priority.
This changes the implementation to manually set the flags and update
the thread status without yielding and keep track whether any thread
has been awoken. Only once the states of all threads have been updated,
the adapted implementation will now call `thread_yield()` (unless no
thread was awoken).
All uses of thread_flags_wake() also had to set the flags anyway, so
we can just combine those operations into a new
thread_flags_set_internal() and update the users to use that instead.
