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.