For novel ideas about building embedded systems (both hardware and firmware), join the 35,000 engineers who subscribe to The Embedded Muse, a free biweekly newsletter. The Muse has no hype and no vendor PR. Click here to subscribe.
By Jack Ganssle
An RTOS From TI
Published on embedded.com December, 2012.
TI has announced an addition to their Code Composer line of products - their own RTOS. It has all of the usual features including a filesystem and all sorts of communications stacks. And it's free and is supplied with the source code.
Do we really need another RTOS? The market is already saturated.
This could be an excellent marketing ploy: get developers to design TI-RTOS into a system, and they are forever stuck using processors that OS supports. But a wise developer will be wary of any sort of vendor lock-in. As the agile community says, everything changes all of the time, so it's dangerous to pick tool chains that limit your options.
No doubt the product is highly reliable and all of that. But we don't really know. It seems to me that an RTOS is the very foundation of any product, and must be as close to perfection as software gets. There are a lot of commercial and even open-source operating systems that have been proven to be correct: either they have been used in zillions of products, or have been used in devices certified to the highest standards of reliability (think DO-178B/C and 61502). Buy into one of those (some are free) and your risks are low; use an unknown and probably everything will be OK. Hopefully.
Sometimes we forget that there's only one reason the company writes that paycheck every week: to help the company create profits. That means our decisions must always reflect business realities. Risk management is one of those issues; add risk only when it makes business sense.
The datasheet says "TI-RTOS provides a consistent embedded software platform across TI's microcontroller devices, making it easy to port legacy applications to the latest devices." But it doesn't. At the least, their entire line of MSP430 parts is unsupported.
I looked at some of the code and was unimpressed. Formatting is inconsistent. Some of the developers were meticulous with their commenting and formatting; others were not. Some added Doxygen tags hither and yon; other modules have none.
Laudably, base types are avoided. But strangely the derived types are inconsistent. UINT8, UINT16, etc are defined and used, but so is UINT. What the heck is that?
Many functions are declared Void. That's right - with a capital "V". That seemed odd, so I tracked it down to a header file which includes this gem:
#define xdc_Void void
... hundreds of lines of code
#define Void xdc_Void
Function headers are important, and a pet peeve are those that neither describe what a function does nor what its parameters are. That seems to be de rigor in TI-RTOS.
One would think offering a free RTOS would be an excellent way to tick off the company's partners. Perhaps the most important lesson from Windows and the iPhone is that products succeed when they have a large ecosystem of third-party support.
I think TI is an incredible company with some amazing products. But proprietary RTOSes like this (and Freescale's MQX) strike me as poor business.