Windows Embedded Compact

From a recent entry in VDC's blog:

In an effort to remove any confusion around its embedded offerings, Microsoft has reorganized and rebranded its Windows Embedded product family. Going forward, new editions of Windows XP Embedded will be titled Windows Embedded Standard, Windows Embedded CE will be titled Windows Embedded Compact, and restricted licenses of Windows Vista and Windows XP will be offered through the Windows Embedded Enterprise group. In addition, new products specific to certain device categories, including the next generation of Windows Embedded for Point of Service, will be offered through the Windows Embedded Ready division.

Sure, that's less confusing!

Real-Time Java is Dead

A few months less than ten years ago, I presented a paper at the Embedded Systems Conference (ESC) for the first time. My 1.5 hour course was entitled "Embedded Java" or something similar. This was in Silicon Valley, and the audience was standing room only--despite a rather large room to start with.

I've tracked technical and business developments in the world of embedded and real-time Java for even longer--and written a number of articles on the subject. And so I didn't miss that over the years the audiences for courses on either variant of Java dwindled. After a hopeful year or two too long, I gave up on Java in our space and stopped proposing the topic at ESC.

Then, last Spring, I had the refreshing experience of teaching a two-day hands-on real-time Java programming class in the Netherlands. The room was packed. There was enthusiasm. And these guys were really using Java to develop software (though it wasn't truly embedded code). So I thought I'd try again at ESC and reproposed the topic.

Last week I taught a course called "Real-Time Java Programming" at the ESC Silicon Valley venue. A lot had changed about the audience size. This time, in a room of a similar size, there were many empty chairs and tables. I think there were perhaps 15 people attending this time.

By my reckoning, Java is officially dead in the embedded systems community--especially in the U.S.

Embedded History Month

This seems to be the month for celebrating the history of embedded systems.

Twenty-five year old compiler vendor IAR, which just launched a nicely redesigned website, has published an interesting history of the company and its founder, Anders Rundgren.

And next week I'll be out at the Embedded Systems Conference, which is celebrating twenty consecutive years of bringing the community together with a backward-facing keynote led by Jack Ganssle.

Educating Embedded Engineers

One of the biggest problems affecting the embedded systems industry is a shortage of properly skilled firmware developers. I spoke of this in a recent video interview.

Embedded software developers need some skills taught to Electrical Engineers and others taught to Computer Scientists. They also need practical hands-on experience. Unfortunately, even the best of the Computer Engineering programs at Universities fail to deliver the right mix for embedded work.

The demand for such skilled help is growing rapidly--with the latest estimates put at over 4 billion embedded products manufactured per year.

Fellow Embedded Guru Mike Anderson wrote a nice piece about all this for an IEEE-USA publication called "Today's Engineer." I happened across Mike's article in print, but you can find it online by the title "Help Wanted: Embedded Engineers."

Toward a Better Mutex API

A few months ago I blogged that mutexes and semaphores are distinct RTOS primitives. Unfortunately, the APIs of today's most popular commercial RTOSes only add to the confusion for application programmers.

For example, consider the VxWorks API, which not only forces mutexes and semaphores into an inappropriately common-looking API (semMXxx vs. semCXxx) but also adds a third "binary semaphore" type (semBxxx). Micrium's popular uC/OS-II API is preferable to this in that it at least has just two primitive types (OSMutexXxx and OSSemXxx). But the uC/OS-II API also forces programmers to use similar function name suffices--Post() and Pend()--with each.

I propose a new and clearer API such as the following, which is based loosely on uC/OS-II's current API:

int OSSemCreate(SEM * phSem, int cnt)
int OSSemPost(SEM hSem)
int OSSemPend(SEM hSem, int timeout)

int OSMutexCreate(MUTEX * phMutex)
int OSMutexGet(MUTEX hMutex)
int OSMutexPut(MUTEX hMutex)

Wind River would do well to eliminate semBxxx functions and rename the semCXxx functions as semXxx. In addition, the VxWorks API for mutexes should be changed to something like mutexXxx.

Note, too, that this new API is intended to force each mutex object to be created in the 'available' state (i.e., value = 1), as it already is in uC/OS-II. An additional feature of the mutex API should be that any OSMutexPut() call by a task that does not currently own that mutex should fail with an appropriate error code. Together these easily used mutex functions ensure correct usage of mutexes by application developers.

RTOS Myth #3: Mutexes are Needed at the Task Level

The Myth: Mutexes are a useful intertask synchronization primitive, which you should expect to use frequently.

The Truth: Mutexes are a necessary feature of all real-time operating systems. However, best practice is to use them only inside functions that must be reentrant. That is, you should use mutexes only inside functions that are or could be called by two or more tasks.

Mutexes, as their name suggests, enforce mutual exclusion and thus eliminate race conditions between tasks. A mutex can be used to protect a global data structure accessed by two or more tasks. However, doing this properly requires that each user task have the actual address of the global data and allows for bugs in the failure of one task to acquire and release the associated mutex properly.

It is preferable always to abstract or encapsulate said global data structure as an object, which can only be read or written through a set of reentrant function calls. That way, both the address (and possibly internal format) of the data structure can be hidden and the mutex calls can be ensured to be coded correctly.

Note that mutexes are also necessary inside functions that control hardware through I/O registers, which are effectively global data structures.

Of course, a priority inheritance capability should be present within the mutex API (put there by the RTOS vendor) to ensure that priority inversions cannot occur.

RTOS Myth #2: RMA is for Academics

The Myth: The Rate Monotonic Algorithm (RMA) is an interesting theory but it has no practical meaning for users of real-time operating systems.

The Truth: For starters,

• All of the popular real-time operating systems (e.g., VxWorks, ThreadX, and uC/OS-II) feature fixed-priority preemptive schedulers
  
• RMA is the optimal fixed-priority scheduling algorithm (and note that dynamic-priority algorithms do not degrade gracefully)
  
• Unless you use RMA to assign priorities to RTOS tasks, there are no task-specific performance guarantees; if the processor becomes overly busy in a brief period of time, a critical task may miss its deadline
  

In a nutshell, RMA is the one and only proper way to assign relative priorities to RTOS tasks with deadlines. (Shock of shocks: Deferring to your boisterous colleague Bill's insistence that his task is the most important isn't guaranteed to work!) There's a nice introduction to the RMA technique at http://www.netrino.com/Embedded-Systems/How-To/RMA-Rate-Monotonic-Algorithm/.

The principal benefit of RMA is that the performance of a set of tasks thus prioritized degrades gracefully. Your key "critical set" of tasks can be guaranteed (even proven a priori) to always meet its deadlines--even during periods of transient overload. Dynamic-priority operating systems cannot make this guarantee. Nor can static-priority RTOSes running tasks prioritized in other ways.

Too many of today's real-time systems built with an RTOS are working by accident. Excess processing power can mask a lot of design sins. But if you haven't used RMA to assign priorities, it could just be a matter of time before you get burned.

VDC Counts 4 Billion Embedded Products Shipped in 2006

Read Venture Development Corporations OnTarget Blog for more details. But in a nutshell, in the last year for which data are available, VDC estimates 4 billion total units of embedded products, most without a commercial operating system inside. By other estimates, total CPU shipments in 2006 were around 9 billion, but some of those are PCs/Macs and there are also numerous systems containing two or more CPUs.

More Bad RTOS Information

The Internet (and magazines and conferences) are filled with bad information about when to choose an RTOS. In short, the world wants to sell you an RTOS, even when you don't need one or the use of one would overly complicate your software design.

Here are two generalizations from a recent whitepaper:

Operating systems make programming more efficient and better structured, and their use is now frequently justified even in embedded solutions that are relatively small.

and

A clear benefit of using an RTOS is that it reduces time to market, because it simplifies development.

At best, this is misguided advice.

Here's the straight scoop. An RTOS may either "make programming more efficient and better structured" or less efficient and poorly structured; it depends on the nature of the requirements. In many cases, a design composed entirely of state machines is easier to code and works more reliably than one using an RTOS. In other cases, particularly closed-loop control systems, a simple main+ISR approach will work even better.

Embedded Systems History

The editors of Embedded Systems Design recently put together an interesting historical timeline of the embedded systems industry. To learn some history, take a stroll over to http://www.embedded.com/timeline/.