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: embedded, firmware, programming, rtos
Contex switch is in most cases not really the most important thing in RTOS design. It is quite probably that before you finish software design (with RTOS) there will be another version of you chip, with 10% faster cpu clock and less power consumption.context switchs are fairly comparable for different RTOS and in more case not really important for design. Let's try calculate time spend on "switching context" and time spending in idle or in doing job.
It's a really good design goal for an RTOS to strive for constant execution time (best-case = worst-case) for context switches. This means that the RMA is not unnecessarily pessimistic.I've previously worked on the SSX5 RTOS (now merged into RTA-OSEK), which did manage to get very close to constant execution time.
Andrew,
While it is likely on many hardware architectures that the context switch will be constant time, or close to it, I disagree that this should be an important design goal for an RTOS developer. First, because RTOS makers don't control the hardware settings on which they are run. Data caching is one simple way in which the prior context might be brought into the registers much faster than worst-case.
Additionally, RMA is necessarily pessimistic. Application developers who care about ensuring all deadlines are met will never stop caring about worst-case times. Still, making parts of the code run slower than needed is never a good idea. Any spare cycles that pessimistic RMA counts as unavailable can still be used in the field–by low priority tasks that don't have any critical deadlines to meet.
If you want completely deterministic application behavior, you'd do well to ditch the RTOS altogether. Low jitter functionality should be placed into hardware directly (e.g., an FPGA), executed in interrupt handlers, or run as part of a "cyclic executive" backgroun loop with deterministic timing. An RTOS can support provability/predictability with respect to deadlines with RMA. But an RTOS will never give you determinism.
Cheers,
Mike