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.