Re:List of Open Source Real-Time Operating Systems
by tyingq on Saturday February 09, 2019 @09:23AM
(#19122394)
For some use cases, a Beaglebone black can allow for "real" real time while running Linux. It has two microcontrollers (PRU) that share memory with the main ARM cores. So if the real time part can be satisfied by the PRU, it's a neat solution.
Re:List of Open Source Real-Time Operating Systems
by snvzz on Saturday February 09, 2019 @09:32AM
(#19122432)
Same idea as linux-rt "hard realtime": Reserve a processor (doesn't matter if it's the same chip or architecture or not).
The issue with this is precisely the shared memory. If Linux can interfere with the PRU, then there's no assurance. This breaks hard realtime: No assurance that the system will react timely in a certain way to a certain event.
Re:List of Open Source Real-Time Operating Systems
by tyingq on Saturday February 09, 2019 @09:41AM
(#19122484)
It does work well enough to, for example, drive large LED display boards, emulate old video cards, processing audio, etc. Things that don't work well with traditional soft rt-linux. I'm sure, as you say, that it isn't good for all use cases.
Re:List of Open Source Real-Time Operating Systems
by snvzz on Saturday February 09, 2019 @09:57AM
(#19122571)
Yes, it has its uses but ultimately it is not hard realtime.
Hard realtime is all about guaranteeing deadlines. If Linux (which is not and will never be high assurance due to its TCB size) can interfere with guaranteeing deadlines, then it's only soft realtime.
The long answer is that there's patchsets like linux-rt which give it better "soft realtime" behaviour, but no hard realtime (deadline guarantees), thus not actual realtime.
Linux-rt allows "coexistence" with "hard realtime", but it's basically a cop-out: Just reserve a processor to run something else than Linux for hard realtime tasks.
In reality, while linux-rt patchset (not mainline) suffices for most pro audio work, Linux has over a million LoC of trusted code base running in supervisor mode; It should not go anywhere near where anything requiring any kind of assurance is running. This happens to be the case with tasks requiring hard (i.e. actual) realtime, as hard realtime is all about guarantees.
My advice for hard realtime would be to look at seL4 and eChronos, both open source as per OSI definition, and pick the one best suited to your design.