Events
Events can be used to synchronize tasks. Just to make it
simpler, you can imagine an event a bit in the 32 bit integer number (mostly, that is the word size of a MQX RTOS).
So this is how it would happen:
a) Somebody-1 would be waiting for this bit to be set. Until
this bit is set that somebody would be stuck.
b) And Somebody-2 would set that bit so that somebody-1 can
proceed further.
So in crude and very layman sense, events in RTOS are
nothing but setting/clearing one bit.
Now let’s add few more technicalities to it.
Somebody-1 above normally would be tasks which would wait
for something. And sombebody-2 could be another Task or ISR.
In fact many embedded applications work this way, ISR gets triggered
and as ISR handlers should be very small, they normal set an event and exit. So
it serves both purposed ISR finishes quickly and also your application logic of
waiting gets out of ISR. (in fact this is the most widely approach of designing ISR/task based applications).
Why not use Setting/Clearing of bits than Events? What extra ROTS event handling adds apart from setting
clearing bits?
a)
First and for most, whenever
RTOS calls are setting/clearing event bit that part of kernel code is 100%
atomic and safe. I mean, as done for other parts of kernel, when updating (here
setting/clearing bit) interrupts are disabled.
(Imagine you try to mimic the
events and you are about to clear the bit and suddenly and ISR comes which
tries to set the same bit. Well, that would be it for your logic.)
If you have access to MQX source it would be fun exercise to trace the implementation
of set/get event.
b)
Option to wait for single
event (one event) or many events in single call.
_event_wait_all -> if you choose this one your wait call would be
blocked until all the events(bits) you specified in the mask are set.
_event_wait_any -> if any of the events(bit) specified in the mask is
triggered.
c)
RTOS has data structure called run queue and blocked
queue. So event wait call need not be a infinite for loop. If you
are implementing the events try to think how would be your WaitEvent call. As you don't have those data structure it would have to be infinite loop.
RTOS has that(run, blocked queue) info, so when it hits a event wait call, it puts that
task to blocked list. When it receives the event it checks the blocked queue
and puts that task to ready queue.
Infinite loop are big NO in embedded systems. As in that case, CPU would be performing loop operation and consuming power.
d)
Option to unblock all the
tasks. Suppose 3 tasks are waiting for an event, and event is received. There in an
option in MQX which would automatically clear the event as soon as it arrives
and unblock all the tasks.
e)
You can also pass timer parameter to the wait event calls, means you will only be blocked for x mill
secs.
BTW,
MQX comes with two type of event handling, one with lightweight event
handling and second one is (let’s say) normal event handling. Lightweight APIs
are targeted to single processor systems while other one can handle more than
one processor. Remember, in first MQX post when I said MQX can handle more than one
processors.
PS: I intentionally have avoided to put the API names, thinking behind this is concepts are more important than the API names.
Continue reading about events here
One interesting MQX problem I faced can be found here
