Archive for March, 2008

Educating Embedded Engineers

Thursday, March 20th, 2008 Michael Barr

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

Wednesday, March 19th, 2008 Michael Barr

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

Wednesday, March 12th, 2008 Michael Barr

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.

Go back to RTOS Myth #2 or forward to RTOS Myth #4.

RTOS Myth #2: RMA is for Academics

Thursday, March 6th, 2008 Michael Barr

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.

Go back to RTOS Myth #1 or forward to RTOS Myth #3.

VDC Counts 4 Billion Embedded Products Shipped in 2006

Tuesday, March 4th, 2008 Michael Barr

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.