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
To allow components with a simple need to schedule a few events to not
have to create their own threads, with all the associated memory
overhead, add 2 central calls to get shared normal and an
interrupt-deferral event queues, each dispatched on their own shared
threads.
For non-RTOS systems, just the normal event queue is provided, and the
application would have to dispatch this itself. This
application-dispatch is also available via a config option, to
potentially save memory by reusing the main thread.
Possible future improvement: the ability for separate components to
request a minimum stack size, and have the JSON combine these requests.
(Analogous tooling has already been mooted for mbed TLS config options
like key size).
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.
- Removed Makefile from branch
- Moved a0..a4/c0..c4 parameter documentation from top level overloaded functions to each function to appease Doxygen.
- Removed @see Event::Event from overloaded functions as the link did not work and the argument parameter documentation was moved down to each function
- TODO: Cleanup EventQueue.h
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.
stop using scope for \addtogroup. It was placing class methods into the
group documentation instead of the class documentation. The new style is
to explicitly tag the class as @ingroup. This new method will allow the
class to be linked in the group page, and the class page will contain
the detailed documentation of the class methods.
While limitations in type inference prevent the event helper from
infering the type of generic function objects, there is nothing
technical preventing inference from the Callback class, where the
function type is encoded in the template parameters.
With adoption of the Callback class as the standard function
representation, it makes sense to support events created from
callback objects.
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.
In the IAR ide, implicitly generated structures based on function
templates end up with missing type information. This has no effect
on using the IAR compiler standalone, but when used through the ide
the missing type information causes the ide to error.
As a workaround, moved the function attributes generated for the
Callback and Event classes into the class scope. This avoids the
syntax that confuses IAR.
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.