What is the difference between FreeRTOS and CMSIS-RTOS? Can anyone explain how the two RTOSes are similar or different?
3 Answers
I think the source of confusion here is that there exists CMSIS-RTOS API (v1 and v2), and there is CMSIS-RTOS RTX, which is a standalone OS for ARM (and made by ARM), which implements that very API.
The idea was to create a common abstraction layer for RTOSes, so if one is not happy with FreeRTOS queues - he/she can choose another implementation of the same RTOS API without changing his/her firmware sources a lot.
Although I think RTOS makers will violate CMSIS-RTOS as much as MCU vendors violate CMSIS Driver API, I personally prefer CMSIS-RTOS API. There should be a number of wrappers that provide a layer of compatible macros to make existing RTOSes compatible with CMSIS-RTOS API. I'm only aware of PolyMCU attempts:
I have used RTX before CMSIS included the RTOS specification, and have compared it to FreeRTOS. At that time RTX was somewhat more primitive particularly in respect to its support for timers. I do not know whether that has changed in CMSIS-RTX.
Both use pre-emptive priority based scheduling and in that sense are "traditional", however internal design of FreeRTOS is somewhat unusual. In most RTOS the fundamental primitive from which all other API services are created is the mutex, in FreeRTOS however the fundamental primitive is the queue. Consequently "simple" primitives such as semaphores and mutexes are created from the more complex queue - rather then perhaps more intuitively complex things being built form simple things. I would imagine that this design has some impact on performance. Even without that I found that even context switches in FreeRTOS took significantly longer that RTX (15us vs 5us on a Cortex-M3 at 72MHz).
FreeRTOS is of course "free", while RTX is included in licensed commercial development tools from Keil. If you are using those tools there there is some degree of RTOS aware support for RTX within the IDE and debugger which may be helpful in development, though not perhaps essential.

- 88,407
- 13
- 85
- 165
-
1Worth noting that this unusual idea of "everything is a queue" results in the fact that a mutex or semaphore usually takes 3-4x times more RAM in FreeRTOS than in any other RTOS. – Freddie Chopin Jan 26 '17 at 15:53
-
1It is also worth noting that the context switch time of FreeRTOS depends on many things (as with all RTOS), such as stack checking, run time stats etc. It it worth looking at the "What is the context switch time" of http://www.freertos.org/FAQMem.html. It is a lot more efficient than you think! – Realtime Rik Jan 27 '17 at 13:41
-
2@RealtimeRik : Of the suggestions for optimising context switch, I may not have used "configUSE_PORT_OPTIMISED_TASK_SELECTION=1" - it may have already been set in the port I used - one would imagine so. Other than that possibility, it was a like-for-like comparison. The FAQ does not document what was timed for the 84 CPU cycles; my timings were taken from the blocking of one task to the unblocking of another at the user C code level - that is from the call to the blocking function of one task until the return from the blocking function of the other, so includes any IPC API overhead. – Clifford Jan 27 '17 at 14:56
Basically FreeRTOS is a RTOS, while CMSIS-RTOS is only a wrapper for any RTOS (like FreeRTOS, CMSIS-RTOS RTX or anything you want).

- 8,440
- 2
- 28
- 58