CMSIS-RTX介绍

eric2013

The CMSIS-RTOS API is a generic RTOS interface for Cortex-M processor-baseddevices. CMSIS-RTOS provides a standardized API for software components thatrequire RTOS functionality and gives therefore serious benefits to the users andthe software industry.

[li]CMSIS-RTOS provides basic features that are required in many applications ortechnologies such as UML or Java (JVM).[/li][li]The unified feature set of the CMSIS-RTOS API simplifies sharing of softwarecomponents and reduces learning efforts.[/li][li]Middleware components that use the CMSIS-RTOS API are RTOS agnostic.CMSIS-RTOS compliant middleware is easier to adapt.[/li][li]Standard project templates (such as motor control) of the CMSIS-RTOS API maybe shipped with freely available CMSIS-RTOS implementations. [/li]

NoteThe CMSIS-RTOS API defines a minimum feature set. Implementations withextended features may be provided by RTOS vendors. A typical CMSIS-RTOS API implementation interfaces to an existing Real-TimeKernel. The CMSIS-RTOS API provides the following attributes andfunctionalities:

[li]Function names, identifiers, and parameters are descriptive and easy tounderstand. The functions are powerful and flexible which reduces the number offunctions exposed to the user. [/li]

[li]ThreadManagement allows to define, create, and control threads. [/li]

[li]Interrupt Service Routines (ISR) can call many CMSIS-RTOS functions. When aCMSIS-RTOS function cannot be called from ISR context, it rejects theinvocation. [/li]

[li]Three different thread event types support communication between multiplethreads and/or ISR:Signals: are flags that may be used to signal specific conditions toa thread. Signals can be modified in an ISR or set from other threads.[/li][li]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 ina descriptor.[/li][li]Mail: is a fixed-size memory block that can be sent to a thread or anISR. Mails are buffered in a queue and memory allocation is provided. The mailtype and queue size is defined in a descriptor. [/li]

[li]MutexManagement and SemaphoreManagement are incorporated. [/li]

[li]CPU time can be schedule with the following functionalities:A timeout parameter is incorporated in many CMSIS-RTOS functions toavoid system lockup. When a timeout is specified, the system waits until aresource is available or an event occurs. While waiting, other threads arescheduled.[/li][li]The osDelayfunction puts a thread into the state WAITING for a specified period oftime.[/li][li]The generic osWaitfunction waits for events that are assigned to a thread.[/li][li]The osThreadYieldprovides co-operative thread switching and passes execution to another thread ofthe same priority. [/li]

The CMSIS-RTOS API is designed to optionally incorporate multi-processorsystems and/or access protection via the Cortex-M Memory Protection Unit(MPU).
In some RTOS implementations threads may execute on different processors andMail and Message queues can therefore reside in shard memoryresources.
The CMSIS-RTOS API encourages the software industry to evolve existing RTOSimplementations. Kernel objects are defined and accessed using macros. Thisallows differentiation. RTOS implementations can be different and optimized invarious aspects towards the Cortex-M processors. Optional features may be forExample

[li]Generic Wait function; i.e. with support of time intervals.[/li][li]Support of the Cortex-M Memory Protection Unit (MPU).[/li][li]Zero-copy mail queue.[/li][li]Support of multi-processor systems.[/li][li]Support of a DMA controller.[/li][li]Deterministic context switching.[/li][li]Round-robin context switching.[/li][li]Deadlock avoidance, for example with priority inversion.[/li][li]Zero interrupt latency by using the Cortex-M3/M4 instructions LDEX and STEX.  [/li]