embedded software boot camp

Worst-Case Context Switch Times by RTOS

January 6th, 2010 by Michael Barr

This morning I received an e-mail from an embedded software developer. It read in part:

We are trying to find the best case, average, and worst-case context switch times for the ThreadX and eCOS real-time operating systems. I have searched the Internet extensively. I found one source stating that the ThreadX context switch time can be under 1 microsecond, but it was unclear if that was the best-case, average, or worst-case timing. Can you help us?

As questions like this keep coming, I shall respond via this blog.

None of the timings sought (even the 1 microsecond timing found online) can be calculated without knowledge of the specific processor family, clock speed, and memory architecture. Context switch code is generally written in assembly language and mostly consists of pushing a number of CPU register contents to RAM and popping older data from RAM into registers. The primary factors in context switch timing are the number of opcodes involved, the speed of their execution, and RAM access speeds.

Note though that even for a given hardware platform, I am unaware of any analytical use of any but the worst-case context switch timings for an RTOS. ThreadX purveyor ExpressLogic should, like any RTOS vendor, be willing and able to provide a prospective customer an estimate of the worst-case context switch timing on their planned hardware. But you will want to validate that number on your final hardware before performing Rate Monotonic Analysis (RMA) to prove that all critical deadlines will be met.

Related Article: How to Choose a Real-Time Operating System.

Tags: , , ,
Posted in RTOS Multithreading | 3 Comments »

Is Reliable Multithreaded Software Possible?

December 23rd, 2009 by Michael Barr

Until earlier this month, I’d overlooked a most interesting May 2006 article in Embedded Software Design magazine by Mark Bereit titled “Escape the Software Development Paradigm Trap“. The article opines that the methods we use to design embedded software, particularly multitasked software with interrupt service routines and/or real-time operating systems, are fundamentally incompatible with reliability.

Here’s the critical analogy:

Imagine for a minute that I’ve invented the Universal Bolt. This is a metal object for joining threaded holes that can extend or collapse to fit a variety of lengths. It can expand or contract to fit holes of different diameters. The really cool feature is that I have replaced the bolt’s spiral ridge with a series of extendable probes that can accommodate different thread pitches. You no longer need to stock a variety of bolts of different sizes and lengths and thread spacings because my Universal Bolt can be used in place of any of them.

Because it’s able to change configurations extremely quickly, a single Universal Bolt can take the place of many conventional bolts simultaneously. What we do is rig up a clever and very fast dispatcher device that quickly moves the [Universal Bolt] from hole to hole. If the dispatcher is fast enough, my Universal Bolt can spend a moment in each hole in turn and get the whole way through your [mechanical] product so fast that it returns to each hole before the joint has had a chance to separate.

You’d have to be crazy to fly in an airplane designed this way. “If anything caused the dispatcher to derail, the entire product would collapse in a second.” Yet this analogy describes the design of most products powered by embedded computers.

A fast and complex thread dispatcher keeps moving one simple and stupid integer-computation unit all over a big system tending to tasks [and ISRs] rapidly enough that they all get done. And if that dispatcher ever once leads the CPU into an invalid memory address the whole thing crashes to a halt.

Clearly, we need a new paradigm for reliable embedded software architecture. My thoughts on that are coming to this space in 2010.

Tags: , , , ,
Posted in RTOS Multithreading | 7 Comments »

Embedded Java Lives!

December 16th, 2009 by Michael Barr

Reading the latest embedded software market survey highlights from VDC Research I was surprised to note two data points indicating new upward momentum for Java as an embedded software development language.

First, of those survey respondents using an operating system on their current project 11% indicated that a Java Virtual Machine is required in their product.  Second, Java was selected as the fifth most used language for firmware development at 14% of respondents (behind C, assembly, C++, and Matlab, in that order).

This is an interesting trend.  My regular readers will note that I have written and spoken about Java in embedded systems since 1997 and that I declared Java “dead” in the embedded realm about 18 months ago.

Tags: , , ,
Posted in Uncategorized | No Comments »

Verification vs. Validation

December 15th, 2009 by Michael Barr

The FDA 510(k) guidelines for medical device software leave something to be desired in the poor differentiation of two important and distinct software development practices: verification and validation.  In particular, the FDA often uses the word ‘validation’ to describe both types of activities.  (See, for example, the General Principles of Software Validation; Final Guidance for Industry and FDA Staff.)

Put simply, software validation is a set of activities that together demonstrate that you “made the correct product” (or, as others have put it, “built the right thing”) for the customer’s needs.  Validation tests that the product’s behavior is consistent with the requirements, safe, and efficacious.

By contrast, software verification is a set of activities that together demonstrate that the implementation matches the design.  That is, verification tests that you “made the product correctly” (“built it right”).

In the larger context, verification should come before validation.  It doesn’t make sense to check that the product does what it is supposed to unless you first confirm that it does what you programmed it to.  If it were only the case that the many engineers and organizations that talk about software verification and validation (a.k.a., V&V) could get this simple concept.  It wouldn’t hurt, of course, if the FDA rewrote the above document.

Tags: ,
Posted in Uncategorized | 1 Comment »

Embedded Programmers Worldwide Earn Failing Grades in C and C++

November 24th, 2009 by Michael Barr

In industry surveys, over 80% of embedded software developers report using C or C++ as their primary programming language. Yet as a group, these programmers earned a failing grade on a multiple-choice quiz testing firmware-related C programming skills. A scary result, considering that embedded software inside medical devices, industrial controls, anti-lock brakes, and cockpits place human lives at risk every day.

In a February 2008 blog post, I examined the first few hundred results from the “Embedded C Quiz” on the Netrino website. That analysis compared the performance of programmers in the U.S. and India with the rest of the world (the only three data sets large enough for meaningful analysis). I concluded that the average embedded programmers in the U.S. and India don’t know C very well, but do know it better than programmers in the rest of the world.

Two years now since launching the quiz, we have collected thousands of data points, so it’s time for an update on programmer performance. In total, 3,870 programmers have taken the short 10-question multiple-choice C skills test. A few (a bit less than 3%) didn’t answer all of the questions; the analysis below is based on just the 3,755 completed quizzes. (Note that each website user can only take the quiz once.)

Across all countries, the mean result was 60.8%–a grade of ‘D-‘ at best. That is to say that the average embedded programmer answered just 6 out of 10 multiple-choice questions correctly. A rather scary fact, given that C is the language of choice for most embedded projects and that C++ is even harder to master.

Programmers in the United States scored slightly above average. But they still earned a failing grade of 61.8%. Programmers in India scored slightly below the worldwide average, at 58.9%. Together, programmers from these two large English-speaking countries accounted for the majority of all quiz takers.

The number of completed quizzes, mean scores, and standard deviations for all countries with more than 20 completed quizzes are shown in the table below, sorted by average score. In general, programmers from European countries scored best.

Country Completed Mean Std Dev
Poland 23 68.7 19.2
Sweden 26 67.7 15.8
Australia 45 67.3 22.3
Germany 57 67.2 17.2
France 35 66.9 24.0
United Kingdom 109 66.1 22.8
Spain 24 65.0 18.3
Canada 114 64.5 19.3
China 51 64.1 23.4
Israel 22 62.3 21.7
United States 1346 61.8 20.4
Egypt 28 59.3 22.8
India 1288 58.9 22.4
Romania 45 58.9 23.0
Singapore 24 58.3 20.1
Italy 44 56.4 20.8
Turkey 57 55.6 23.3
Brazil 47 55.1 24.1
Pakistan 25 44.0 21.7

How are your embedded C programming skills? Test them by taking the Embedded C Quiz yourself now at http://www.netrino.com/Embedded-Systems/Embedded-C-Quiz?

P.S.  We recently launched an Embedded C++ Quiz and the results so far look downright abysmal.  I’ll write something about that in a future post.  Do you have a few minutes to take that one too?

Tags: , , , , ,
Posted in Uncategorized | 6 Comments »

« Older Entries
Newer Entries »