From Bare-Metal to Embedded Linux

[nctnico]

I think we are still on extremes, here. It can be rather more murky even given onerous specs.

We don't need to be on extremes; extremes may be easier to understand though. But a motor controller FOC is a perfect example of "everyday" commodity stuff (millions produced, cost in dollars, see e.g. every e-scoot e-waste product) which fails in smoke in minutes if you try to run it on linux. No one just ever does it, because they know it can't be done. They know linux isn't a realtime system, basic knowledge you can read everywhere.

It is just so obvious to you guys not to run it on linux/Windows you don't even consider the idea. But that's exactly the core of the "linux isn't a realtime OS" argument. By saying "it can do multimedia", oh yes, it can, but multimedia is not a realtime embedded control application like driving a $10 e-scooter motor is. This is just a nctnico's recurring brainfart. He's wrong. Multimedia isn't the same. Screen stutter is entirely normal and relatively harmless. Case closed.

For real-time, it's bare metal or RTOS. For something which can stall for tens of milliseconds, in rarer cases for seconds, for unexpected reason, linux is fine. linux can be tuned to perform better, but at some point you are using a lot of effort (the historical linuxCNC case) on a battle you can never win. It makes no sense when the $1 microcontroller does the trick and can communicate with the linux computer through UART, so you get the benefit of both. The hardware on the linux box has a FIFO on it's UART exactly because they know linux can't do even the UART real-time. This solves the problem. Higher-level comms, hardware to deal with the timing uncertainty, partitioning the responsibilities to where they belong.

The benefit you are getting from Linux (or, say, Windows CE if you believe in that) is exactly that you get a large stack of usable stuff that doesn't need huge amount of tuning.

Again, you fall into the trap of not putting any numbers to the word 'realtime'. That is where you argument falls apart. The actual definition of realtime is meeting timing constraints. BTW, try and convince a hardcore gamer screen stutter is OK  But there are also limits to what a system (software + hardware) can do. Going beyond these limits is the fault of the designer, not the system itself. LinuxCNC is obviously pushing the boundaries too far. But that doesn't mean Linux can't be used for tasks where there is a hard time limit (been there, done that). As PlainName already noted several times, that is way too black & white.

[PlainName]

The hardware on the linux box has a FIFO on it's UART exactly because

I am struggling to think of anything that doesn't have a UART FIFO!

[PlainName]

It makes no sense when the $1 microcontroller does the trick and can communicate with the linux computer through UART, so you get the benefit of both.

I am not disagreeing with you there, but much of this thread seems to be use Linux OR have a real-time product. But, as you point out, you can shove on a cheap peripheral to do the time-sensitive whatever and then use Linux for GUI, network, storage, and everything else. It's a Linux product doing real-time work at the end of the day.

[Siwastaja]

The hardware on the linux box has a FIFO on it's UART exactly because

I am struggling to think of anything that doesn't have a UART FIFO!

Most microcontrollers do not have UART FIFO (unless you count the single data register as a special case of 1-element FIFO, fair enough), exactly because microcontrollers easily can handle that in interrupts. Higher-end MCUs do have sometimes FIFOs in UART peripherals but that's more like an optional performance optimization rather than a fundamental feature.

That's exactly the difference I'm pointing out between real-time and non-realtime systems. Even without putting exact numbers, the whole architectures are so different because timing capabilities differ so greatly.

Again, you fall into the trap of not putting any numbers to the word 'realtime'.

Sure, it's easy to put some numbers on it - most (somewhat demanding) gamers / multimedia users are fine with 5ms jitter with 99.9% (three-9) reliability, and 50ms to 99.99% (four-9) reliability, and complete crash 5 times per year. With a $1 microcontroller, it is trivially easy to do 1µs jitter with 99.99999% (seven-9) reliability, and complete crash every 500 years. We are talking about differences of at least 4-5 orders of magnitude. It is revealing in itself I don't bother defining a different reliability number for higher jitter - it doesn't exist, because it's not a probabilistic curve at all, like it is on linux.

You are right that the term "real time" is meaningless without numbers - it depends highly on context. Just like "low noise".

But sometimes fluffy terminology is good to have so that we are on the same page. tggzzz thinks computer SoCs are "MCUs", and that confuses the shit out of everyone. You call linux a "realtime OS" because it can play multimedia and for your numeric thresholds, that's "realtime enough"; but the rest of the world does not call linux a "realtime OS", but instead there is separate class of RTOS. You are right to have that opinion, but expect backlash and confusion. "Show the numbers" sentiment I wholeheartedly agree with, that's a good engineering approach.

[NorthGuy]

Again, you fall into the trap of not putting any numbers to the word 'realtime'.

These are different approaches which has nothing to do with exact time measurements.

For example, you're making a video game and try to maximize the frame rate. You don't worry that your frame rate varies over time. It is perfectly fine if it falls when you have a difficult scene to render. You do as much as you can. Or if you're mining bitcoins. You worry about how much work you do in ten years, and every particular second doesn't matter. Your goal is average performance. Therefore, the most important thing for you is computing power - how much operations can you perform per second. You don't care about delays, as long as you get more on average.

Real time is when you need to do certain things at certain moments of time, or certain events. For example, if you drive a motor you need to flip the bridge when current changes past certain threshold. Your goal is real time. What you do between switches doesn't matter. You may have tremendous computing power, or none at all. As long as you are capable of switching when needed, your computing power does not matter.

[paulca]

If you breadboard a big iron CPU, good help you, but .. the interrupt lines will get serviced as fast as you MCU or faster at 5Ghz.

That is not where the issue lies.  It lies in how you get to interact with that interrupt, assuming you have a "general purpose multi-tasking OS".

Your process states it is waiting on SIGNAL_X and the scheduler parks the process in memory.  Usually invalidating it's cache etc. 

Your UART "RxRDYINT" fires the PCI (or whatever bus you are on) INT line.  That has to clock through a few things in the various bus layers for interrupt multiplexing at bus clock speeds, not CPU.  The CPU seeing the interrupt can act on it in nanoseconds jumping a selected core to the ISR.  That OS ISR is extremely likely to just update your process to "RUNNABLE" and return in nano seconds.

Your process will not actually see that UART interrupt until the OS gets round to scheduling your process.  How long is that?  Literally... no idea.  Could be 1milliseconds, could 10, could 100, or if the system is under extreme load minutes.

There ARE "higher priority" mechanisms you can invoke in kernel driver land, more things if you run the realtime preemptive scheduler which can force abort the "cadence" to services certain interrupts immediately.

while( _lock ) {}

It wasn't my money and I didn't need to sit in a room with 196 cores per box of this.  Thats how we got <uS timing.

[nctnico]

If you breadboard a big iron CPU, good help you, but .. the interrupt lines will get serviced as fast as you MCU or faster at 5Ghz.

That is not where the issue lies.  It lies in how you get to interact with that interrupt, assuming you have a "general purpose multi-tasking OS".

Your process states it is waiting on SIGNAL_X and the scheduler parks the process in memory.  Usually invalidating it's cache etc. 

Your UART "RxRDYINT" fires the PCI (or whatever bus you are on) INT line.  That has to clock through a few things in the various bus layers for interrupt multiplexing at bus clock speeds, not CPU.  The CPU seeing the interrupt can act on it in nanoseconds jumping a selected core to the ISR.  That OS ISR is extremely likely to just update your process to "RUNNABLE" and return in nano seconds.

Your process will not actually see that UART interrupt until the OS gets round to scheduling your process.  How long is that?  Literally... no idea.  Could be 1milliseconds, could 10, could 100, or if the system is under extreme load minutes.

There ARE "higher priority" mechanisms you can invoke in kernel driver land, more things if you run the realtime preemptive scheduler which can force abort the "cadence" to services certain interrupts immediately.

That is the way it works indeed. A couple of years ago I supervised a project that involved receiving & decoding radio communication signals in realtime. SDR hooked up to a PC over USB which streamed the downconverted IQ samples (IIRC 80MB/s all together). That system ran Linux and we simply assigned 1 core specific to the decoding task and let other cores do housekeeping. That setup had to run continuously for months and it did. Without dropping a single frame (which would be bad because then the whole decoding stack would need to re-synchronise and we would have a gap in the data analysis).