Table C-13 shows the difference in API for semaphore management.
µC/OS-II ( |
µC/OS-III ( |
Note |
|
|
(1) |
|
|
(2) |
|
|
|
|
|
(3)
|
|
|
|
|
|
|
|
|
(4) |
|
|
|
Table C-13 Semaphore Management API
TC-13(1) In µC/OS-III, there is no “accept” API since this feature is built into the OSSemPend()
by specifying the OS_OPT_PEND_NON_BLOCKING
option.
TC-13(2) In µC/OS-II, OSSemCreate()
returns the address of an OS_EVENT
, which is used as the “handle” to the semaphore. In µC/OS-III, the application must allocate storage for an OS_SEM
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.
TC-13(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 the OS_SEM
object signaled. The receiver of the signal therefore knows when the signal was sent.
TC-13(4) µC/OS-III does not provide query services, as they were rarely used.