CMSIS-RTOS

You could try mbedOS. I believe it's based off CMSIS-RTOS. os.mbed.com/.../index.html

FreeRTOS can be also used with CMSIS-RTOS. I can put it this way, which one is better a native FreeRTOS or a FreeRTOS with CMSIS-RTOS?

BigG, why do you prefer mbedOS over FreeRTOS? Is it easy usage and mass libraries or are there any technical advantages? 

I used mbed platform long time ago it is good for fast prototyping but it has so many abstractions that hides many things like Arduino platforms. I want something that can be used for real-time applications which can be also certified if required. 

msimon said:

which one is better a native FreeRTOS or a FreeRTOS with CMSIS-RTOS?

I personally cannot answer that question as I've not spent much time learning about FreeRTOS. I am sure there are others like Jan Cumps who can provide expert opinion.

mbedOS is now much more mature. Up to version 6.15 the last time I checked. What I like about it is that it does not require you to set up the configuration settings to use it. It just works well for what I want to do. It is also very well structured and well documented so once you know the basics you can quickly move onto more advanced optimizations to suit your particular hardware. Based on the commercial applications I have seen, I cannot see why certification will be a problem. Also from what I've come across online, bare metal programming still tends to work better for time critical real-time applications.

Another newer packaged RTOS system for consideration is the Zephyr project. https://zephyrproject.org/

At the end of the day, it's complexity that wrecks most projects. Keeping it as simple as you can always pays dividends. So best of luck.

Thanks BigG. I agree that bare metal is the best but structuring and maintaining the code can be difficult in a complex system. A schedular can simplifies things significantly. 

I also heard that Zephyr is getting popular. I need to keep eye on it. Btw, I am not developing a product, I am preparing a course. I want something commercial and mature so students can benefit. 

Aha, I see. Not sure if you've come across this site. Has a useful overview of the different options out there. https://www.osrtos.com/

Appears fairly up to date. Looking through the list I've come across TinyOS, ContikiOS and then MongooseOS for ESP32/ESP8266. TI have a version too: www.ti.com/.../TI-RTOS-MCU (and oops almost forgot https://www.silabs.com/developers/micrium)

Then I know Microsoft are pushing their own commercial RTOS too, by way of Azure RTOS (https://azure.microsoft.com/en-us/services/rtos/) and AWS offer their version of freeRTOS too (aws.amazon.com/.../).

Hope that helps.

PS. speaking of courses have you seen this one from ARM: www.arm.com/.../real-time-operating-systems

Thanks for the sources BigG. I didn't see osrtos that is an interesting site thanks. 

Personally, I love TI MSPs. Though they are not user friendly, you learn the underlying system. But, we have STM32 boards, that is one of the reason TI-RTOS is not an option. Micrium is also a good option as it is the other widely used RTOS.

Yes, I am aware of ARM courses. That is one of the sources I will follow for the background work. 

MBED OS and CMSIS-RTOS are changing so fast that I can't follow anymore what they are, what they wrap and what they are based upon 

I know TI-RTOS and FreeRTOS fairly well. Although they are completely different, I find it easy to switch and port between the two, because the concepts are the same:

• scheduler
• tasks
• messages and queues
• semaphores
• events (between tasks)

If I had to make a training :) that's targeting a particular vendor or controller, I'd choose an OS that has good examples from that vendor.
If you then build a training example for the concepts above, I think you handle the 80% that's common between all of the RTOSes. 

Thanks  Jan Cumps. Therefore, I think it is better to go with native FreeRTOS. I am targeting STM32 because we have STM32 kits but I want it to be vendor independent. I think FreeRTOS is not bad as it can support many vendors.

As you mentioned, schedulers, tasks, semaphores, mutex, messages, events, interrupts are main elements and I want to cover those. Those are fundamentals. I just want to make sure, the thing I am teaching is the most beneficial. 

Normally I don't pay much attention to emailed newsletters but this one caught my eye as the latest from ST mentions Azure RTOS with STM32F7.

www.st.com/.../x-cube-azrtos-f7.html

Self promotion :) : balearicdynamics and I made a project last year, with FreeRTOS, that uses most of the principles there:

• scheduler and task
• semaphore/mutex
• message queue
• events and inter-task messages
• tasks going to sleep
• interrupt 

additional:

• controller going to low power
• controller wakes up via HW interrupt when data arrives on UART and kicks off a message.
• wifi
• AWS IoT / MQTT

Self promotion :) : balearicdynamics and I made a project last year, with FreeRTOS, that uses most of the principles there:

• scheduler and task
• semaphore/mutex
• message queue
• events and inter-task messages
• tasks going to sleep
• interrupt 

additional:

• controller going to low power
• controller wakes up via HW interrupt when data arrives on UART and kicks off a message.
• wifi
• AWS IoT / MQTT

Thanks Jan Cumps. It looks like a good example of RTOS project. I will also investigate low power RTOS design but I have a long way to go before I dive into it. 

This part is most of the time vendor dependent.
What is independent: telling FreeRTOS what sleep modes are allowed. FreeRTOS knows when a next job is due and will know how to wake up.
What is dependent: how you work with HW drivers in low power and wake up FreeRTOS when a HW event happens. Like most of the HW/driver logic, this is not abstracted by the RTOS.