A task would usually be considered realtime to some degree if it cannot automatically get its work done on time even when competing with a background-priority long-running job—for example, if your deadlines are operating on similar or smaller timescales to the operating system's CPU scheduler. Then you need to start taking extra measures to ensure adequate responsiveness, not just adequate throughput.

But there's also the aspect of consequences of missing a deadline. Most realtime tasks are concerned with millisecond or shorter timescales, but a job that must be performed once every 108 minutes to prevent the end of the world would also be reasonably considered a realtime task.

At least wrt soft realtime scheduling for audio, I think users/programmers tend to get severely tripped up because the latencies are simply too small for them to make a clear mental model of the underlying system. That, along with their ineluctable desire for their code to "go faster" drives them to request features or design algorithms which would have to travel "back to the future" in order to work at all.

So it would be nice to decouple "ultra-low latency" from "realtime" to make it clear that, say, you can't put the heart on ice after the helicopter already lifted off to fly it to the hospital.

i.e. A spacecraft that requires a thruster to be fired with accuracy of a few hundred milliseconds in two years time has mission/safety critical timing requirements. Therefore this is hard-real-time

Alternatively, a payroll that has to run at the end of every month will not cause people to miss payments if that deadline is missed by any relatively large amount of time (minutes/hours). The timing requirements are not mission critical at this point. They could be considered soft-realtime tho as there is still an upper bound to desired behaviour.

To me, realtime means "responds faster than the fastest it needs to in order to control a feedback loop" which is super subjective since different system dynamics are so different.

When I tried to use RTOS it appeared to be that better than 1ms resolution was not remotely possible. Just hardcoding the interrupts resulted in 1us resolution easily.

I grant that the RTOS provides a scheduler, but when this chip says that it is intended for "realtime" does it mean that it's microsecond fast even when running RTOS, that it's capable of running fast with handwritten interrupts and code (which to me seems to be most things), or just that it has a spec for an upper bound on op timing?

I guess the last is important for correctness proofs but the prior two are how I interpret it as a confused person reading marketing materials put out by conflicting sources.

Stuff like branch prediction probably isn't too useful to implement as a switchable feature. Instead, the core is designed so that mispredict latency is still reasonably short (short pipeline, in-order execution or OoO with a short reorder window). This means you won't get as much benefit from speculative work as you would on a desktop-class core, but you're probably not going to be as vulnerable to Spectre-style attacks, either.

So, there is a spectrum of realtime and how "hard" it needs to be. There are a lot of cases where simply having a real time OS on a traditional processor is fine as long as everything can be sufficiently bounded.

I've only worked with one RTOS, and a lightweight one at that.

The scheduler would run every time an interrupt handler finished running.

One such interrupt was the 'systick' - you can choose if you want it to run every 1ms, or 100us, or a different rate (depending on how fast your CPU is)

The systick was how you timed anything you didn't want to use a dedicated hardware timer for. If you want to wait 10ms and your systick happened every 1ms, you waited until the 10th systick.

If you want to time something with finer resolution than 1ms, you either made your systick faster, or used a hardware timer with the interrupt triggering the scheduler.

> Just hardcoding the interrupts resulted in 1us resolution easily.

If your CPU runs at 180MHz, 1us is enough time for 180 clock cycles. Plenty of time to run one reasonably carefully coded interrupt handler, not much time to run 10 interrupt handlers.

As you can imagine, running your systick at 1us with that clock rate would be challenging!

I would say there are two (2) sets of realtime definitions.

1) concerning amount of events

Hard realtime system always produces output to an input in predefined time (subject to clocking). This time can vary between different inputs, but is fixed for a given input.

Soft realtime systems are bound - output time is bounded to some number.

2) concerning number of inputs

Hard realtime system has bound reaction time to every possible input

Soft realtime system has bound reaction time to "critical" inputs.

---

Definitions used in practice mix the two in some ways. The most prevalent definition I happen to come across in the general internet is something like "realtime system has bounded, low-variation reaction time to critical inputs".

Specifically with the R-family ARM chips, there is support for things like tightly-coupled memory (https://developer.arm.com/documentation/ddi0338/g/level-one-...) to provide latency guarantees for real-time code, deterministic interrupts, that kind of thing.

Real-time systems show up especially in industrial control and safety systems. For example, take a logging harvester, which cuts down trees and strips their branches and bark. It has a control panel for moving incredibly violent, dangerous machinery. It is truly critical that you can guarantee that, for example, sensors which detect a problem can abort something within a very tight latency budget.

I think you are missing something here.

Real Time systems aren't designed for high performance at all and instead they are designed for predictability.

You aren't aiming to "hit your metric", you are aiming to never, even go below it.

This is useful for something like old-style spinning hard drives where you had to calculate where to move the head of the disk within the time of the rotation. You have a instructions/second budget, and you know it will execute that.

On non-realtime hardware (and software) you know how many instructions/second it can do, but things like speculative execution of caching strategies or non-RTOS mean those instructions are not guaranteed at all.

It's pretty rare in software for it to define minimum performance. There's good reasons for this - software is interacting with intrinsicly messy things (like humans) and so performance outliers are a big factor.

It's pretty common in software for the worse case to be 10x the "hit your metric" case, and this isn't viewed as bad: the worst case happens rarely enough for the trade off to be worth it.

I am coming from the hardware world, through raw assembly, to C so my path is very much the assumption that if the microcontroller is going to control a feedback loop that stabilizes at 10MHz it will be guaranteed to do so.

But I suppose that I actually do that by overspecifying things nowadays since it's much too unpredictable as you say to predict how long things will take.

To me if you say you sample at 100kHz you sample at a minimum of 100kHz. Very very good to know that if I work with a firmware engineer that they won't hear the same thing as I mean if I say that it needs to hit a 100kHz sampling rate.

It would be very disappointing if they wrote a loop designed to average a 100kHz sampling rate with random jitter... (kidding mostly, I'd assume they would at least not do that).

That value doesn't have to be anything in particular. Could be 1ms. Could be 100ms. Could be a year. It just has to exist and be documented, and never, ever be exceeded by whatever operations are covered by its guarantee.

Generally, hard realtime means missing a deadline in unacceptable, but does not necessarily imply that latency is exactly fixed—just bounded. Soft realtime means that the consequences of missing a deadline are less severe, so the system may allow for some missed deadlines: eg. dropped packets for a video conference or delayed frames for a video game are noticeable especially if they become common, but they don't crash the whole system and the system remains useful even after missing a deadline.

There's no such requirement.

All hard realtime needs is the guarantee that the value will never be exceeded.