Table C-13 The table below shows the difference in API for semaphore management.
| Panel |
|---|
|
µC/OS-II (os_sem.c) | µC/OS-III (os_sem.c) | Note |
|---|
INT16U |
|
...
...
...
...
...
...
...
...
...
...
OS_ERR *p_err); | (2) | OS_EVENT * |
|
...
...
...
INT8U opt,
...
INT8U opt,
INT8U *perr); | OS_OBJ_QTY, |
|
...
...
...
...
...
...
...
...
INT32U timeout,
...
INT32U timeout,
INT8U *perr); | OS_SEM_CTR |
|
...
...
...
...
...
...
INT8U
OSSemPendAbort(
INT8U
OSSemPendAbort(
OS_EVENT *pevent, |
|
...
INT8U opt,
...
INT8U opt,
INT8U *perr); | OS_OBJ_QTY |
|
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
OS_SEM_DATA *p_sem_data); |
|
...
...
...
...
INT16U cnt,
...
INT16U cnt,
INT8U *perr); | void |
|
...
...
...
...
Table C-13 Semaphore Management API
...
...
|
(1) In µC/OS-III, there is no “accept” API since this feature is built into |
...
...
...
the OS_OPT_PEND_NON_BLOCKING |
...
...
(2) In µC/OS-II, OSSemCreate() |
...
...
an OS_EVENT, which is used as the “handle” to the semaphore. In µC/OS-III, the application must allocate storage for |
...
...
object, which serves the same purpose as |
...
the OS_EVENT. The benefit in µC/OS-III is that it is not necessary to predetermine the number of semaphores at compile time. |
...
(3) µC/OS-III returns additional information when a semaphore is signaled. The ISR or task that signals the semaphore takes a snapshot of the current timestamp and stores this in |
...
...
object signaled. The receiver of the signal therefore knows when the signal was sent. |
...
(4) µC/OS-III does not provide query services, as they were rarely used. |