It really depends on what you're doing, but there are certainly versions of Linux that are capable of hard real-time performance. But it shouldn't be too surprising that the goals of an operating system designed for multiuser, multiprocess context is not well aligned with the needs of real-time machine control applications. The trainer is correct, often times it really is appropriate to just delegate those requirements to a dedicated controller whose job is to do nothing else than keep performing the same DSP loop over and over in a well-timed manner. However, there are certainly cases where you might want to interact smoothly between real-time and non-real-time components of a system and use things like shared memory, and in those cases, there definitely are Linux-based solutions available. Like most things in engineering, there are trade-offs along this continuum, so knowing the options and the pros and cons so that you can make a good design decision is just part of the job.

The only version of linux I know of that's capable of hard real time performance isn't really linux anymore but instead just runs an rtos microkernel underneath linux to make real time guarantess and simply runs linux as the lowest priority task on that kernel.

https://en.wikipedia.org/wiki/RTLinux

RTLinux is quite old. There's an official patchset for real-time preemption in Linux that's making its way to the mainline kernel.

If you're talking about the preempt-rt patches being merged, those are very soft real time.

Hard real time, yes. But with very high tolerances compared to what a MHz processor can accomplish just running the application.

Each job requires a tool that does it best, within some limits.

To set a bit in GPIO:

- on AVR, one assembly instruction, 2 bytes machine code, 1 CPU cycle (unless interrupts are enabled);

- on microcontroller-style ARM (Pi-pico), 2-4 assembly instructions, 8-20 bytes machine code (depending on compiler options), 4-12 CPU cycles. All numbers deterministic within the same build (unless code cache is cold, then 50+ cycles, and don't forget interrupts);

- on ARM+linux, hardcore mode: same as above + small, deterministic number of extra cycles since GPIO runs at slower clock than CPU. That assumes you go out of your way to reserve CPU core, set rt_prio for your task, etc...;

- on linux, via sysfs: who knows. 1000 CPU cycles is probably the lower bound, but each run is going to take different amount of time. On a busy system, some - as long as a few seconds.

The pi-pico does have that cute PIO state machine though to baby sit GPIO and get single cycle granularity out of it.

Yep, I suspect that will be the path forward. Same high level strategy, but integrated into a single package. It will be interesting to see if the babysitters remain state machines or if they grow into tiny little microcontrollers.

Or tiny little FPGAs connected to the GPIO lines would be neat too.

Many automotive MCUs have complexe timer coprocessors integrated for hard real time I/O purpose. Examples are GTM, eTPU and N2HET that I know about. Does the PIO work in the same way?

Perhaps counter-intuitively, big complex CPUs are incredibly bad at real time control. Instruction latency and jitter can be huge when dealing with complex caching systems, deep instruction pipelines, etc.

If you have serious hard real time requirements, you will be using a very simple 8bit mcu.

If you are hard real time, then the ability to country hose many cycles each assember instruction will take makes it easy to prove your code is correct. Run on a much faster modern 64 bit CPU with branch prediction, caches, and other tricks and there is no way to know how long any instruction will take. Getting non-real time things done is faster on the 64bit CPU, but the 8 bit is going to get the things it does done one time every time.

This is exactly the division of labor my current project has. The UI and data storage run on a Linux System On Module and the real time control is on an STM32 processor running an RTOS. Pretty standard these days.

I've been on projects where the Linux part would have been offloaded to a tablet or an Android SBC running an app and communicating to the real time processor via BLE.

Both processor hardware and the Linux operating system are powerful in large part because they're opportunistic. But that's the opposite of predictable, which is what defines hard real-time.

When I worked at Qualcomm this is exactly what we used to do, if I rememeber correctly even parts of the USB driver used to run on one.

Can I ask, which training was that?

A week long course with a Linux greybeard in my country. It focused on how to make our own Linux distribution (using yocto) for our future embedded platform.