Porting Overview
- Former user (Deleted)
- WES Admin
μC/USB-Device uses some RTOS abstraction ports to interact with the RTOS. Instead of being a simple wrapper for common RTOS service functions (TaskCreate(), SemaphorePost(), etc...), those ports are in charge of allocating and managing all the OS resources needed. All the APIs are related to the μC/USB-Device module feature that uses it. This offers you a better flexibility of implementation as you can decide which OS services can be used for each specific action. Table - Comparison between a wrapper and a features-oriented RTOS port gives an example of comparison between a simple RTOS functions wrapper port and a features-oriented RTOS port.
| Operation | Example of feature-oriented function (current implementation) | Equivalent function in a simple wrapper (not used) |
|---|---|---|
| Create a task | The stack is not in charge of creating tasks. This should be done in the RTOS abstraction layer within a USBD_OS_Init() function, for example. | USBD_OS_TaskCreate(). The stack would need to explicitly create the needed tasks and to manage them. |
| Create a signal for an endpoint | USBD_OS_EP_SignalCreate(). Another OS service than a typical Semaphore can be used. | USBD_OS_SemCreate(). The stack would need to explicitly choose the OS service to use. |
| Create a lock for an endpoint. | USBD_OS_EP_LockCreate(). Another OS service than a mutex can be used. | USBD_OS_MutexCreate(). The stack would need to explicitly choose the OS service to use. |
| Put a core event in a queue | USBD_OS_CoreEventPut(). If you prefer not using typical OS queues, you could still implement it using a chained list and a semaphore, for instance. | USBD_OS_Q_Post(). Again, the stack would need to explicitly choose the OS service to use. |
Because of the features oriented RTOS port design, some μC/USB-Device modules will need their own OS port. These modules are listed here:
- μC/USB-Device core layer
- Audio Class
- Human Interface Device Class (HID)
- Mass Storage Class (MSC)
- Personal Healthcare Device Class (PHDC)
Moreover, all the demo applications for each USB class that Micrium provides interact with the RTOS. The demo applications do not benefit from an RTOS port. Therefore, if you plan to use them with an RTOS other than μC/OS-II or μC/OS-III, you will have to modify them.
Figure - µC/USB-Device architecture with RTOS interactions summarizes the interactions between the different μC/USB-Device modules and the RTOS.
