Love this page. After wanting to try something other than FreeRTOS, and having been frustrated with very public projects RIOT and Zephyr, I found TNEO from this page and have used it successfully in multiple gadgets. Still very happy with it.
Comparing Zephyr and TNEO is like comparing apples and oranges. Zephyr is full fledged operating system with networking etc while TNEO is more like basic building blocks of os for those who want to implement everything themselves.
I can warmly recommend Zephyr for BLE usage. It is up to date with recent bt specs and implementation is really solid.
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.
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.
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.
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.
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.
There are patchsets out there that add realtime capabilities to the kernel. But as far as I know none of them is in the mainline. I am also not confident that the kernel can be made truly hard realtime capable without major rewrites. The best bet is probably RTLinux which runs the entire Linux kernel as one of the processes managed by a hard realtime kernel.
Linux isolated through virtualization under a microkernel is the way to go if running Linux in the same hardware is actually needed at all. The realtime tasks would simply run outside of Linux, shielded from Linux.
Genode's virtualization (particularly when paired with the excellent seL4 microkernel) is a good way to achieve that.
If Linux can interfere with the "hard realtime" task, then there can be no assurance (of meeting hard deadlines) and it's thus not a solution providing hard realtime.
Without any changes, you have SCHED_FIFO and SCHED_RR [1] schedulers, but despite the name, they are not really suitable for proper real-time tasks. Closest to real time on vanilla Linux is SCHED_FIFO task - as long as there is no other task with same or greater priority, your task don't yield, call syscalls or cause page fault, it won't be preempted. When it does yield (one way or the other), there are no guarantees when it's going to be rescheduled, which is severely limiting for considering it as RT.
One of the reasons why Linux is not suitable for real-time use is virtual memory. It's not even about swapping. The Translation Lookaside Buffer introduces too much variance into timing. Same thing with instruction and data caches and even instruction pipelining. It's not just Linux, but most general-purpose CPUs that are not suited for real-time control applications.
There is a patchset that enables deterministic behaviour on Linux (https://www.linux.com/news/event/elce/2017/2/inside-real-tim... has a few pointers). Much of it has been mainlined, and it does have trustworthy enough commercial backing that it's worth considering at least.
That being said, the more typical approach for this, as employed by e.g. RTLinux ( http://www.rtlinux.org/ -- I'm not endorsing it, it's just the one I'm more familiar with), is to run a hard RTOS along with Linux, running real-time tasks on the RTOS and everything else on Linux. It's a more complex solution, and it's a little unsettling that we've even had to come up with it, but it works surprisingly well.
Writing fancy UIs and multimedia applications on top of things like QNX is difficult (not necessarily in terms of learning/development effort, but also in terms of licensing, cost, hardware support etc.), while writing real-time control applications on a patched Linux kernel requires some trips down the kernel rabbit holes, and is hard to get through some certification processes. Companies optimize for whatever they need :).
This is the wiki for the PREEMPT_RT patchset. Parts of this have been moving into mainline for years, bringing the regular kernel closer and closer to real-time. However, there are some real-time features that will never be appropriate for mainline, so you can get them through this patchset. Some of the "famous" kernel devs are also very active in PREEMPT-RT; it's as official as you can get short of being in the mainline kernel.
For lots of uses, the regular kernel is already realtime enough.
AIUI the plan is to merge the patchset itself into mainline to ease the maintenance burden, but to keep the changes that don't actually make sense for mainstream server use under a special config/#define flag, PREEMPT_RT_FULL or similar. It will then be up to users/distributors whether to enable it. I've only tried the current patchset casually, but IME, the throughput penalty is there but is barely perceptible for casual use, and the improved responsiveness due to kernel thread preemption and the priority inversion fix do make the system a lot more usable especially under load.
It's currently not possible to compile Linux to something that works with 64k RAM and similar amounts of flash like what you usually would find on a MCU.
The first entry FreeRTOS shows MIT as license, but says it's distributed as GPL in the description. I don't know where they got the GPL part from: it's not mentioned anywhere at https://www.freertos.org/a00114.html
FreeRTOS used to be dual-licensed GPL (with an LGPL-esque linking exception) and commercial. Amazon acquired the copyright in 2017 and relicensed FreeRTOS under the MIT license.
The Amazon FreeRTOS operating system and software libraries are released under the MIT open source license, a permissive license with limited restrictions on reuse.
So many of the best are missing. Eg from the L4 family with widest adoption and best HW support only the smallest SeL4 is present, but not OKL4, L4Re, Fiasco, L4Ka::Pistachio, L4/MIPS, WrmOS, Genode.
It's too bad you're being downvoted. It's a legitimate question.
Looking at the source, a case could be made either way IMO. On one hand the scheduler doesn't have priorities, but on the other, you have to explicitly pin tasks to cores so you could actually guarantee real time behavior pretty easily on a fixed platform...
Yeah. I used TI-RTOS a couple of years ago for some work and the whole experience was very different. The most unique part was that the RTOS came bundled with a development GUI integrated into the IDE where you could create threads, mailboxes and other such RTOS primitives. I don't think I liked using it very much though.
It does compile with gcc, but I don't trust it with gcc. At least with TIVA TM4C processors, it would not boot. I suspect they don't test with gcc as well as with their own compiler.
One way to deal with the many available operating systems is to use OSAL. It's an abstraction layer for embedded OS (and POSIX). Admittedly I have mixed feelings about it since it creates work when debugging in a new OS: you need to trace which OS call OSAL is using.
But the RTOS is already an abstraction layer around the hardware, how would adding another abstraction possibly help?
It's not like you often find yourself in the situation where you want to run the same application on multiple RTOSes, it's usually way too specific to the device.
> It's not like you often find yourself in the situation where you want to run the same application on multiple RTOSes, it's usually way too specific to the device
Perhaps that's the point: make your program more portable across different hardware that may only support specific OSes.
I'd be curious how many of these actually provide real time guarantees the way QNX or VxWorks does. I think quite a few of them may simply be "embedded OS" rather than RTOS.
https://en.wikipedia.org/wiki/Real-time_operating_system