Hi All,
It seems like the future support for real-time Linux is trending towards PREEMPT_RT (I'm only a casual observer). It seems like there have also been some problems with porting Xenomai onto the BBAI platform. If Bela was written again today, I wonder if PREEMPT_RT would be able to work as well as Xenomai and give better compatibility with new hardware?

12 days later

I am not knee-deep in to the topic and I am not aware of any modern comparison between the interrupt latencies of the two, so the most recent one I am aware of is the classic "How fast is fast enough? Choosing between Xenomai and Linux for real-time applications", JH Brown, B Martin - Proc. of the 12th Real-Time Linux Workshop (RTLWS 2010)": https://picture.iczhiku.com/resource/paper/WyIEpzspsLtjRXnc.pdf .

I am sure things have improved on the PREEMPT_RT side since, but I don't think they have become as good as on the Xenomai side yet. On the other hand, the Xenomai project has improved enormously (also thanks to having support and staff time provided by Siemens) and its latest 3.2 version (and upcoming 4.0) are easier to apply on newer Linux releases than the older ones. Over the years we relied on the great work by Robert C Nelson at BeagleBoard who does a great job at providing readily-buildable kernels for the BeagleBoard family which include TI-specific patches of three main kernel flavours: vanilla, preempt-rt and Xenomai. I think Xenomai is the one that gets the least attention from Robert, as preempt-rt is the one that is used at BeagleBoard. The upside of this is that we have to deal with minimal issues on the Xenomai side (I think I submitted a couple of patches total over the years), but on the other hand we didn't spend enough time struggling with it to be able to readily investigate and fix the issue that is currently plaguing the BBAI. I will try to build a newer kernel in the near future and I always have a BBAI in my bag, but as it happens we've always had more urgent things to do so far.

As to what would happen today if we started over ... perhaps we'd naively go with PREEMPT_RT, just because that's what everyone does (there was not much of "what everyone does" when we started this work in 2014). However, that would take way some key features (I doubt we'd be able to run at 2, 4 or 8 samples per block reliably) and we'd be missing out on some Xenomai-specific features such as real-time-friendly pipes to communicate between a RT and non-RT thread, or across RT-threads. These are heavily used by our Scope and Gui libraries and allow to minimise overhead without introducing extra latency. Sure, they could be re-implemented under PREEMPT_RT but some sacrifices would have to be made. So overall I am happy we are on Xenomai and we will keep using it for the foreseeable future, hoping to expand our direct low-level knowledge of it to be able to be more independent from BeagleBoard in releasing updates.