rt linux is not appropriate for many hard realtime requirements
i have seen some try and fail in an effort to save $perceived_value
i have seen some try and fail in an effort to save $perceived_value
Dedicated Real-Time Cores: Many SoCs include dedicated cores specifically for hard real-time tasks.
Microcontroller Companions: Pairing a microcontroller running a lightweight RTOS with a larger, general-purpose processor as a supervisor (You can use normal Linux).
FPGAs: Custom FPGA implementations can deliver deterministic timing where ultra-low latency or specialized processing is needed.
I'm wondering about things that could cause unexpected delays, like PCIe bus contention / error correction, high interrupt traffic, etc.
(I don't know much about this topic, so apologies if my question is ill-conceived.)
On the other hand, on FPGAs, deterministic timing is so very simple. Your output will not be a single clock cycle late even if something else goes wrong in logic running on the same FPGA (except through a connection that you control).
If you really want to know, OSADL has a QA Farm that monitors worst-case interrupt and scheduling latency for various CPUs and Linux versions.
my experiences then would lead me to recommend it, though.
Forgot to mention: the neat part of RTEMS is it allows one to sort of turn a Unix program into a bare metal program.
It's all very well asserting something but a bit more chat would be nice.
I'm not sure what "turn a Unix program into a bare metal program." means.
It may be easier to write that on a full sized Linux system, but come time to deploy it, all that Linux code that isn't being used is a liability for bugs and unexpected behavior to crop up. One approach is to slim down Linux to avoid that (eg removing systemd, esp for systems that don't have enough ram to run it), but another approach would be to just use something less complicated than Linux. It would suck to get to space only to find that something had messed up permissions on the gpio pins again so your satellite didn't deploy and now you've wasted a launch. If there's no permissions system to mess up, that can't go wrong.
As far as bare metal, I presume it means to port a Unix program which has all sorts of assumptions about running on a Unix operating system, to an OS that's not one, with simplified models for a lot of things, and for the system to reliably run that program on boot and not do anything unecessary. Like run cups.
This is completely impossible with standard Linux. Real-time Linux might offer some guarantees, but I am pretty sure that they are rather soft.
Linux is already too big to be easy to understand and audit in order to be certain that you really know which will be the worst case.
With a simple OS like RTEMS, a competent programmer can become an expert in its internals in a month or so, and then it is easy to understand what exactly will happen in any circumstance.
I have used in the past some commercial real-time operating systems, like pSOS and VxWorks, but the free RTEMS has been much better than those, especially because being open-source it allows a much deeper customization than any proprietary solution.
Empirical testing of “verified” software often found errors, too. High-assurance, security certification used to require formal methods, thorough testing of code, review of anrtifacts, and pen testing by independent team. We should do that today.
In this case, you’d do white box and black box testing of the WCETS of seL4.