If user has initiated a delayed event (either with call_in or call_every),
user might need to know how much time is left until the event is
due to be dispatched.
Added time_left() function can be used to get the remaining time.
Event queue was using its own Timer or LowPowerTimer objects to derive
millisecond tick counts. This is unnecessary in RTOS builds, where the
RTOS is maintaining a tick count.
It also makes more sense to use the actual RTOS tick count, as the
values are being used to compute tick timeouts for RTOS calls. Computing
these RTOS tick delays with a separate timer could conceivably lead to
rounding errors.
Fixes: #5378
Building with (GNU Tools for Arm Embedded Processors 7-2017-q4-major) 7.2.1 20170904 gives this warning
../events/equeue/equeue.c: In function 'equeue_incid':
../events/equeue/equeue.c:40:17: warning: '<<' in boolean context, did you mean '<' ? [-Wint-in-bool-context]
if (!(e->id << q->npw2)) {
Make calls to cmsis-os to get thread state, stack size, and max stack
usage rather than accessing internal RTX data directly. Wrap RTX5
specific code in OS_BACKEND_RTX5.
Also refactor the code to use mbed types rather than RTX types:
os_timer_t -> mbed_rtos_storage_timer_t
os_event_flags_t -> mbed_rtos_storage_event_flags_t
osRtxMutex_t -> mbed_rtos_storage_thread_t
This provides the correct binary semaphore behaviour that was expected
by the equeue layer, removes concerns around semaphore overflow, and
reduces the number of spurious wakeups which may save a bit of power.
This also fixes some issues we were seeing around the RTX 5 changes
to semaphore behaviour.
Several opaque buffers are used to to wrap c++ classes to pass
to the c layer. The reinterpret cast to c++ classes is fine as long
as the underlying buffer is not interpreted as different incompatible
types, or else the behaviour is undefined.
In the equeue_tick_init function, placement new is used to initialize
the buffers. However, this interprets the buffer as a simple array
of bytes, not the actual class type. Later the buffer is casted to
the class type. From the point of view of the compiler, these two
types are incompatible, and the compiler is free to reorder the
operations under the assumption that they can't affect each other.
Reinterpet casting the buffer to a class pointer before using
placement new insures that the buffer is only interpreted as a single
type. Or simple using the return value from placement new will handle
the aliasing appropriately.
Before, if the semaphore recieved a wait of zero, the semaphore
would erronously drop the ticker event to wake up the device,
causing the device to go to sleep without any mechanism to wake
itself up.
During a dispatch operation, the event queue dispatches all events
that have expired, so the call to equeue_sema_wait very rarely
has a wait of zero. But this can happen when an event is posted
just after a dispatch has occured.
An odd bug (c0951c9) in the NCS36510 ticker code caused the timer/ticker
classes to become desynchronized. Updated the handling to not assume the
timers are perfectly in synch. This will increase the event's tolerance of
less robust platforms.
For equeue_sema_wait, -1 is used to indicate an infinite wait.
This wasn't handled in the nonrtos implementation and caused
undefined/weird behaviour after an overflow on integer multiplication.
On most boards, the infinite wait would return after ~50 days, on the
STM32F4 the timeout killed all other timeouts for some reason.
The equeue_chain function is supposed to unchain the event queue
from whatever queue it is chained to when passed a null target.
Internally, this is accomplished by just calling equeue_background
with null and letting the previously registered update function
clean up the chaining.
However, equeue_chain did not appropriately check for null, causing
it to unnecessarily allocate memory and leaving the update function
in a bad state. Fixed with a simple null check.
With ARM Compiler 5.06u3, when the equeue_tickdiff function is
inlined, the compiler treats the unsigned integer subtraction
as undefined behaviour and assumes falsely the comparisons
could never be true.
The workaround is to an explicit cast, which politely reminds the
compiler to emit the correct comparison.
Added mbed-events from https://github.com/ARMMbed/mbed-events. Changes
from upstream:
- the whole code is licensed under the Apache license. Sources and
headers were updates with this information.
- removed the porting layers for Windows and FreeRTOS and the references
to these porting layers in equeue_platform.h.
- moved the TESTS directory in mbed-events to the TESTS directory of
mbed-os.