How Could I predict of loop speed of Microcontrollers ?

[T3sl4co1l]

Peripherals designed to work with high-priority, high-accuracy safety signals, such as motor controller peripherals, implement their own low-latency, low-jitter input channels directly into that peripheral. (Like a motor controller / power controller bridge overcurrent signal.)

Yup, it's one thing to expect so-and-so amount of computation, but anything you can offload to peripherals is that much more certainty that your software can potentially be correct and on time.

I'm well-read on the AVR XMEGA family, which offers a timer mode with ganged timer-compare channels into a sequencer output -- intended for real-time motor drive applications, for example.  It also has an event system, which varies in scope across the family, but most support an input from a GPIO pin, analog comparator or ADC reading, and events can trigger interrupt, ADC sampling, timer compare, waveform output disable, or etc. functions.

A very typical application, then, would be the waveform generator output pins going to gate driver ICs to MOSFETs to the motor, and a current sense resistor going to the analog comparator.  It's a nearly self-contained system, very little support hardware required -- and most of it the necessary interfacing stuff that isn't easy to avoid (i.e., gate drivers and MOSFETs).  And you can get 100% the full performance of a real purpose-made controller ASIC, if your code is up to snuff.

I'm less closely familiar with say the STM32 family; I know they have more complex timers and waveform generation features, but I don't know offhand which ones are best suited to something like motor or SMPS control.  Think I've seen a few appnotes suggesting candidates, so it's a thing.  I know there are some PICs with onboard SMPS logic (e.g. peak-current-mode latch and comparator).  These sorts of peripherals start to lie on the special-purpose side, but the applications are also common enough that they're worth selling (apparently).

Simpler, or older/more primitive, peripherals may not be so easy to adapt, or (ab)use.  ATMEGA family for example isn't really suitable for SMPS controls: the ADC is too slow (typically 10s kSa/s), the analog comparator is an embarrassment (a few us delay), there's no event system (so you have to set a timer output from a comparator input, via interrupt service only; or possibly through a jumper wire if there's a dedicated trigger input pin), and no internal hardware to solve this kind of problem.  The older MCUs: PICs, 8051s, HC08s, and really old peripherals like your 8155s and 8253s and Z80-CTC and etc., might've been little more than counters and registers with a bus interface; more of a shortcut to avoid using a dozen logic chips, than a dedicated peripheral all its own.

Of course, going that far back in history, you'd be more than happy to put in the (discrete) logic yourself, or solve the whole thing analog, for that matter.

Going completely the opposite direction, peripherals can be emulated completely in software, given enough CPU cycles.  You can run a 6502 CPU completely in your browser, at the transistor level, at I think much better than real-time speed?  No reason you can't extend that to a whole PC (say, a C64), or any of their peripherals.  The problem again comes down to timing: CPUs this powerful, are rarely as consistent as we might like, and often have to yield cycles to an operating system.  Interrupt latencies can be worse, and definitely are in relative terms -- IIRC, typical latency on modern PCs is fractional-microsecond, which is to say, thousands of CPU cycles (and perhaps tens of thousands if it's multicore, if we were to naively sum them together).  Buffered IO is mandatory in these environments, and indeed that's what we have in our architectures (e.g., memory-mapped PCIe buffers).  If we don't have such facilities handy, for example if we wish to use a Raspberry Pi's GPIO pins for tight timing -- we're going to be disappointed, and may actually have worse performance than a less powerful, but simpler, platform.

A relevant example, rPi with NES interface:
The original(?), glitchy, but impressive: https://youtu.be/ar9WRwCiSr0
Much improved: https://youtu.be/gCWhWBtu0LA
The technical discussion in both should be very relevant to this thread, actually.

Tim