Global Sources
EE Times-India
Stay in touch with EE Times India
 
EE Times-India > Embedded
 
 
Embedded  

Utilising RTOS semaphores: Event semaphores

Posted: 21 Nov 2014     Print Version  Bookmark and Share

Keywords:semaphore  mutex  embedded systems  binary  multiple event 

As mentioned in Part 1 of this series, the semaphore is often disparaged because it cannot prevent unbounded priority inversions like its big brother, the mutex. To compensate for this disability, semaphores have many more capabilities and uses than mutexes. Following on my discussion earlier of binary and multiple resource semaphores in embedded systems, this part discusses using binary and multiple event semaphores.

Event semaphores provide a method to synchronise tasks with internal or external events and with other tasks. For example, one task can signal another:

 Code

SCB_PTR se;
se = smx_SemCreate(EVENT, mode, "se");

where port1_ack is an event semaphore. An event semaphore is created as follows:

SCB_PTR se;
se = smx_SemCreate(EVENT, mode, "se");

Mode == M for a multiple event semaphore and == B for a binary event semaphore. In both cases, the semaphore's internal count starts at 0, i.e., there are no events to report, yet.

Multiple event semaphore
We start with the multiple event semaphore because it is the more common of the two. When a signal occurs for it, the first waiting task is resumed with TRUE. If no task is waiting, the internal count is incremented by 1. A multiple event semaphore keeps an exact count of signals received, whether or not any task is waiting. Hence, it is good for situations where every event counts and missing events could have bad consequences.

Of course, a simple counter could keep an accurate count of events, but a task cannot wait at a counter. An important property of the multiple event semaphore is that it handles both the case where events get ahead of the processing task and the case where the processing task gets ahead of events. In the first case, the semaphore's internal count is incremented; in the second case, the task waits. The following is an example showing this:

 Code

This is a simple example in which the occurrence of external event A causes an interrupt, which causes ISR_EventA() to run. ISR_EventA() invokes LSR_EventA(), which signals semaphore sme. Note that task t2a tests sme for every loop, including the first. If the internal count in sme is greater than 0, the count will be decremented, and t2a will process event A. Looping continues until the internal count of sme is 0, then t2a waits. Hence, no events will be lost if t2a gets behind, and when all events have been processed, t2a will wait for the next event. This synchronisation between external events and an internal task produces a solid design.

Note that t2a will only wait for TMO ticks, after which the 'while' loop is exited and other code runs to deal with the timeout or error. It is always a good idea to specify reasonable timeouts on task waits in order to prevent tasks from being permanently suspended due to unexpected combinations of events. This improves reliability.

Note: LSRs are a means of performing deferred interrupt processing. Most other RTOSes use callback functions to accomplish this.

Binary event semaphore
The binary event semaphore is the converse of the multiple event semaphore in that events after the first are discarded. There is a good reason for this, as we shall see. A binary event semaphore is created as follows:

SCB_PTR sbe;
sbe = smx_SemCreate(EVENT, B, "sbe");

1 • 2 Next Page Last Page



Comment on "Utilising RTOS semaphores: Event sem..."
Comments:  
*  You can enter [0] more charecters.
*Verify code:
 
 
Webinars

Seminars

Visit Asia Webinars to learn about the latest in technology and get practical design tips.

 

Go to top             Connect on Facebook      Follow us on Twitter      Follow us on Orkut

 
Back to Top