Question

I am looking for RTOS for Arm M/R series (developing in C++) ?
Can someone recommend on good RTOS for ARM Cortex-M or R series?
Thank you.

Answer 1

Getting an answer of any value would require someone to have objectively evaluated all of them, and that is unlikely.

Popularity and suitability are not necessarily the same thing. You should select the RTOS that has the features your application needs, works with your development tools, and for which the licensing model and costs that meet your needs and budget.

The tool-chain you use is a definite consideration – kernel aware debugging and start-up projects are all helpful in successful development. Some debugger/RTOS combinations may even allow thread-level breakpoints and debugging.

Keil’s MDK-ARM includes a simple RTOS with priority based pre-emptive scheduling and inter-process communication as well as a selection of middleware such as a file system, and TCP/IP, CAN and USB stacks included at no extra cost (unless you want the source code).

IAR offer integrations with a number of RTOS products for use with EWB. Their ARM EWB page lists the RTOSes with built-in and vendor plug-in support.

Personally I have used Keil RTX but switched to Segger embOS because at the time RTX was not as mature on Cortex-M and caused me a few problems. Measured context switch times for RTX were however faster than embOS. It is worth noting that IAR’s EWB integrates with embOS so that would probably be the simpler route if you have not already invested in a tool-chain. I have also evaluated FreeRTOS (identical to OpenRTOS but with different licensing and support models) on Cortex M, but found its API to be a little less sophisticated and complete than embOS, and with significantly slower context switch times.

embOS has similar middleware support to RTX, but at additional cost. However I managed to hook in an alternative open source file system and processor vendor supplied USB stack without any problems in both embOS and RTX, so middleware support may not be critical in all cases.

Other options are Micro C/OS-II. It has middleware support again at additional cost. Its scheduler is a little more primitive than most others, requiring that every thread have a distinct priority level, and this does not support round-robin/time-slice scheduling which is often useful for non-realtime background tasks. It is popular largely through the associated book that describes the kernel implementation in detail. The newer Micro C/OS-III overcomes the scheduler limitations.

To the other extreme eCos is a complete RTOS solution with high-end features that make it suitable for many applications where you might choose say Linux but need real-time support and a small footprint.

The point is that you can probably take it as read that an RTOS supports pre-emptive scheduling and IPC, and has a reasonable performance level (although I mentioned varying context switch times, the range was between 5 and 15 us at 72MHz on an STM32F1xx). So I would look at things like maturity (how long as the RTOS been available for your target -you might even look at release notes to see how quickly it reached maturity and what problems there may have been), tool integration, whether the API suits your needs an intended software architecture, middleware support wither from the vendor or third-parties and licensing (can you afford it, and can you legally deploy it in the manner you intend?).

With respect to using C++, most RTOSes present a C API (even eCos which is written in C++). This is not really a problem since C code is interoperable with C++ at the binary level, however you can usefully leverage the power of C++ to make the RTOS choice less critical. What I have done is define a C++ RTOS class library that presents a generic API providing the facilities that need; for example I have classes such as cTask, cMutex, cInterrupt, cTimer, cSemaphore etc. The application code is written to this API, and the class library implemented for any number of RTOSes. This way the application code can be ported with little or no change to a number of targets and RTOSes because the class library acts as an abstraction layer. I have successfully implemented this class library for Windriver VxWorks, Segger embOS, Keil RTX, and even Linux and Windows for simulation and prototyping.

Some vendors do provide C++ wrappers to their RTOS such as Accelerated Technology’s Neucleus C++ for Neucleus RTOS, but that does not necessarily provide the abstraction you might need to change the RTOS without changing the application code.

One thing to be aware of with C++ development in an RTOS is that most RTOS libraries are initialised in main() while C++ invokes constructors for static global objects before main() is called. It is common for some RTOS calls to be invalid before RTOS initialisation, and this can cause problems – especially as it differs between RTOSes. One solution is to modify your C runtime start-up code so that the RTOS initialisation is invoked before the static constructors, and main(), but after the basic C runtime environment is established. Another solution is simply to avoid RTOS calls in static objects.