A real-time system is not a fast system. It is a system whose worst case is known. The
distinction decides the architecture, the operating system, and often the processor, and it
is the point where most embedded projects first go wrong.
Hard, firm and soft
A hard deadline missed is a failure: the airbag fires late, the servo overshoots, the
sample is lost. A firm deadline missed makes the result useless but harmless. A soft deadline
missed degrades quality. Each class buys a different amount of engineering, and calling a soft
deadline hard is an expensive way to be careful.
Where the time goes
The budget for an interrupt-driven path has four parts: interrupt latency in the silicon,
the time the kernel spends before your handler runs, the handler itself, and any priority
inversion on the way to the task that finishes the work. The first is in the datasheet. The
second is the number that separates an RTOS from a general-purpose kernel. The third you can
measure. The fourth is the one that produces the bug you cannot reproduce.
Measuring rather than assuming
A GPIO pin toggled at the entry and exit of the handler, watched on a scope, answers more
questions in ten minutes than a week of reasoning about the scheduler. Run it with the caches
cold, with the worst-case interrupt load, and at the temperature the enclosure actually
reaches. The interesting number is not the average; it is the widest pulse in an hour.