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 are 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 switched in FreeRTOS took significantly longer that RTX (15us ve 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.