Industry Comment
CMSIS 3, and CMSIS RTOS, March 6 2012
A significant development was announced at Embedded World 2012 that directly affects the RTOS industry - the release of CMSIS 3.
CMSIS is an acronym of "Cortex Microcontroller Software Interface Standard". It is a hardware abstraction layer that provides a standard software interface to the Cortex-M core. It is equally applicable to all Cortex-M based microcontrollers, so is microcontroller vendor independent. CMSIS simplifies software re-use and reduces the Cortex-M learning curve by provides 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 is a common operating system interface that has been in place for many years, but is generally not regarded as being an optimal solution for smaller devices, such as Cortex-M3 microcontrollers, so will CMSIS be a better choice?
The cynic might say that ARM have such a strong position in the microcontroller market that, if they put their 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 is necessary to try and view the possible CMSIS RTOS business case from the perspective of each stake holder - starting form the most important stake holder - the end user.
The End User Perspective
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 is therefore not realistic to expect an end user to switch suppliers frequently, unless, of course, they only use open source software.
The Open Source RTOS Vendor Perspective
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 and/or fast. 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 is likely that the abstraction layer will be removed in end products that make it to market anyway.
The Commercial RTOS Vendor Perspective
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 homogenises 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 re-writing parts of the underlying code, which may effect backward compatibility.
Tools and middleware will become the key differentiator, until they, too become commoditised. It is feasible that a successful CMSIS RTOS roll out will go along way to commoditise RTOS tools already. It is 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 uCOS/II could ever become CMSIS RTOS compatible because the CMSIS RTOS specification only permits seven distinct priority levels.
The Non-RTOS Affiliated Middleware Supplier Perspective
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 Perspective
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 Perspective
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.
Conclusion
Disappointingly, it is 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, there are both positive and negative aspects to the CMSIS RTOS API. Market forces will play a role in its success - if commercial vendors invest in CMSIS RTOS support then their competitors will probably have to follow. Ultimately though, it will be end user interest that will be key. No matter which industry you are 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 standardisation 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 optimised native RTOS API by interfacing to the RTOS directly.