The nanostack hal's critical section uses a mutex for mutual exclusion,
which is nice for many use cases. But when one needs to use the critical
section from interrupts, the RTX will have a assertion failure and panic.
Add a configurable for mbed_lib, which can be used to enable a alternative
version of critical section, which uses the underlying OS primitives, which
disables the interrupts.
Note: the default behavior is not changed, one needs to override the
"nanostack-hal.critical-section-usable-from-interrupt" to have "true".
Reason for this change is that there is a need for sending events using
nanostack event queue from interrupt context, eg. from a socket callback.
The thread flag signaling mechanism is problematic if a separate event
loop thread is not used. The problem is, that one needs to know the
thread id of the loop dispathcer, and that knowledge can be derived
only from the caller thread of the initialization function.
Remove the magic connection from caller thread to dispatcher thread
by using event flags instead of thread flags on signaling. As the
event flags require the massive amount 20 bytes of RAM whereas
thread flags requires none, keep the code behind flag.
The separate eventloop thread may not be necessary on all uses, as one
can use the existing main thread for event dispatching. Add a
conditional nanostack-hal.event-loop-dispatch-from-application, which
disables the thread creation.
Note: the ns_hal_init must be ran from the same thread which will be
used to execute the event loop later.
Few targets need more than just pending IRQ set. They include some flags to be
set that are checked in IRQ handler. This is the case for targets in this
commit.
Before this patch, when calling lfs_mkdir or lfs_file_open with root
as the target, littlefs wouldn't find the path properly and happily
run into undefined behaviour.
The fix is to populate a directory entry for root in the lfs_dir_find
function. As an added plus, this allowed several special cases around
root to be completely dropped.
sleep_manager_racecondition test fix for devices with low CPU clock
This RP contains fix for sleep_manager_racecondition test
for very slow devices (like NRF51). It fixes the test itself
as well as side effects of fix introduced in
#5046 (us ticker: fix fire interrupt handling)
The idea of the test was to test race condition between main thread
and interrupt handler calling the same function.
To efficiently test this, each handler call should interrupt
main thread to make race more likely.
On very slow devices (like NRF51) when we set very low ticker period
(e.g less then 1000us for NRF51) there is no much time for thread scheduling.
On such slow devices, setting period to 500 us cause that
main thread is scheduled very rarely and only handler is
constantly called making test unreliable.
Fix introduced in #5046 (us ticker: fix fire interrupt handling)
changed fire_interrupt function implementation causing more
interrupt tailing thus even less time for main thread scheduling.
After introduction of #5046 (us ticker: fix fire interrupt handling)
when running sleep_manager_racecondition test on NRF51
(with ticker1.attach_us(&sleep_manager_locking_irq_test, 500);)
test is failing with timeout due to the fact that interrupt
handler is constantly called and main thread is never scheduled.
Current behaviour ends up undefined when the constructor leaves early.
Now FilePath just discards leading slashes and otherwise asserts if the
path is bad.
Some toolchains (GCC) may emit error messages with unicode symbols based on
the your localization settings. Instead of being passed to the user as is,
the unicode causes an exception.
Cruz Monrreal
Tero Jääskö
Kevin Bracey
Rob Meades
Ashok Rao
Jimmy Brisson
Vincent Coubard
Martin Kojtal
Maciej Bocianski
Filip Jagodzinski
Christopher Haster
David Saada
Mahesh Mahadevan
Teemu Kultala
Marcus Chang