Archive for January, 2008

USB On-The-Go

Thursday, January 31st, 2008 Michael Barr

Last fall, Netrino was asked by a prospective client to assist with the design of a product to be controlled by a smartphone. At first, the requirement was stated as a Bluetooth connection between the smartphone and the product. Later, however, Bluetooth was deemed by the client too complex a connection for their customers to manage. Thus the connection requirement was changed to a USB link via physical cable.

Unfortunately, and quite to our client’s surprise, this was easier stated as a requirement than implemented. USB is not a bi-directional protocol. According to the standard, each USB endpoint is either a “host” or a “device”. A PC running Windows is an obvious USB host. Printers and mice are obvious USB devices. But what about a smartphone, particularly a smartphone running Windows Mobile? Should a smartphone be a USB host or a device? The answer turns out to reveal a design oversight the original USB specification.

For historical reasons, USB was stuck with this host vs. device design issue and smartphones were all treated as USB devices only. (Smartphones make sense as devices when considered in relation to the host PCs they sync with.) So what would happen if you wanted to use a smartphone like our client as a USB host, with a device like a printer attached directly?

As we would learn in our research, this shortcoming of the original USB standard was recognized over a decade ago and a new standard called USB On-The-Go (OTG) was defined to allow products like smartphones to change roles from USB host to USB device on the fly. Unfortunately, this requires dedicated hardware at the USB interface–as well as different cabling.

For one reason or another, USB OTG technology never made its way into smartphones. There is certainly historical evidence of chip supplier attempts to integrate OTG. But perhaps the emergence of Bluetooth as an alternate host or device technology in that product space about the same time led to OTG being excluded from or disabled at the smartphone design level.

Unfortunately, that left our client between a rock and a hard place. Control via USB would be possible only with a USB host implementation in their product and a custom interface between that and the smartphone. The didn’t want to use Bluetooth and couldn’t use USB.

How have you solved this problem?

Twenty Years of Embedded Systems Design

Tuesday, January 29th, 2008 Michael Barr

It’s hard to believe, but industry magazine Embedded Systems Design, which I edited for five years from 1999 to 2004, is this year celebrating its twentieth continuous year in print.

The popular magazine, which was titled Embedded Systems Programming for about the first 16 years, started its run in 1988, at a time when the widespread use of assembly language was challenged by some engineers as inefficent compared with coding in raw hex. There were then dozens of dialects of the C language, which few embedded developers used, but a committee at ANSI was actively working on the standard that would ultimately win.

The passing of this event brings two interesting thoughts to my mind. One about the past, the other about the future.

Looking backward, I wonder just how much the embedded developer community owes to Ted Bahr and Tyler Sperry (the founding publisher and editor-in-chief, respectively) for giving us the name “Embedded Systems”. Although the concept of embedding microcontrollers into products dates back 17 years earlier (to the introduction of the 4004 single-chip micro by Intel in 1971), the name embedded systems was made popular by the success of the magazine and associated Embedded Systems Conference.

Looking forward, though, I wonder just how much longer the print magazine is for the world. Tremendous changes have rocked the universe of print media–even just in the four years since I left the editor-in-chief role at Embedded Systems Programming. Both the number of subscribers and the number of pages in the print magazine peaked during my tenure, at about 70,000 and over 120, respectively. Today, the circulation is down considerably and the typical number of pages is around a third of that peak. Online advertising has changed the game for most technology companies, who no longer find the unmeasurable and expensive investment in print ads their only option.

What do you think?

RTOS Myth #1: Mutexes and Semaphores are Interchangeable

Monday, January 28th, 2008 Michael Barr

The Myth: Mutexes and semaphores are similar–even interchangeable–operating system primitives.

The Truth: Mutexes and semaphores should always be used for distinct purposes, and should thus feature distinct APIs. (My recommendations to RTOS vendors are at the end.)

The cause of the confusion between mutexes and semaphores is historical, dating all the way back to the 1974 invention of the semaphore by Djikstra. Prior to that date, the interrupt-safe task synchronization and signaling mechanisms known to computer scientists were not efficiently scalable for use by more than two tasks. Dijkstra’s scalable semaphore could be used for task synchronization (including mutual exclusion) as well as signaling.

After the introduction of commercial real-time operating systems (beginning with VRTX, ca. 1980) and the publication of a 1990 paper on priority inheritance protocols it became apparent that mutexes needed to be more than just semaphores with a binary value. Because of the possibility of unbounded priority inversion, which would break RMA assumptions, ordinary semaphores cannot be used for mutual exclusion.

Many bad sources of information add to the general confusion by introducing the alternate names binary semaphore for mutex and counting semaphore. The current wikipedia entry for semaphore is a prime example.

The correct and appropriate solution is a distinct set of RTOS primitives: one for semaphores and another for mutexes. Mutexes must prevent unbounded priority inversion. The APIs for semaphores and mutexes should be as distinct as possible, as their use is quite different.

Go on to RTOS Myth #2.

Are all RTOSes the Same?

Wednesday, January 23rd, 2008 Michael Barr

Having just, coincidentally, returned from teaching a two-day hands-on RTOS course in Florida, I was greeted this morning by the following message from an RTOS company president in my inbox:

Recently, I have had a statement by you thrown at me. The statement essentially said that all RTOSes are the same, or something to that effect. Obviously, you and I both know that there are differences, some large and some small. The problem is that people listen to what you say and I think they may have misunderstood you. So what were you trying to say? I’d like to know so I can rebut them with your own words when they quote you.

This reply is probably best handled publicly. Having used several commercially successful RTOSes (including both of the current top two according to Embedded Systems Design); written one of my own (ADEOS) for a book; taught OS theory as adjunct faculty at the University of Maryland; and also written and spoken of non-preemptive RTOS alternatives in several venues, I am quite opinionated on the subject. A few years back I was even interviewed about RTOSes on a PBS television show called American Business Review.

Here are a few of my past RTOS articles, which may provide additional background for this post:

I believe the opening paragraph of that last article concisely sums up an opinion I’ve often expressed–and which may have been the basis of the remark aimed at the RTOS vendor who e-mailed.

Every commercial RTOS employs a priority-based preemptive scheduler. This despite the fact that real-time systems vary in their requirements and real-time scheduling doesn’t have to be so uniform. Multitasking and meeting deadlines is certainly not a one-size-fits-all problem.

But my e-mail correspondent is correct that there are differences large and small. Here are some of the most obvious differences between the various commercial RTOSes:

  1. At the API level, each RTOS is unique. Though every RTOS has functions for creating a new task, acquiring a mutex, and posting to a message queue, the specific function names and parameter lists differ “by brand”. Individual programmers may find one RTOS’ API more comfortable or logical than another.
  2. To support true real-time scheduling via RMA, each RTOS must provide the following:

    1. A guarantee that the highest-priority task ready to use the CPU is the one actually running at all times
    2. A bounded worst-case context switch time
    3. A bounded worst-case interrupt latency
    4. A mechanism to automatically prevent unbounded priority inversion during mutex contention

    An RTOS that doesn’t do one of these things is, obviously, different from the others–but most do. But the specifics may vary. In particular, the precise timing of those worst-case times may differ from one RTOS to the next on one processor to the next. In addition, the details of the chosen priority inversion workaround will make a difference in the RMA calculation mathematics.

  3. Some RTOSes can use the MMU and others can’t

Hopefully, this clarifies both that I think commercial RTOSes are somewhat commodity products and that there are, nonetheless, obvious differences.