The idea is to move realtime-ish stuff to a popular processor many people have worked with and moving the Linux stuff over to an appropriate platform.

When it came out we used STM32MP257 to demo a quadrature encoder debugger/logger (for internal use, not a product) since the IO supports easy interfacing of encoders. The micro's peripherals (SPI, I2C, GPIO etc.) are easy to program at the register level and you can run a simple mainloop+interrupts thing on the micro, then run Linux for your UI, networking, etc.

The fact that there's not much activity around these kinds of platforms (CPU+micro or CPU+FPGA) suggests it's too hard to combine the two in a way that makes sense for enough people, easier to just use standard components and have them side-by-side on the PCB.

It is nice to have them on the same die, though, for people like myself who like to work on both ends but don't know how to make their own PCBs.

Calling Cortex-A35 "full-desktop-capable" is quite a stretch.

Even if it supports the 64-bit ARM ISA, it is a very small and slow core, much slower than even the little Cortex-A53 and Cortex-A55 cores, which were used in the early Raspberry Pi versions.

As mentioned in TFA, at the same clock frequency Cortex-A35 is much slower than the fastest microcontroller cores, i.e. Cortex-M85 and Cortex-M7.

The only advantage of Cortex-A35 is that it has a deeper pipeline, which increases the latency of many things, like interrupt handling, but it allows a higher clock frequency, thus a greater throughput.

Having a MMU, it is suitable for Linux, but using it for a desktop would be ridiculous, as even the slowest Atom CPU from 17 years ago was much faster.

The processor by Texas Instruments used in the Beaglebone boards had a main CPU plus two small cores inside the die. Unfortunately those two smaller cores didn't get their own compiler until the Beaglebone was many years old and easier to use, more open source products ate TI's lunch in that domain. (Although TI has never been concerned with the hobbyist domain).

But once TI provided that compiler it was easier for people to have the two smaller cores handle peripherals in real time, while the main processor was busy. Those kinds of heterogenous chips are super interesting if you're into bare metal programming.

It’s common for embedded systems to have some powerful cores running Linux and some microcontroller cores running real time code.

The fusion of the two is very valuable if you have applications that require real time work.

> I presume they're trying to milk value out of the name recognition but they're just diluting the name.

No, absolutely not. This is a very valuable structure for embedded work and it’s very common. I don’t know why you’d jump to such a cynical conclusion.

We do this (on different SoC) for real-time application protocols.

You keep the linux on the beafy cheip, and hand over the real-time stuff to the M0.

Seems normal to me. Microchip also puts their 32-bit and 64-bit chips with their SAM and PIC64 names.

Must be an embedded thing.

Even desktop and smartphone platforms come with MCU grade co-processors these days for low level tasks like power and sleep management.