When creating Zephyr RTOS objects like mutex, timers or message queues via CMSIS-RTOSv2 API, there are two options for the users to choose - dynamic allocation or RTOS implementation-specific static allocation. Dynamic allocation is what's currently supported by Zephyr portability layer with static allocation left unimplemented.
It is a hassle to keep a track of how many RTOS objects a project might be using. With dynamic allocation, we need to declare this via configs like CONFIG_CMSIS_V2_MUTEX_MAX_COUNT. Either memory is getting wasted by allocating huge pools which are not fully used, or these configs need manual update as different libraries get added/removed to a project.
Proposed change
The above will not be a problem if Zephyr's CMSIS-RTOSv2 port supports static memory allocation. I plan on
Support passing in struct cv2_mutex equivalent types in .cb_mem field of CMSIS-RTOSv2 osxxxAttr_t objects. If the projects passes in cv2_mutex object, when Zephyr portability layer would not need to allocate this object from a buffer.
Dependencies
This would not impact existing use of dynamic allocation for creating RTOS objects via CMSIS-RTOSv2.
Concerns and Unresolved Questions
Let me know of any concerns or ideas, otherwise I am creating a pull request implementing this proposal.
Introduction
When creating Zephyr RTOS objects like mutex, timers or message queues via CMSIS-RTOSv2 API, there are two options for the users to choose - dynamic allocation or RTOS implementation-specific static allocation. Dynamic allocation is what's currently supported by Zephyr portability layer with static allocation left unimplemented.
Problem description
It is a hassle to keep a track of how many RTOS objects a project might be using. With dynamic allocation, we need to declare this via configs like
CONFIG_CMSIS_V2_MUTEX_MAX_COUNT
. Either memory is getting wasted by allocating huge pools which are not fully used, or these configs need manual update as different libraries get added/removed to a project.Proposed change
The above will not be a problem if Zephyr's CMSIS-RTOSv2 port supports static memory allocation. I plan on
<zephyr/portability/cmsis_os2_types.h>
.struct cv2_mutex
equivalent types in.cb_mem
field of CMSIS-RTOSv2osxxxAttr_t
objects. If the projects passes incv2_mutex
object, when Zephyr portability layer would not need to allocate this object from a buffer.Dependencies
This would not impact existing use of dynamic allocation for creating RTOS objects via CMSIS-RTOSv2.
Concerns and Unresolved Questions
Let me know of any concerns or ideas, otherwise I am creating a pull request implementing this proposal.