I am currently on a project that has existing code that's using the CMSIS RTOS2 API.
In particular, it's using RTX 5 which is interesting to me because of this statement: "RTX does not disable interrupts during critical sections for Armv7-M and Armv8-M architecture based devices, but rather uses atomic operations."
"
I don't know if this is really unique or not.
Also, since this API has a FreeRTOS wrapper (https://github.com/ARM-software/CMSIS-FreeRTOS), it could act as an RTOS portability layer for QP and perhaps hide some of the ugliness of the FreeRTOS API.
So, any thoughts about a port to this API?
Thanks,
Dominic
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi Dominic,
The RTX5 RTOS is an interesting porting target for QP/C/C++. This seems to be how RTOS is "supposed to be" designed for ARM, where each RTOS API runs in the context of the SVC exception. This way, you have the separation between the "Privileged" system code and "User" thread code. That's also why the RTX does not need to disable interrupts explicitly.
I'd need to look deeper under the hood to understand the prioritization of the SVC exception and how it interacts with the IRQ exceptions. For porting QP to this RTOS, perhaps the most interesting aspect would be to understand how to implement the critical section in this design (most likely some SVC service.)
--MMS
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Great! I was hoping (selfishly) that you would find it interesting.
It makes sense that ARM of all people would know how to use their architecture.
But my question was more about porting QP to the CMSIS RTOS2 API .
I would assume (perhaps incorrectly) that if QP could call the CMSIS RTOS2 API, it could use either the RTX5 or the FreeRTOS kernel implementations of it.
Thanks,
Dominic
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I'm frankly a little confused about all these RTOS APIs. There is this CMSIS RTOS API, there is RTX5, and there is also mbed RTOS. They all seem related, but I'm not sure how close.
As far as the universality of the CMSIS RTOS2 API, I frankly doubt it. Every "compliant" implementation has its gotchas, so I wouldn't trust that it would fix, say the bizarre design of "fromISR" stuff in FreeRTOS.
--MMS
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi Miro,
I am currently on a project that has existing code that's using the CMSIS RTOS2 API.
In particular, it's using RTX 5 which is interesting to me because of this statement:
"RTX does not disable interrupts during critical sections for Armv7-M and Armv8-M architecture based devices, but rather uses atomic operations."
"
I don't know if this is really unique or not.
Also, since this API has a FreeRTOS wrapper (https://github.com/ARM-software/CMSIS-FreeRTOS), it could act as an RTOS portability layer for QP and perhaps hide some of the ugliness of the FreeRTOS API.
So, any thoughts about a port to this API?
Thanks,
Dominic
Hi Dominic,
The RTX5 RTOS is an interesting porting target for QP/C/C++. This seems to be how RTOS is "supposed to be" designed for ARM, where each RTOS API runs in the context of the SVC exception. This way, you have the separation between the "Privileged" system code and "User" thread code. That's also why the RTX does not need to disable interrupts explicitly.
I'd need to look deeper under the hood to understand the prioritization of the SVC exception and how it interacts with the IRQ exceptions. For porting QP to this RTOS, perhaps the most interesting aspect would be to understand how to implement the critical section in this design (most likely some SVC service.)
--MMS
Great! I was hoping (selfishly) that you would find it interesting.
It makes sense that ARM of all people would know how to use their architecture.
But my question was more about porting QP to the CMSIS RTOS2 API .
I would assume (perhaps incorrectly) that if QP could call the CMSIS RTOS2 API, it could use either the RTX5 or the FreeRTOS kernel implementations of it.
Thanks,
Dominic
I'm frankly a little confused about all these RTOS APIs. There is this CMSIS RTOS API, there is RTX5, and there is also mbed RTOS. They all seem related, but I'm not sure how close.
As far as the universality of the CMSIS RTOS2 API, I frankly doubt it. Every "compliant" implementation has its gotchas, so I wouldn't trust that it would fix, say the bizarre design of "fromISR" stuff in FreeRTOS.
--MMS
To paraphrase Andrew Tanenbaum's quote about standards:
It's maddening. The last time I looked at Micrium's API for creating a task, I think it took 13 arguments...
Last edit: Panopticon 2023-08-02