...
The operations described above are summarized using the pseudo-code shown in the listing below.
Code Block | ||
---|---|---|
| ||
OS_SEM MySem; (1)
void main (void)
{
OS_ERR err;
:
:
OSInit(&err);
:
OSSemCreate(&MySem, (2)
"My Semaphore", (3)
1, (4)
&err); (5)
/* Check "err" */
:
/* Create task(s) */
:
OSStart(&err);
(void)err;
} |
Panel | ||||
---|---|---|---|---|
| ||||
(1) The application must declare a semaphore as a variable of type (2) You create a semaphore by calling (3) You can assign an ASCII name to the semaphore, which can be used by debuggers or µC/Probe to easily identify the semaphore. Storage for the ASCII characters is typically in ROM, which is typically more plentiful than RAM. If it is necessary to change the name of the semaphore at runtime, you can store the characters in an array in RAM and simply pass the address of the array to (4) You specify the initial value of the semaphore. You should initialize the semaphore to 1 when the semaphore is used to access a single shared resource (as in this example). (5) |
Code Block | ||
---|---|---|
| ||
void Task1 (void *p_arg)
{
OS_ERR err;
CPU_TS ts;
while (DEF_ON) {
:
OSSemPend(&MySem, (1)
0, (2)
OS_OPT_PEND_BLOCKING, (3)
&ts, (4)
&err); (5)
switch (err) {
case OS_ERR_NONE:
Access Shared Resource; (6)
OSSemPost(&MySem, (7)
OS_OPT_POST_1, (8)
&err); (9)
/* Check "err" */
break;
case OS_ERR_PEND_ABORT:
/* The pend was aborted by another task */
break;
case OS_ERR_OBJ_DEL:
/* The semaphore was deleted */
break;
default:
/* Other errors */
}
:
}
} |
Panel | ||
---|---|---|
| ||
(1) The task pends (or waits) on the semaphore by calling (2) The next argument is a timeout specified in number of clock ticks. The actual timeout depends on the tick rate. If the tick rate (see (3) The third argument specifies how to wait. There are two options: (4) When the semaphore is posted, µC/OS-III reads a “timestamp” and returns this timestamp when (5) (6) The resource can be accessed when (7) When finished accessing the resource, you simply call (8) (9) As with most µC/OS-III functions, you specify the address of a variable that will receive an error message from the call. |
Code Block | ||
---|---|---|
| ||
void Task2 (void *p_arg)
{
OS_ERR err;
CPU_TS ts;
while (DEF_ON) {
:
OSSemPend(&MySem, (1)
0,
OS_OPT_PEND_BLOCKING,
&ts,
&err);
switch (err) {
case OS_ERR_NONE:
Access Shared Resource;
OSSemPost(&MySem,
OS_OPT_POST_1,
&err);
/* Check "err" */
break;
case OS_ERR_PEND_ABORT:
/* The pend was aborted by another task */
break;
case OS_ERR_OBJ_DEL:
/* The semaphore was deleted */
break;
default:
/* Other errors */
}
:
}
} |
Panel | ||
---|---|---|
| ||
(1) Another task wanting to access the shared resource needs to use the same procedure to access the shared resource. |
Semaphores are especially useful when tasks share I/O devices. Imagine what would happen if two tasks were allowed to send characters to a printer at the same time. The printer would contain interleaved data from each task. For instance, the printout from Task 1 printing “I am Task 1,” and Task 2 printing “I am Task 2,” could result in “I Ia amm T Tasask k1 2”. In this case, you can use a semaphore and initialize it to 1 (i.e., a binary semaphore). The rule is simple: to access the printer each task must first obtain the resource’s semaphore. The figure below shows tasks competing for a semaphore to gain exclusive access to the printer. Note that a key, indicating that each task must obtain this key to use the printer, represents the semaphore symbolically.
Panel | ||
---|---|---|
| ||
The above example implies that each task knows about the existence of the semaphore to access the resource. It is almost always better to encapsulate the critical section and its protection mechanism. Each task would therefore not know that it is acquiring a semaphore when accessing the resource. For example, an RS-232C port is used by multiple tasks to send commands and receive responses from a device connected at the other end as shown in the figure below.
Panel | ||
---|---|---|
| ||
The function CommSendCmd()
is called with three arguments: the ASCII string containing the command, a pointer to the response string from the device, and finally, a timeout in case the device does not respond within a certain amount of time. The pseudo-code for this function is shown in the listing below.
Code Block | ||
---|---|---|
| ||
APP_ERR CommSendCmd (CPU_CHAR *cmd,
CPU_CHAR *response,
OS_TICK timeout)
{
Acquire serial port's semaphore;
Send "cmd" to device;
Wait for response with "timeout";
if (timed out) {
Release serial port's semaphore;
return (error code);
} else {
Release serial port's semaphore;
return (no error);
}
} |
Each task that needs to send a command to the device must call this function. The semaphore is assumed to be initialized to 1 (i.e., available) by the communication driver initialization routine. The first task that calls CommSendCmd()
acquires the semaphore, proceeds to send the command, and waits for a response. If another task attempts to send a command while the port is busy, this second task is suspended until the semaphore is released. The second task appears simply to have made a call to a normal function that will not return until the function performs its duty. When the semaphore is released by the first task, the second task acquires the semaphore and is allowed to use the RS-232C port.