Who wins when Cortex-M adds RTOS?

Richard Barry of FreeRTOS.org examines who the winners and losers will be in ARM's decision to add an RTOS to its Cortex-M hardware abstraction layer, through the release of CMSIS 3 (Cortex Microcontroller Software Interface Standard 3).

A significant development was announced at Embedded World 2012 that directly affects the RTOS industry–the release of CMSIS 3.

The Cortex Microcontroller Software Interface Standard (CMSIS) is a hardware abstraction layer that provides a standard software interface to the Cortex-M core. It's equally applicable to all Cortex-M based microcontrollers, so it's microcontroller-vendor independent. CMSIS simplifies software reuse and reduces a team's learning curve on the Cortex-M by providing a library of Cortex-M core-specific interface functions and definitions. For example, it provides a function that sets the priority of an interrupt, because the interrupt controller (NVIC) is part of the Cortex-M core itself, and not a separate peripheral as it is on ARM7-based microcontollers.

New in CMSIS 3 is CMSIS RTOS. This expands the common interface concept from the hardware interface, to the RTOS interface. But will this work? While the hardware interface to a Cortex-M core is common across all Cortex-M microcontrollers, the software interface to an RTOS is different in every case. POSIX, a common operating system interface in use for many years, is generally not regarded as an optimal solution for smaller devices, such as Cortex-M3 microcontrollers, so will CMSIS be a better choice?

The cynic might say that ARM has such a strong position in the microcontroller market that, if it put its weight behind it, CMSIS RTOS will be successful whether it technically merits the success or not. Ultimately, however, its success (or otherwise) will depend on whether customers want it. For customers to want it, they have to see a benefit. One benefit is already clear–a single API for a set of two or more RTOSes. Is this benefit alone enough to make CMSIS RTOS a success? To answer that question objectively, it's necessary to try to view the possible CMSIS RTOS business case from the perspective of each stake holder–starting from the most important stake holder–the end user.

Perspectives:
The end-user
A common interface to multiple RTOS solutions has an obvious appeal. It will make software more portable and allow the freedom of moving between RTOS suppliers.

As an engineer though, I know that, particularly for high-volume products, the selected microcontroller will be the lowest cost and smallest possible for the task in hand. That means, in the presence of the inevitable resource crunch, the software running on the microcontroller will be trimmed down. If space, time, or responsiveness is at a premium, any software that is not adding value to that application will be ejected. An RTOS abstraction layer will, by its very nature, not add to the RTOS functionality, but will make the code bigger and the execution slower. The RTOS abstraction layer will always be a prime candidate for removal.

Also, a commercial RTOS is a financial investment. It's therefore not realistic to expect an end user to switch suppliers frequently, unless, of course, they only use open-source software.

The vendor of open-source RTOSes
It has just been stated that, because of the financial investment required to select a new commercial RTOS, CMSIS RTOS compliance will provide more mobility to, and between, free open-source RTOS products. This presents a big benefit to open-source suppliers. Another benefit is the potential investment made by commercial silicon, RTOS, and tool vendors in CMSIS-RTOS-compliant infrastructure that will be equally applicable to open-source-compliant products–whether the open-source vendors make an equivalent investment or not.

However, it has also just been stated that, by its very nature, an RTOS abstraction layer will make the RTOS larger and less responsive. This is counter productive as an RTOS should be designed to be small or fast (or both). Using the abstraction layer will not allow the RTOS to be used to its full potential, or provide the maximum potential benefit to the end user. Maybe that is not a problem though, and it's likely that the abstraction layer will be removed in end products that make it to market anyway.

The vendor of commercial RTOSes
The plus points already stated for the open-source RTOS vendor must surely be negative points for the commercial vendors. The negative point stated for the open source RTOS vendor (the fact that the product will be bigger and slower) will probably be exaggerated for the commercial RTOS vendor.

Commercial RTOS vendors invest in their products to differentiate them in a number of different ways. Performance, size, price, support, etc. are all attributes used to position an RTOS. Anything that homogenizes RTOS offerings in the market, and in so doing reduces any differentiation gained by technical and/or marketing investments, makes the RTOS market a tougher market in which to work. It also makes future investment harder to justify. The canny commercial RTOS vendor may be able to turn this to their advantage by providing the most efficient CMSIS RTOS compliant product on the market–but it is difficult to see how that can be achieved without rewriting parts of the underlying code, which may have an effect on backward compatibility.

Tools and middleware will become the key differentiator, until they, too become commoditized. It is feasible that a successful CMSIS RTOS roll out will go along way to commoditise RTOS tools already. It's unlikely however that a commercial RTOS vendor will make their own middleware offerings CMSIS RTOS compatible, unless their business model is to license them to other RTOS vendors.

Different RTOSes have different usage models, and different APIs that are tailored to the product. CMSIS RTOS compliance cannot be practical for all commercial RTOS offerings. For example, one of the most popular existing products is uCOS/II, the scheduler for which does not permit more than one task to use the same priority value. It is difficult to see how µCOS/II could ever become CMSIS RTOS compatible because the CMSIS RTOS specification only permits seven distinct priority levels.

The non-RTOS-affiliated middleware supplier
Non-RTOS affiliated vendors of sophisticated middleware supply software that must work with any RTOS their customers might be using. This places a burden on the middleware supplier to provide their own abstraction layer to, and test with, a number of different RTOS solutions. Replacing these multiple abstraction layers with a single abstraction layer must therefore be seen as a benefit. The benefit will only become a reality however if the end users are actually using CMSIS RTOS in the products they are designing and shipping. If the end users do not use the abstraction layer, then the middleware supplier has the choice of either asking the end user to do the porting themselves (not a good commercial angle), or accepting the CMSIS RTOS specification as just another interface the middleware supplier has to maintain themselves.

The microcontroller vendor
The microcontroller vendor perspective is similar to that of the middleware supplier in that they provide software (predominantly drivers) that must interface with any system their customers are using. Traditionally, silicon vendors supplied drivers that used a simple polling model, but more sophisticated usage models are becoming more common.

The tool vendor

Tool vendors provide products such as execution trace and profiling tools, as well as kernel away debugger plug-ins. Generally these tools do not access the RTOS through the RTOS's API, so will largely be unaffected. Also, these tools are predominantly supplied by the RTOS vendor themselves, who are unlikely to want their tools used with any competitive products.

Who wins?
Disappointingly, it's too early to draw any conclusion yet, although it appears, if my surmising is accurate, that open-source vendors will probably have the most to gain.

Like a lot of things, the CMSIS RTOS API has both positive and negative aspects. Market forces will play a role in its success–if commercial vendors invest in CMSIS RTOS support, their competitors will probably have to follow. Ultimately though, it will be end-user interest that will be key. No matter which industry you're in, you will have a much higher chance of success if you do what your customers want. Likewise, investing in something your customers don't want is always a bad call.

There is potential for a CMSIS RTOS usage scenario that might be a compromise between performance and standardization that is acceptable to all stake holders. In this, middleware and microcontroller driver library suppliers provide their products configured to use the CMSIS RTOS API, but end users (the application writers) get all the benefits of the optimized native RTOS API by interfacing to the RTOS directly.

Richard Barry graduated with 1st Class Honours in Computing for Real Time Systems. He's been directly involved in the start up of several companies, primarily working in the industrial automation and aerospace and simulation markets. Barry is currently a director of Real Time Engineers Ltd., owners and maintainers of the FreeRTOS project (www.FreeRTOS.org ) .

This content is provided courtesy of Embedded.com and Embedded Systems Design magazine.
See more content from Embedded Systems Design and Embedded Systems Programming magazines in the magazine archive.
See more blogs in Embedded.com Industry Comment blog archive.
Sign up for subscriptions and newsletters.
Copyright © 2012
UBM–All rights reserved.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.