Posts Tagged ‘embedded’

RTOS Myth #5: You Need One

Monday, February 23rd, 2009 Michael Barr

The Myth: You need a real-time operating system (RTOS) to make your embedded software easy to implement and maintain.

The Truth: Three positive implications of the use of a preemptive priority-based RTOS must be weighed against ten negative implications. An RTOS works well in some scenarios, but overly complicates the design of many other systems.

Annual surveys of the readers of EETimes and Embedded Systems Design generally find that about half (50%) of embedded software developers work on projects that utilize a commercial RTOS, such as VxWorks or uC/OS-II. Due to a sampling bias stemming from the correlation between big teams and RTOS use, the number of new products containing an RTOS is likely much lower than 50%.

Contrary to popular belief, a real-time operating system (RTOS) is not the answer to all of your design problems. When chosen for the wrong reasons, the presence an RTOS can make the firmware design more complicated rather than less. In addition, preemption increases the opportunity for race condition and non-reentrancy bugs. Finally, the inclusion of an RTOS has other costs, such as additional RAM and ROM/Flash.

By my calculations, preemption has three principal positive implications and ten negative implications. For example, one positive is that an RTOS can help separate the timing (i.e., which code is running on the CPU when?) from the application-level algorithmics. The problem is decomposed into a less “fragile”/more maintainable firmware design.

However, the use of separately-coded parallel tasks also complicates the software. Without the RTOS, the only possible race conditions occur between communicating interrupt service routines and the background loop in main(). Additional tasks increase the need for communication and synchronization factorially.

Perhaps the most interesting tradeoff concerns responsiveness to interrupts. Although what an RTOS does is to divide up the spare CPU time not used by any interrupt service routine (ISR) between pseudo-parallel running tasks (i.e., a set of C functions that don’t return), one negative side effect is slower CPU response to interrupts. The interrupt latency is higher with an RTOS than without.

Don’t get me wrong, sometimes an RTOS is a valuable tool. But don’t go using one simply to put its name on your resume. You may instead find yourself languishing in an overly-complicated and buggy embedded software design at your present job.

The “RTOS Alternatives” course by Netrino Institute includes full coverage of these tradeoffs, including details of each of preemptions three positives and all ten of the negative implications of a commercial RTOS.

Go back to RTOS Myth #4.

Embedded Systems Conference 25% Discount Code CTDSS15

Monday, February 23rd, 2009 Michael Barr

As a speaker and track chair for the “Designing Safer Systems” track at the Embedded Systems Conference Silicon Valley, I am able to offer conference attendees a 25% registration discount. To receive the discount you must register with the promotional code CTDSS15.

The complete conference program can be found at http://esc-sv09.techinsightsevents.com/conference.

Requirements vs. Design

Wednesday, February 4th, 2009 Michael Barr

Over the years, I have found that many engineers (as well as their managers) struggle to separate the various elements or layers of firmware engineering. For example, we are barraged with requests for “design reviews” that turn out to be “code reviews” because the customer is confused about the meaning of “design”.

In the hopes of clearing this up, I propose a concise set of definitions and an architectural analogy.

Requirements
The requirements are the WHAT of the system. A set of requirements is a list of statements each of which begins “The system shall…” Each such statement must be objective and testable. The requirements should not unnecessarily restrict the HOW of the architecture, design, or implementation.

Architecture
The architecture of a system is the outermost layer of HOW. The architecture is a block diagram. The architecture of a system describes dataflow and workflow partitioning at the hardware vs. software level. The architecture of firmware features subsystem-level blocks such as device drivers, middleware, RTOS, etc. The architecture does not include function or variable names. It should be extensible in the direction of anticipated future changes.

Analogy: An architect describes a new building very broadly. A scale model and drawings show the outer dimensions, foundation, and number of floors. The number of rooms and their specific uses are not included at this level.

Design
The design of a system is the middle layer of HOW. A firmware design document identifies finer structural details, such as the names and responsibilities of tasks within the specific subsystems or device drivers, the brand of RTOS (if one is used), and the various interfaces between subsystems. The design does include class, task, function, and variable names that must be agreed upon by all implementers.

Analogy: A designer describes the interior and exterior of the new building in finer detail than the architect. He locates and names the rooms and gives them purposes. The location of pipes and vents and outlets are not included at this level.

Implementation
An implementation is the lowest layer of HOW. There is no document, other than the source code or schematics, to describe the implementation details. If the interfaces are defined sufficiently at the design level above, individual engineers are able to begin implementation in parallel.

Analogy: The carpenter, plumber, and electrician work in parallel and apply their own judgement about the finer details of component placement.

Constructive feedback is welcome via the blog comments or e-mail.

Multi-Core in Embedded Systems

Thursday, January 29th, 2009 Michael Barr

Hey Michael,

We met about a year ago at a class that you presented.

I was wondering if you have noticed any movement in the embedded software community to consider multi-core chips and, if so, what OS?

I ask because I noticed ARM has a multi-core chip, Cortex A9, which is rumored to be in the next edition of the iPhone.

Do you see multi-core being valuable, or too expensive for most embedded products? Do you see any problems with going with a multi-core system?

Thanks,
Greg

Dear Greg,

The technology trend that’s driving all the talk about multi-core is that two or more slow processors on one die is becoming more cost effective to produce than a single “faster” processor.

Multi-core processors are thus of most interest toward the end of embedded systems with severe computational demands. Multi-core hardware brings challenges, especially for the software architectures and compilers and operating systems we mostly use. Thus it is unlikely that multi-core will be widely used in the near term by the majority of embedded developers.

Hope this helps!

Cheers,
Mike

The End of a (Print) Era

Thursday, January 22nd, 2009 Michael Barr

With Dr. Dobb’s Journal going printless, the writing is on the (paperless) wall for other trade journals. This prompts me to reflect on the state of technical magazines and their web-based counterparts.

The thickest-ever print edition of Embedded Systems Design magazine (then Embedded Systems Programming) was published in September 2000. That issue had about 120 pages. I was the editor-in-chief at the time, and I distinctly remember the struggle to find enough high quality content for that issue and the impact that doing so had on my backlog of good articles.

In 2000, a full page ad in the magazine sold for about $10,000. And the formula for free-for-registered-subscribers trade journals was simple: publish one page of editorial content for each page of advertising sold. Some quick math shows that the 120 page issue probably generated about $600,000 of revenue. Of course it costs more to print and mail each additional page, but above a certain fixed break-even page count (say, 50 page issues), each additional ad dollar flowed mostly to the bottom line. I think it’s fair to say that the current 40 page print issues of Embedded Systems Design, with ads sold at much lower per page rates, is below that break-even.

By and large, we paid generously for the technical articles and columns we published in that more prosperous era. That incentive to authors plus the editorial funneling process meant that Embedded Systems Programming published lots of high quality articles over the years. Maintaining a reputation for quality content contributed to the publisher’s ability to add qualified subscribers and charge a premium for the ads.

But the online model is different. Because the per-eyeball ad revenue is far lower online, the editorial game has shifted from high quality content to a large quantity content. Even a poorly written technical article with bad advice can earn the publisher some money–if it the editor applies the right keywords.

As Jack Ganssle put it in the above article:

the publication will have more content than ever, no longer restricted by the physical constraints of printing

(To be clear: Embedded Systems Design and its sister website Embedded.com maintain a high standard for content to this day. The preceding comments concern the risks of a move from print to online publishing on any website.)

The move to online publishing is unstoppable, for obvious economic reasons. There are simply more cost effective ways for vendors to reach a large audience and engineers to search for information than the printing and mailing of periodicals.

It is unfortunate that a move toward a higher quantity of lower quality material is becoming the norm within the online editions.