Open ad3154 opened 6 months ago
sonarcloud[bot]
commented
5 months ago 
Quality Gate passedIssues
0 New issues
0 Accepted issues
Measures
0 Security Hotspots
100.0% Coverage on New Code
21.9% Duplication on New Code
ad3154
commented
5 months ago Marking as ready since it's now tested. It's a bit more invasive than I expected I guess, but latching onto the CMSIS abstraction for RTOSes seems very valuable, as it should give us very easy access to:
Describe your changes
This is an attempt to provide support for embedded RTOSes that use the CMSIS RTOS 2 abstraction, such as FreeRTOS, Keil RTX, and others.
My thinking is that this is 50 percent of the battle to supporting STM32 and other small ARM devices, with the other half being hardware plugins with specific HAL integrations for each micro.
In order to actually consume this, you'd need to also implement a proper hardware time-base for the stack using a hardware timer on those devices, which maybe we could also provide as part of a CAN plugin eventually. Additionally, you'd also need to start the RTOS before using the stack, which I think is acceptable (osKernelInitialize, and osKernelStart).
Either way, the point is, CMSIS RTOS2 is a common RTOS abstraction which would be nice to support.
The CMSIS RTOS 2 API is documented here
I added some super obvious infinite loops to catch issues between us and the kernel. I used loops because assert may not be supported on the target platforms, and since this file is included in the logger, I can't emit any log output here.
How has this been tested?
This is a draft until I can test it. I have a cheap STM32L4 eval board coming to help test it. Will update once I have more to share.Tested on STM32L476 Nucleo dev kit with an external CAN transceiver running FreeRTOS and CMSIS 6.0 via the CMSIS_RTOS2 api.
The dev kit loaded the VT example and worked normally, even using > 1 thread as expected when used with the stm32l4 plugin which is not yet merged in,.