5 ms·

Great to hear. However even if Linux the kernel is real-time, likely the hardware won't be due to caches and internal magic CPU trickery. Big complex hardware

• wholesomepotato 3y ago
  Features of modern CPUs don't really prevent them from real time usage, afaik. As long as something is bounded and can be reasoned about it can be used to build a real time system. You can always assume no cache hits and alikes, maximum load etc and as long as you can put a bound on the time it will take, you're good to go.
  • synergy20 3y ago
    mlock your memory, test with cache miss and cache invalidation scenarios will help, using no heap for memory allocation, but it's a bit hard
    • jeffreygoesto 3y ago
      Right. But still possible. https://www.etas.com/en/applications/etas-middleware-solution.php https://www.etas.com/en/applications/etas-middleware-solutio...
    • eschneider 3y ago
      Does anyone use paged memory in hard realtime systems?
  • SAI_Peregrinus 3y ago
    Exactly. "Real-time" is a misnomer, it should be called "bounded-time". As long as the bound is deterministic, known in advance, and guaranteed, it's "real-time". For it to be useful it also must be under some application-specific duration. The bounds are usually in CPU cycles, so a faster CPU can sometimes be used even if it takes more cycles. CPUs capable of running Linux usually have higher latency (in cycles) than microcontrollers, but as long as that can be kept under the (wall clock) duration limits with bounded-time it's fine. There will still be cases where the worst-case latency to fetch from DRAM in an RT-Linux system will be higher than a slower MCU fetching from internal SRAM, so RT-Linux won't take over all these systems.
  • bloak 3y ago
    So the things that might prevent you are: 1. Suppliers have not given you sufficient information for you to be able to prove an upper bound on the time taken. (That must happen a lot.) 2. The system is so complicated that you are not totally confident of the correctness of your proof of the upper bound. 3. The only upper bound that can prove with reasonable confidence is so amazingly bad that you'd be better off with cheaper, simpler hardware. 4. There really isn't a worst case. There might, for example, be a situation equivalent to "roll the dice until you don't get snake eyes". In networking, for example, sometimes after a collision both parties try again after a random delay so the situation is resolved eventually with probability one but there's no actual upper bound. A complex CPU and memory system might have something like that? Perhaps you'd be happy with "the probability of this operation taking more than 2000 clock cycles is less than 10^-13" but perhaps not.
    • formerly_proven 3y ago
      You're probably thinking about bus arbiters in 4.), which are generally fast but have no bounded settling time.
  • dooglius 3y ago
    System management mode is one example of a feature on modern CPUs that prevents real-time usage https://wiki.linuxfoundation.org/realtime/documentation/howto/debugging/smi-latency/smi https://wiki.linuxfoundation.org/realtime/documentation/howt...
• nraynaud 3y ago
  I think it's really useful on 'big' MCU, like the raspberry pi. There exists an entire real time spirit there, where you don't really use the CPU to do any bit banging but everything is on time as seen from the outside. You have timers that receive the quadrature encoders inputs, and they just send interrupt when they wrap, the GPIO system can be plugged to the DMA, so you can stream the memory to the output pins without involving the CPU (again, interrupts at mid-buffer and empty buffer). You can stream to a DAC, stream from a ADC to memory with the DMA. A lot of that stuff bypasses the caches to get a predictable latency.
  • stefan_ 3y ago
    Nice idea but big chip design strikes again: on the latest Raspberry Pi, GPIO pins are handled by the separate IO chip connected over PCI Express. So now all your GPIO stuff needs to traverse a shared serial bus (that is also doing bulk stuff like say raw camera images). And already on many bigger MCUs, GPIOs are just separate blocks on a shared internal bus like AHB/APB that connects together all the chip IP, causing unpredictable latencies.
• 0xDEF 3y ago
  >Big complex hardware is a no-no for true real-time. SpaceX uses x86 processors for their rockets. That small drone copter NASA put on Mars uses "big-ish" ARM cores that can probably run older versions of Android.
  • ska 3y ago
    Does everything runs on those CPUs though? Hard realtime control is often done on much simpler MCU at the lowest level, with oversight/planning for a high level system....
    • zokier 3y ago
      In short, no. For Ingenuity (the Mars2020 helicopter) the flight computer runs on pair of hard-realtime Cortex R5 MCUs paired with a FPGA. The non-realtime Snapdragon SoC handles navigation/image processing duties. https://news.ycombinator.com/item?id=26907669 https://news.ycombinator.com/item?id=26907669
      • ska 3y ago
        That's basically what I expected, thanks.
• SubjectToChange 3y ago
  Big complex hardware is a no-no for true real-time. There are advanced real time cores like the Arm Coretex-R82. In fact many real time systems are becoming quite powerful due to the need to process and aggregate ever increasing amounts of sensor data.
• snvzz 3y ago
  >8051 will truly live forever. 68000 is the true king of realtime.