I'm currently evaluating what to use for the next project, any insight would be good.
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.
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.
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.
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.
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.
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...
The Amazon FreeRTOS operating system and software libraries are released under the MIT open source license, a permissive license with limited restrictions on reuse.
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.
TI is weird, they have their own C compiler.
Surprised to see that they killed the project.
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.