Posts Tagged ‘firmware’

Worst-Case Context Switch Times by RTOS

Wednesday, January 6th, 2010 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.

Is Reliable Multithreaded Software Possible?

Wednesday, December 23rd, 2009 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.