没有合适的资源?快使用搜索试试~ 我知道了~
首页RTOS RTX(V1)keil自带的操作系统STM32可用
资源详情
资源评论
资源推荐

2018/11/17 Main Page
file:///C:/Keil_v5/ARM/Pack/ARM/CMSIS/5.4.0/CMSIS/Documentation/RTOS/html/index.html 1/1
CMSIS-RTOS Documentation
This manual describes the CMSIS-RTOS API Version 1 and the reference implementation CMSIS-RTOS
RTX which is designed for Cortex-M processor-based devices. The RTOS kernel can be used for creating
applications that perform multiple tasks simultaneously. These tasks are executed by threads that
operate in a quasi-parallel fashion.
While it is certainly possible to create real-time applications without an RTOS (by executing one or more
tasks in a loop), there are numerous scheduling, maintenance, and timing issues that can be solved
better with an RTOS. For example, an RTOS enables flexible scheduling of system resources like CPU and
memory, and offers methods to communicate between threads.
CMSIS-RTOS API programs are written using standard C/C++ constructs and are compiled with the
ARMCC, GCC, or IAR Compiler. The cmsis_os.h header file defines functions and macros that allow
declaring tasks and accessing all RTOS features easily.
This manual contains the following sections:
Revision History : Documents changes made in each version for CMSIS-RTOS API and RTX.
Generic RTOS Interface : Provides an overview about the CMSIS-RTOS API.
Using a CMSIS-RTOS Implementation : Provides generic instructions for using a CMSIS-RTOS
API compliant implementation.
Function Overview : Lists the CMSIS-RTOS API functions including RTX-specific extensions.
RTOS Validation : Describes the Software Pack that can be used to validate a CMSIS-RTOS
implementation.
RTX Implementation : Documents the open-source implementation CMSIS-RTOS RTX.
Note
An extended version of the CMSIS-RTOS API is available in CMSIS-RTOS v2.
CMSIS-RTOS in ARM::CMSIS Pack
The following files relevant to CMSIS-RTOS are present in the ARM::CMSIS Pack directories:
File/Folder Content
CMSIS/Documentation/RTOS This documentation
CMSIS/Documentation/RTOS2 CMSIS-RTOS API Version 2 documentation
CMSIS/RTOS/Template Header File Template: cmsis_os.h

2018/11/17 Revision History
file:///C:/Keil_v5/ARM/Pack/ARM/CMSIS/5.4.0/CMSIS/Documentation/RTOS/html/rtos_revisionHistory.html 1/2
Revision History
CMSIS-RTOS API
Version Description
V1.03 - only
documentation
changes
Incorporated documentation for reference implementation CMSIS-RTOS RTX.
V1.02 - only
documentation
changes
Added: Overview of the CMSIS-RTOS Validation Software Pack.
Clarified: Behaviour of Timout Value.
V1.02
Added: New control functions for short timeouts in microsecond resolution
osKernelSysTick, osKernelSysTickFrequency, osKernelSysTickMicroSec.
Removed: osSignalGet.
V1.01
Added capabilities for C++, kernel initialization and object deletion.
Prepared for C++ class interface. In this context to const attribute has been
moved from osXxxxDef_t typedefs to the osXxxxDef macros.
Added: osTimerDelete, osMutexDelete, osSemaphoreDelete.
Added: osKernelInitialize that prepares the Kernel for object creation.
V1.00
First official Release.
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.
V0.02 Preview Release.
CMSIS-RTOS RTX
Version Description
V4.82 Corrected: Recursive Mutex 16-bit lock counter is now checked to not overflow.
V4.81
Added provisions for Arm Compiler 6.
Corrected: Message Queue behavior when osMessagePut timed out due to full queue and
osMessageGet was called from ISR.
V4.80
Restored time delay parameter 'millisec' old behavior (before V4.79) for software
compatibility.
Corrected: implicit mutex release when mutex owner thread is terminated.
V4.79
Corrected: time delay parameter ‘millisec’ in all functions (osDelay, osSignalWait, …) is now
treated as lower bound – wait for at least time given (before it could have been up to 1ms
less).
Corrected: Lazy Context switching for Cortex-M4 with FPU could lead to a crash when
thread which used FPU was terminated.
Corrected: osMailCAlloc only cleared the allocated memory block if it was available without
waiting.
Corrected: osThreadCreate function returns NULL when trying to create more concurrent
threads than defined in the configuration.
Improved source code MISRA compliance.
V4.78
Corrected: osTimerStart function accepts full 32-bit range for time delay value in milisec.
Added: User Timer Callback Queue overflow reported through
os_error(OS_ERROR_TIMER_OVF).
V4.77 Added: Stack usage watermark.
V4.76
Optimized Service calls in GCC libraries.
Corrected: Stack/Heap regions can be used with scatter loading.
V4.75 Corrected: Service calls for Cortex-M4 with Floating Point for GCC.
Corrected: osSignalClear returns 0x80000000 when called from interrupt service routines.

2018/11/17 Revision History
file:///C:/Keil_v5/ARM/Pack/ARM/CMSIS/5.4.0/CMSIS/Documentation/RTOS/html/rtos_revisionHistory.html 2/2
Corrected: C standard library memory functions (malloc, free, ...) can be called between
calls to osKernelInitialize and osKernelStart.
Corrected: Interrupt Priority Group can be configured between calls to osKernelInitialize
and osKernelStart.
V4.74
Corrected: osKernelInitialize and osKernelStart when called from main which is already
a thread.
V4.73
Corrected: mutex priority inversion when thread owns more than one mutex.
Added: RTX extensions os_suspend and os_resume.
Added: RTX os_error template.
V4.72
Corrected: object initialization when defined inside function (allocated on stack and not as
static memory).
V4.71 Corrected: osMailFree behaviour when osMailAlloc timed out.
V4.70
Added: New control functions for short timeouts in microsecond resolution
osKernelSysTick, osKernelSysTickFrequency, osKernelSysTickMicroSec.
Removed: osSignalGet.
V4.61
Enhanced: osTimerCreate can now be called after osKernelInitialize (before only after
osKernelStart).
Corrected: Initialization of alternative kernel timer for Cortex-M0/M0+/M1 (when SysTick
timer is not used).
Corrected: Message/Mail Queue behavior when timeout expires.
V4.51
Corrected: problem with osKernelInitialize when after the call high priority threads are
defined.
V4.50
Based on CMSIS-RTOS API Version 1.01 and the classic RTX V4.50 Kernel.
Added: osTimerDelete, osMutexDelete, osSemaphoreDelete.
Added: osKernelInitialize that prepares the Kernel for object creation.
Added: support for Low Power Cortex-M applications based on new configuration
functions: os_suspend, os_resume.
Added: support for peripheral timer to be used as OS tick timer instead of Core SysTick
timer.
Corrected: stack checking did not work for os_tsk_delete_self function Preview Release.
V4.20 Initial CMSIS-RTOS adaption of the RTX Kernel.

2018/11/17 Generic RTOS Interface
file:///C:/Keil_v5/ARM/Pack/ARM/CMSIS/5.4.0/CMSIS/Documentation/RTOS/html/genRTOSIF.html 1/2
Generic RTOS Interface
The CMSIS-RTOS API is a generic RTOS interface for Arm® 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.
Thread Management allows you to define, create, and control threads.
Interrupt Service Routines (ISR) can call some 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:
Signal: is a flag that may be used to indicate 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.
Mutexes and Semaphores are incorporated.
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.

2018/11/17 Generic RTOS Interface
file:///C:/Keil_v5/ARM/Pack/ARM/CMSIS/5.4.0/CMSIS/Documentation/RTOS/html/genRTOSIF.html 2/2
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 shared 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 LDREX and STREX.
剩余111页未读,继续阅读

















安全验证
文档复制为VIP权益,开通VIP直接复制

评论1