CMSIS-RTOS2
Version 2.1.2
Real-Time Operating System: API and RTX Reference Implementation
|
Information about memory management possibilities. More...
The CMSIS-RTOS2 API offers two options for memory management the user can choose. For object storage one can either use
In order to affect the memory allocation scheme all RTOS objects that can be created on request, i.e. those having a osXxxNew
function, accept an optional osXxxAttr_t attr
argument on creation. As a rule of thumb the object attributes at least have members to assign custom control block memory, i.e. cb_mem
and cb_size
members. By default, i.e. attr
is NULL
or cb_mem
is NULL
, Automatic Dynamic Allocation is used. Providing a pointer to user memory in cb_mem
switches to Manual User-defined Allocation.
The automatic allocation is the default and viable for many use-cases. Moreover it is fully portable across different implementations of the CMSIS-RTOS2 API. The common drawback of dynamic memory allocation is the possibility of memory fragmentation and exhaustion. Given that all needed objects are created once upon system initialization and never deleted at runtime this class of runtime failures can be prevented, though.
The actual allocation strategy used is implementation specific, i.e. whether global heap or preallocated memory pools are used.
Code Example:
The Mutexes in this example are created using automatic memory allocation.
One can get fine grained control over memory allocation by providing user-defined memory. The actual requirements such user-defined memory are implementation specific. Thus one needs to carefully refer to the size and alignment rules of the implementation used, e.g. for RTX see Static Object Memory.
Code Example:
The above example uses user-defined memory for the mutex control block. Depending on the actual implementation used one needs to include the specific header file, rtx_os.h
in this case.