The CMSIS-RTOS API is a generic RTOS interface for Cortex-M processor-based devices. CMSIS-RTOS provides a standardized API for software components that require RTOS functionality and gives therefore serious benefits to the users and the software industry.
- CMSIS-RTOS provides basic features that are required in many applications or technologies such as UML or Java (JVM).
- The unified feature set of the CMSIS-RTOS API simplifies sharing of software components and reduces learning efforts.
- Middleware components that use the CMSIS-RTOS API are RTOS agnostic. CMSIS-RTOS compliant middleware is easier to adapt.
- Standard project templates (such as motor control) of the CMSIS-RTOS API may be shipped with freely available CMSIS-RTOS implementations.
- Note:
- The CMSIS-RTOS API defines a minimum feature set. Implementations with extended features may be provided by RTOS vendors.
CMSIS-RTOS API Structure
A typical CMSIS-RTOS API implementation interfaces to an existing Real-Time Kernel. The CMSIS-RTOS API provides the following attributes and functionalities:
- Function names, identifiers, and parameters are descriptive and easy to understand. The functions are powerful and flexible which reduces the number of functions exposed to the user.
- Interrupt Service Routines (ISR) can call many CMSIS-RTOS functions. When a CMSIS-RTOS function cannot be called from ISR context, it rejects the invocation.
- Three different thread event types support communication between multiple threads and/or ISR:
- Signals: are flags that may be used to signal specific conditions to a thread. Signals can be modified in an ISR or set from other threads.
- Message: is a 32-bit value that can be sent to a thread or an ISR. Messages are buffered in a queue. The message type and queue size is defined in a descriptor.
- Mail: is a fixed-size memory block that can be sent to a thread or an ISR. Mails are buffered in a queue and memory allocation is provided. The mail type and queue size is defined in a descriptor.
- CPU time can be schedule with the following functionalities:
- A timeout parameter is incorporated in many CMSIS-RTOS functions to avoid system lockup. When a timeout is specified, the system waits until a resource is available or an event occurs. While waiting, other threads are scheduled.
- The osDelay function puts a thread into the state WAITING for a specified period of time.
- The generic osWait function waits for events that are assigned to a thread.
- The osThreadYield provides co-operative thread switching and passes execution to another thread of the same priority.
The CMSIS-RTOS API is designed to optionally incorporate multi-processor systems and/or access protection via the Cortex-M Memory Protection Unit (MPU).
In some RTOS implementations threads may execute on different processors and Mail and Message queues can therefore reside in shard memory resources.
The CMSIS-RTOS API encourages the software industry to evolve existing RTOS implementations. Kernel objects are defined and accessed using macros. This allows differentiation. RTOS implementations can be different and optimized in various aspects towards the Cortex-M processors. Optional features may be for example:
- Generic Wait function; i.e. with support of time intervals.
- Support of the Cortex-M Memory Protection Unit (MPU).
- Zero-copy mail queue.
- Support of multi-processor systems.
- Support of a DMA controller.
- Deterministic context switching.
- Round-robin context switching.
- Deadlock avoidance, for example with priority inversion.
- Zero interrupt latency by using the Cortex-M3/M4 instructions LDEX and STEX.
Revision History of CMSIS-RTOS API
| Version | Description |
| V0.02 | Preview Release. |
| V0.03 | Added: osKernelStart; starting 'main' as a thread is now an optional feature.
Semaphores have now the standard behavior.
osTimerCreate does no longer start the timer. Added: osTimerStart (replaces osTimerRestart).
Changed: osThreadPass is renamed to osThreadYield. |
