5 ms·
… if you’re running a single task at a time. Usually multiple tasks need exclusive access to shared resources. And they might be triggered by external inputs wh
by pgorczak 4y ago
… if you’re running a single task at a time. Usually multiple tasks need exclusive access to shared resources. And they might be triggered by external inputs which are non-deterministic, making the number of possible system states you need to check intractable.
- jacquesm 4y agoYes, hard real time is hard. So don't multi-task, use as simple a scheduler as you can afford and make sure all your time critical paths are limited. I've built quite a few hard real time systems (machine control, mostly) and the penalty for messing that up would be either a toolstrike, loss of a workpiece, loss of a machine or loss of limb or life so I'm aware of the pitfalls and would definitely not want a multi-tasking OS as the core for anything hard real time. For soft real time that works fine, but for hard real time you need absolute control. In an extreme case that can mean a separate CPU running with all interrupts disabled (and NMI tied) so that you will never be surprised. Another CPU can handle concurrent stuff.
- keithnz 4y agoI've also done a bunch of machine control, and I generally really like the multi CPU architecture for real time control, if you are making your own hardware, I don't think it is too extreme. I've also found a lot of the systems end up being a mix of hard/soft realtime, where the bits that directly monitor/control the machine are hard, and then there is soft "decision" type stuff, farming them out to their own CPUs is often much easier to make guarantees of the hard real time bits.