alt Hacker News> ST seems to consistently put out faster chips [1].
They have not released anything in years, only modest incremental updates. STM32V8 is a welcome update, but it is nothing ground breaking and not available yet.
> The real reason to use a Cortex-M is determinism in hard real-time systems.
Correct.
> but at that point you either aren't making a hard real-time system and would benefit greatly from an MPU
Why not?
> allowing you to run Linux and benefit from the wealth of drivers available for these interfaces
It is precisely to avoid running Linux and the "wealth of drivers".
> or your real-time deadlines are so tight an FPGA would be a better choice
When MCUs were not good enough, the FPGA was a sensible choice. That said you won't get Cortex-M7 core on FPGA and other cores might be available, though there is not going to be any substantial performance improvement, unless you want to spend unreasonable amount of money (talking 5 figures at least).
What I am trying to point out is that there is a huge market gap.
i.MX8 is not realtime and the support for running bare metal code is very much non existent.
Replies
The easy to obtain FPGAs contain ancient ARM cores, but which are usable for implementing microcontroller tasks.
For example the AMD Xilinx UltraScale+, like in the AMD Kria modules and development kits (3-digit prices), include some Cortex-R5 cores, which provide deterministic operation, like Cortex-M.
Cortex-R5 are somewhat slower than Cortex-M7 at the same clock frequency, but they are available at a higher clock frequency than many Cortex-M7 implementations.
If you can implement some custom peripherals in the FPGA logic array, then you can obtain much higher performance than with a microcontroller alone.
> i.MX8 is not realtime and the support for running bare metal code is very much non existent.
Looking at e.g. STM32H755: 1x Cortex-M7 480 MHz, 1x Cortex-M4 240 MHz, USB2, 100 Mbit Ethernet, DAC.
Comparing to AM6421: 1x Cortex-A53 1GHz, 2x Cortex-R5F 800MHz, 1x Cortex-M4F 400MHz, 2x PRU, USB3, 1 Gbit Ethernet, PCIe Gen2.
I can hardly believe STM32H755 microcontroller is almost so costly as AM6421 SoC.
> It is precisely to avoid running Linux and the "wealth of drivers".
Why not? I understand not wanting to deal with unnecessary complexity as a hobbyist, but you'll find yourself creating far more complexity trying to implement all of this yourself (and vendors certainly don't want to support you in this). Secondly, I think the number of customers for chip vendors who are uncomfortable with setting up an embedded Linux environment, but perfectly confident in routing DDR and PCIe signals is approximately 0.
> What I am trying to point out is that there is a huge market gap.
> i.MX8 is not realtime and the support for running bare metal code is very much non existent.
This isn't quite true and is what I'm trying to get at. Most of these embedded SoCs contain a Cortex-M and a Cortex-A (not all but there are quite a lot). High performance DRAM, external PCIe devices, and large internal caches are fantastic for compute performance but most of the things you want to do with a PCIe device (networking, asynchronous compute) don't require cycle-accurate determinism. Generally there isn't much you need to do with such stringent timing requirements, so you can offload that work to secondary Cortex-M33 core with a shared memory interface to the main core and get the best of both worlds.
I see so many systems trying to take advantage of the impressive compute power of modern MCUs (which is really cool!) but often end up just re-inventing the cooperative multitasking OS, but worse.