Speaker
Description
Any builder and developer who enjoys going down the rabbit hole at the intersection of software and hardware in embedded systems, will eventually find themselves judging if their current task/project should be implemented using an RTOS or a custom linux kernel with the PREEMPT_RT patch set. The decision they make almost always is not guided by the nature of the project/ problem they are currently solving, but on what they find to be the easy path. If they have previously built a custom kernel with the PREEMPT_RT patch set for their hardware and have no RTOS experience, they will do the same. The opposite is also true. The exception comes if they have done both, and from personal experience, their decision will be guided by the merits each approach brings to the table with regards to the particular problem they are solving.
Two-three years ago I was building a custom drone firmware, but from a model predictive control point of view instead of the classic PID tuning approach. I came at the problem from an RTOS point of view, and needless to say, while a microcontroller works perfectly with an RTOS, it is at the end of the day an extremely resource constrained device. As a result, I put the project on a brief hiatus. Last year, after discovering that I could compile a custom kernel for the Raspberry Pi with the PREEMPT_RT patch set, I realized that I now had the right primitives to revisit the problem, however, I ran into an immediate problem. A real-time linux kernel is very powerful, but the challenge of managing kernel configuration, maintaining compatibility across hardware types and revisions quickly shift the focus away from building my project and towards maintaining infrastructure.
But what if real-time performance didn’t require turning Linux itself into an RTOS? This talk proposes an alternative architectural pattern: distribute time-critical responsibilities to dedicated microcontroller-based nodes, and leave Linux to do the high-level orchestration, networking, UI, and asynchronous processing. Building on this kernel of the idea, this project and talk are inspired by the klipper firmware that runs on most 3d printers, where real-time workloads (those that have hard timing guarantees) run on microcontrollers like the Raspberry Pi Pico or ESP32, each running a lightweight RTOS, while a Linux SBC coordinates the system, aggregates data, handles networking, and runs all high level logic without requiring PREEMPT_RT. This way, you can have real-time guarantees and still keep/eat your cake
Justification
This talk will be valuable to attendees for two main reasons. First, it challenges the orthodoxy that if one needs real-time, they must patch the kernel. This talk provides the compelling argument that distributed determinism can still be achieved in a maintainable way without turning a general-purpose kernel into something it was never originally designed to be. Secondly, it balances performance with pragmatism because it aligns with real-world constraints like limited engineering resources, long maintenance cycles, and hardware diversity.
| Where are you based? | Nairobi, Kenya |
|---|---|
| Technical level | intermediate |
| Submission type | Talk |