CMSIS RTOS v2 Portability Layer - Thread Stack Size

[htcrane]

From my embedded systems experience, when I use an RTOS I configure the OS buffer size and can divvy that up however I wish. For example I create 3 threads of various sizes say 1KB, 2 KB, 3KB (6KB of threads in total) and as long as the total is below the OS buffer size all is well. This is also the approach the CMSIS RTOSv2 wrapper takes when creating a thread where the osThreadAttr_t member stack_mem is NULL. The programmer specifes the stack size in bytes via the stack_size member. CMSIS expects the underlying OS to allocate "the memory for the stack is provided by the system based on the configuration of underlying RTOS kernel" per the CMSIS documentation.

However, Zephyr's implementation decides not to follow so nor documents the deviation from this...

Zephyr's implementation decides that dynamic allocation will not follow CMSIS's documentation and instead allocates a stack array of CMSIS_V2_THREAD_DYNAMIC_STACK_SIZE by CMSIS_V2_THREAD_DYNAMIC_MAX_COUNT. Zephyr does not respect the requested thread stack size, rather yielding each thread to be the same size. To our example above, I would have to set the dynamic size in the KConfig to be 3KB, each thread takes 3KB for 9KB in total with a third being wasted space.

Looking through the commit history of the thread.c file for CMSIS RTOS v2, the only hint I can find as to why is a message from 2019. Why not allocate a CMSIS heap to use for thread creation, like other RTOSs, and divvy up based on the requested size instead of silently assigning a static size? For alignment purposes, could just round the programmer provided size up to the nearest valid aligned size when threads are created with dynamic memory. Am I missing something?

[ndrs-pst]

@htcrane The interpretation of the following may be ambiguous:

void * stack_mem (Memory for Stack)
Pointer to a memory location for the thread stack (64-bit aligned).
Default: NULL - The memory for the stack is provided by the system based on the configuration of the underlying RTOS kernel.

uint32_t stack_size (Size of Stack)
The size (in bytes) of the stack specified by stack_mem.
Default: 0 - No memory is provided with stack_mem by default.

When stack_mem is NULL, it is mentioned that the stack is provided by the underlying RTOS. This implies that the stack_size parameter is irrelevant in this case, as the stack size is determined by the RTOS configuration, not by stack_size.

However, if both defaults are combined—stack_mem is NULL and stack_size is 0—it means that the stack size and allocation are based on the underlying RTOS kernel.

---

Anyway, Zephyr RTOS is a good platform to adopt, and the benefits of CMSIS RTOS are minimal compared to the extensive ecosystem provided by Zephyr. 🚀

[htcrane]

I do not believe that ignoring input parameters will be a good practice, nor what is meant...

1. Having a stack_size as a function parameter but ignoring it, especially when documentation provides no exceptions on when it will be ignored, does not make sense. Why have a parameter that is always unused?
2. The stack memory being provided by the underlying RTOS's configuration may refer to the memory region used or defaults. CMSIS RTOS is developed by ARM, who also provides the RTX RTOS. We can look at their source code for the CMSIS RTOS wrapper for RTX to better understand the configuration. See lines 903 to 916 within the new thread function. We see that if stack_mem is NULL the user's requested stack size is respected when provided.
   • user provides stack_size that size is allocated.
   • user does not provide a stack_size, a default thread stack size is used.
3. Looking at other code bases for embeded systems, in their provided CMSIS RTOS wrapper they respect the stack_size parameter.
   • FreeRTOS: Respects the stack_size and allocates said space. Code here.
   • ESP Uses FreeRTOS and thus can support the wrapper above.
   • Mbed OS: Uses RTX as the underlying RTOS with the CMSIS RTOS wrapper mentioned above.
4. In the detailed CMSIS RTOS interface guidance, memory management states, "actual allocation strategy used is implementation specific, i.e. whether global heap or preallocated memory pools are used". Both a heap and pool allocation structure allow for allocation sizes to be dynamically used.

The purpose of CMSIS RTOS is to provide a wrapper so applications can be RTOS independent. I will be opening a PR with updates to Zephyr's implementation to follow expected behavior of CMSIS RTOS. Also, I will be updating some of the ISR restrictions as it appears the Zephyr kernel has better support within ISRs at this time.

--
I work with applications that are independent of the base RTOS, hence CMSIS RTOS. Zephyr does not support all features of the MCUs that I need nor is as memory/speed optimized as platforms I currently use. Two quick examples, if one was to use a microSD card for data storage:

• Zephyr when using FatFS seeks to the end of a file when writing, on every single write. FatFS does not allow multiple file handles to be opened to the same file, unless in read-only mode (see duplicated file open). So not sure why the seek is occurring when only one handle can be opened for writing and this cuts the speed of write operations in half (based on my testing). Additionally, for wearable or battery constrained systems, more accesses to the SD card to seek will reduce battery life.
• SD SPI has 0.5KB of ROM dedicated to just ensuring Zephyr keeps MOSI high during read operations. The SD physical layer specification, version 9.10, chapter 7 does not specify that the MOSI pin must be in a specific high or low state during read transactions. If anything, SPI should allow a pin to latch high rather than having to use large buffers of dummy data.

[ndrs-pst]

Thank you for your detailed and insightful response. Your explanation about the stack_size parameter and its handling across different RTOS implementations is very clear. I appreciate the points you made about FreeRTOS, ESP, Mbed OS, and Zephyr.

• About SD SPI, I noticed that the problem stems from the SPI driver itself sending 0x00 as dummy data instead of 0xFF. Ping @danieldegrasse if you have any insight about this?

[danieldegrasse]

When I implemented the SD SPI driver I used the existing SDHC SPI driver (which implemented SD protocol support and the SPI SDHC controller) as a guide, and this driver used the same approach. We need to write 0xFF while we read data from the SD card, Linux does the same thing (see here: https://github.com/torvalds/linux/blob/master/drivers/mmc/host/mmc_spi.c#L423). The signalling diagrams in the SD specification do indicate that the data in line (MOSI) must be held high when sending a command with an R1b (busy signal) response type, until the card stops sending the busy signal in response.

[ndrs-pst]

Thank you for your insight. Although addressing the issue of using 0.5 KiB of ROM on 0xff dummy data in the sdhc_spi.c is a point of improvement, my interests may not align with implementing widespread modifications.

However, the solutions that come to mind are:

• Changing the default dummy data to 0xff across all drivers/spi, which would require significant effort
  since various devices may have their own limitations.
• Overriding the MOSI pin to latch high as @htcrane suggested, but this may need a method to identify the MOSI pin in the SPI driver.

[ndrs-pst]

FYI 👀, @htcrane PR #75804

[htcrane]

Thank you both!