> And a lot of these parts either don’t have crypto acceleration or security-by-obscurity lock up the docs to the crypto accelerator, which is an absolute dealbreaker for me.
I have to wonder if locking up the docs is some kind of export control or government contract requirement.
Despite STM32 in the product name, this is a dual core Cortex-A35 SOC intended to run Linux, though he brings it up as bare metal. The STM32MP257F-EV1 dev board that he used costs $425 at Digikey. His thing is interfacing it to FPGA's. So this seems to be a hardware person's product. Most of us can probably use simpler stuff. The Pocketbeagle 2 looks interesting to me.
I think you mean "despite the STM32 in the product name, they're 64 bit compatible cores." Because STM8 was 8 bit (though I've never seen one in any design ever, I'm sure they're just before my time) and STM32 MCUs and MPUs were always 32-bit.
I'm worried they dug too deep a trench with the 32. Like how do much from Espressif is an ESP32 now despite them ranging from slower single core to faster dual core, now even with mmu, some with Wi-Fi some not...
Or they could have just meant STM32 is normally synonymous with "typical slow single-core MCU" compared to multi-ghz Cortex SoCs that we see in higher-end devices that run Linux?
STM32 processors have traditionally been M-series 32-bit ARM cores including M7. I don't know if there have been any exceptions before this. But A-series is application processors with MMU's, DRAM interfaces, etc.
STM8 is still a thing and they were popular cheap embedded boards before ESP32 took over. They were ok as a cheap alternative to Arduino-compatible AVR boards. I have a few of the boards around. They were around $1 each on Aliexpress and have 8K of flash and 1K of ram, which is enough to run interactive Forth, and there's an SDCC compiler target for them.
Yes, but Cortex-A7 (the big core of MP1) is a 32-bit core, unlike Cortex-A35.
Nonetheless, the 64-bit Cortex-A35 is not the 64-bit replacement for Cortex-A7, but for the smaller core Cortex-A5, so it is actually slower than Cortex-A7 at the same clock frequency.
Cortex-A53, then Cortex-A55, were the 64-bit replacements for Cortex-A7.
That's the thing, STM32s are jellybean devices that you can tenth-source from anywhere, including some guy cooking them up in his kitchen in Shenzhen. This thing is an STM32 in name only (SINO? STINO?).
That's marketing. The iMac was a huge hit so Apple started releasing iEverything. Denny's had a hit with its "Grand Slam" breakfast now they have ten different "slams" on their menu,
STM32MP257 application processors (STM32 MPUs) are based on a dual Arm® Cortex®-A35 cores running at up to 1.5 GHz and Cortex®-M33 cores running at 400 MHz.
Why do they put a full-desktop-capable A35 processor in the sme product line as the M0 microcontrollers? I presume they're trying to milk value out of the name recognition but they're just diluting the name.
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.
The truth is that those are just niche items. Having a need for both a Linux-grade CPU and a real time MCU-like core is not that common. It tends to show up in projects too advanced for most to attempt.
That's untrue. Almost all the products I worked with in my last company had such architecture - which we leveraged (this was Ag industry). It's very easy to work as they have shared memory to talk to each other.
That's at least a tier more advanced than mainstream.
And if by "very easy to work" you mean "just allocate a shared memory block and put a mailbox in there for the Linux userspace and the RT MCU to talk to each other", you may have inflated expectations of what an average developer using an SBC can easily do. It's "very easy" in the same way rolling your own PCBs or writing your own drivers is very easy. Seasoned developers do it without thinking twice, and then stand dumbstruck when they see entry level developers avoid that like the plague.
Not like we're lacking for the offerings. Plenty of modern SoCs have MCU-like real time cores in them - intended for low power operation, real time control, or both. Even the mainstream RPi 5 boards ship spare PIO and MCU cores - in the RP1 chip. The vendor just couldn't be bothered to document that.
There’s whole sectors of industrial and automotive using these AMP SoMs. And relative to these RPi only recently began providing options that you could design into an embedded product at all. Their FAE and supply presence is way behind.
By "mainstream" I mean "the bulk of development work done", not "the bulk of units shipped".
The boards that people reach for when they roll their first projects, the hardware that ends up in early prototypes and one-off devices, the hardware that gets targeted by open source projects. The chips that return more than a "databrief" 8 pages long and a single page on a vendor site inviting you to visit the snake pit with "contact sales for more information". The boards you can actually buy with a fixed price tag and a delivery to door, and can find writeups on how to use them for specific things.
If you know what "FAE" is, let alone can get into a meeting with one, you're deep in the trenches, and are pretty much expected to wrangle an extremely poorly documented MCU core that happens to be shipped in a SoC as an afterthought into submission.
There's multiple embedded companies, NXP i.MX, TI AM355x, STMicro STM32MP1 and MP2, Xilinx Zynq... that offer either Linux-CPU + realtime MCU, or Linux-CPU + FPGA. If we include Rasp. Pi PIO, there's even more companies offering main processor + coprocessor (including ESP32).
Those are just the ones off the top of my head. I'm sure there's more if I used Google to search. And of those companies, there's *multiple* lines of chips that offer these capabilities.
Its... pretty mainstream in the embedded world. The fact is that Linux is very bad for realtime, so adding a non-Linux coprocessor is one of the easiest ways to solve the problem. Run Linux for "regular" code, and then run the hard-realtime code on a dedicated chip (either Cortex M4 or some other MCU... or maybe a Cortex-R(something)). Or in the case of Xilinx, run the realtime stuff in FPGA-land.
Alternatively, you spend a ton of money on an OS that's well suited for hard-realtime (ex: VxWorks or something), but that also requires a processor with some guarantees (usually L1-like cache that's reserved by the programmer, some "always active" hard-realtime memory). This is more difficult in practice compared to just having a 2nd MCU or FPGA handle the realtime tasks though in a coprocessor like arrangement.
-------
I dunno what you're arguing for. Are you trying to say that the world of Linux capable core + Realtime core is somehow... niche?
The parts are there, but the support and the usage? Very much not. It took years for vendors to even start shipping remoteproc support in some of the parts.
NXP's i.MX 7 was released in 2013 with Cortex-A7 + Cortex-M4 and well supported back then. And there probably were earlier chips.
Yeah Linux is slow at developing features for embedded systems. That's why embedded programmers run code outside of Linux. Fortunately, Linux has kernel modules to make it easy to do things like that.
Historically, Linux isn't even a proper embedded OS. Linux continues to get better-and-better for embedded but I'd expect that 2013-era was dominated by VxWorks or other embedded OSes with a better featureset for embedded. It was _LINUX_ that was the problem in my experience, at least back then.
But then WindRiver (makers of VxWorks) added a bunch of features to the Linux kernel and now today Linux is acceptable for embedded. I dunno exactly when the switchover from majority VxWorks embedded systems -> WindRiver Linux -> and now each manufacturer has their own BSP / Linux support... but a lot of what you're complaining about was software development.
Even then, a ton of older embedded crap ran their own custom versions of Linux 2.4 or whatever and just maintained a separate branch. I'm guessing these older embedded systems got their start in the early 00s and just had issues upgrading past the Linux 2.4 -> Linux 2.6 jump.
Or in other words: it was far more likely that Linux wouldn't support Chip X, rather than Chip X was unable to support Linux. Or maybe a chip did support Linux but most of the codebase was stuck on Linux 2.4. Or if Linux support existed, it was effectively proprietary custom kernel modules that individual teams wrote for themselves rather than a community-driven internet-based workflow. Etc. etc. Linux was harder back then.
But the stuff you're talking about is early 2010s, if not 00s. Damn well over a decade, might be closer to TWO decades (and the only reason I don't know that is because I was a wee-little ignorant student back then and don't really know things older than 2010s....)
Virtually all big computers (mainframes, workstations, rackmount servers, PCs, laptops, tablets, cellphones, and e-readers) use this architecture: the Linux-grade CPU doesn't directly drive things like the USB port, the HDMI signal, the SSD's flash translation layer, or the hard disk head movements. Instead, real-time MCU-like cores do it.
The only difference is that a lot of them are on separate chips.
Probably programming a computer is too advanced for most to attempt, so that doesn't seem like a legitimate criticism.
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.
Interrupts trash high end cores throughput and they have high latency and non deterministic execution times. Smaller cores like an Cortex-M series handle interrupts quickly and deterministically. And they are very power efficient.
That was a gut feel of mine 30 years ago. And it wasn't as bad then.
Newer gut feel but I remember a processor designer saying the same thing a few years ago. Modern systems the processor very often is doing basically jack all nothing 95% of the time. They aren't very power efficient in that mode. Where Cortex-M processors are.
A soft poke. An Arm Cortex-M4 is as powerful as an 486 of yore that was what people were running windows 3.1 on and playing DOOM.
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.
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.
I doubt that. Android has advantages only for consumer devices.
Anything with Cortex-A35/Cortex-A32/Cortex-A34 may be useful only for some embedded devices which run Linux. They are much slower than even the chips with Cortex-A53 that were used in the cheapest smartphones from more than a decade ago.
In fact anything with Cortex-A35/Cortex-A32/Cortex-A34 is too slow to be useful for anything, because much faster chips with Cortex-A55 are available at much lower prices from vendors like Rockchip and several others. Even some much better SBCs with Intel Atom CPUs are available for a price 4 times lower.
A board with Cortex-A55, PCIe, USB 3 and with everything else that the author of the TFA desired can be bought for a 10 times lower price than that ST development system.
I am using a lot of ST development boards, but they are various versions of the cheap Nucleo boards, which have an excellent price/performance ratio.
Their more expensive boards and more expensive microcontrollers that can run Linux are not competitive in price and features with the boards using cheaper N-series Intel CPUs or with the boards using various Cortex-A55, Cortex-A520, Cortex-A76, Cortex-A78 or Cortex-A720 that are available from Chinese vendors.
I'm so glad we are finally seeing small cores, something to threaten the Cortex A7, which harkens back to 2011!!
But also: Cortex A35 is from 2015! And it's still just a trickle of these small application processor cores. Having a MMU enables so much more. Look at what Baochip and Xous are doing, with small cores but with MMU, for radically better interesting OS / systems architectures.
It just feels so cursed, is so beyond my surprise here well past half way through 202X that so many cores from early 201X are still not just alive but utterly dominant. Something has gone super super super wrong in the House of ARM!
The pipeline from new ARM cores to shipping silicon is surprisingly long. Cortex-M85 was announced in 2022, and there's still almost nothing on the market that implements it.
I don't think it's merely long pipeline. Simpler explanation is that there is just not much demand for these middle-class cores; A55 cores are from same generation and started appearing in socs pretty quickly. I suspect that the benefits of A3x (compared to A5x) just werent there for vendors to justify adding them to their portfolios
As I have already mentioned in another comment, Cortex-A35 is not the replacement for Cortex-A7, but for the smaller and slower Cortex-A5. Because of that, Cortex-A35 is slower at the same clock frequency than Cortex-A7.
The successor of Cortex-A7 was Cortex-A53, which was followed by Cortex-A55, then by Cortex-A510, and so on, until the current Arm C1-Nano.
The line of Cortex-A5 and Cortex-A35, which includes Cortex-A32 and Cortex-A34, can be considered dead, because using so slow CPUs instead of the best Cortex-M or Cortex-R cores (like Cortex-M85 and Cortex-R82) does not make sense.
ranger_danger | 18 hours ago
I have to wonder if locking up the docs is some kind of export control or government contract requirement.
mastax | 13 hours ago
throwaway81523 | 17 hours ago
Neywiny | 17 hours ago
I'm worried they dug too deep a trench with the 32. Like how do much from Espressif is an ESP32 now despite them ranging from slower single core to faster dual core, now even with mmu, some with Wi-Fi some not...
What is in a name?
ranger_danger | 17 hours ago
throwaway81523 | 15 hours ago
STM8 is still a thing and they were popular cheap embedded boards before ESP32 took over. They were ok as a cheap alternative to Arduino-compatible AVR boards. I have a few of the boards around. They were around $1 each on Aliexpress and have 8K of flash and 1K of ram, which is enough to run interactive Forth, and there's an SDCC compiler target for them.
Neywiny | 14 hours ago
adrian_b | 7 hours ago
Nonetheless, the 64-bit Cortex-A35 is not the 64-bit replacement for Cortex-A7, but for the smaller core Cortex-A5, so it is actually slower than Cortex-A7 at the same clock frequency.
Cortex-A53, then Cortex-A55, were the 64-bit replacements for Cortex-A7.
pseudohadamard | 14 hours ago
duskwuff | 14 hours ago
pseudohadamard | 13 hours ago
hackingonempty | 14 hours ago
kvemkon | 16 hours ago
> The Pocketbeagle 2 looks interesting to me.
If only it had 2GB+ RAM. Since it has 4 cores, even more RAM would be better.
And 1Gbit Ethernet is what I'm missing.
Aurornis | 14 hours ago
Most would start with the significantly cheaper Discovery Kit version.
With ST, the developer kit is usually only needed if you need every pin and function exposed because you’re developing your own board.
dlcarrier | 16 hours ago
zwieback | 16 hours ago
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.
ACCount39 | 15 hours ago
azzentys | 15 hours ago
ACCount39 | 15 hours ago
And if by "very easy to work" you mean "just allocate a shared memory block and put a mailbox in there for the Linux userspace and the RT MCU to talk to each other", you may have inflated expectations of what an average developer using an SBC can easily do. It's "very easy" in the same way rolling your own PCBs or writing your own drivers is very easy. Seasoned developers do it without thinking twice, and then stand dumbstruck when they see entry level developers avoid that like the plague.
Not like we're lacking for the offerings. Plenty of modern SoCs have MCU-like real time cores in them - intended for low power operation, real time control, or both. Even the mainstream RPi 5 boards ship spare PIO and MCU cores - in the RP1 chip. The vendor just couldn't be bothered to document that.
nateglims | 15 hours ago
There’s whole sectors of industrial and automotive using these AMP SoMs. And relative to these RPi only recently began providing options that you could design into an embedded product at all. Their FAE and supply presence is way behind.
ACCount39 | 14 hours ago
The boards that people reach for when they roll their first projects, the hardware that ends up in early prototypes and one-off devices, the hardware that gets targeted by open source projects. The chips that return more than a "databrief" 8 pages long and a single page on a vendor site inviting you to visit the snake pit with "contact sales for more information". The boards you can actually buy with a fixed price tag and a delivery to door, and can find writeups on how to use them for specific things.
If you know what "FAE" is, let alone can get into a meeting with one, you're deep in the trenches, and are pretty much expected to wrangle an extremely poorly documented MCU core that happens to be shipped in a SoC as an afterthought into submission.
dragontamer | 10 hours ago
Those are just the ones off the top of my head. I'm sure there's more if I used Google to search. And of those companies, there's *multiple* lines of chips that offer these capabilities.
Its... pretty mainstream in the embedded world. The fact is that Linux is very bad for realtime, so adding a non-Linux coprocessor is one of the easiest ways to solve the problem. Run Linux for "regular" code, and then run the hard-realtime code on a dedicated chip (either Cortex M4 or some other MCU... or maybe a Cortex-R(something)). Or in the case of Xilinx, run the realtime stuff in FPGA-land.
Alternatively, you spend a ton of money on an OS that's well suited for hard-realtime (ex: VxWorks or something), but that also requires a processor with some guarantees (usually L1-like cache that's reserved by the programmer, some "always active" hard-realtime memory). This is more difficult in practice compared to just having a 2nd MCU or FPGA handle the realtime tasks though in a coprocessor like arrangement.
-------
I dunno what you're arguing for. Are you trying to say that the world of Linux capable core + Realtime core is somehow... niche?
ACCount39 | 4 hours ago
The parts are there, but the support and the usage? Very much not. It took years for vendors to even start shipping remoteproc support in some of the parts.
dragontamer | an hour ago
NXP's i.MX 7 was released in 2013 with Cortex-A7 + Cortex-M4 and well supported back then. And there probably were earlier chips.
Yeah Linux is slow at developing features for embedded systems. That's why embedded programmers run code outside of Linux. Fortunately, Linux has kernel modules to make it easy to do things like that.
Historically, Linux isn't even a proper embedded OS. Linux continues to get better-and-better for embedded but I'd expect that 2013-era was dominated by VxWorks or other embedded OSes with a better featureset for embedded. It was _LINUX_ that was the problem in my experience, at least back then.
But then WindRiver (makers of VxWorks) added a bunch of features to the Linux kernel and now today Linux is acceptable for embedded. I dunno exactly when the switchover from majority VxWorks embedded systems -> WindRiver Linux -> and now each manufacturer has their own BSP / Linux support... but a lot of what you're complaining about was software development.
Even then, a ton of older embedded crap ran their own custom versions of Linux 2.4 or whatever and just maintained a separate branch. I'm guessing these older embedded systems got their start in the early 00s and just had issues upgrading past the Linux 2.4 -> Linux 2.6 jump.
Or in other words: it was far more likely that Linux wouldn't support Chip X, rather than Chip X was unable to support Linux. Or maybe a chip did support Linux but most of the codebase was stuck on Linux 2.4. Or if Linux support existed, it was effectively proprietary custom kernel modules that individual teams wrote for themselves rather than a community-driven internet-based workflow. Etc. etc. Linux was harder back then.
But the stuff you're talking about is early 2010s, if not 00s. Damn well over a decade, might be closer to TWO decades (and the only reason I don't know that is because I was a wee-little ignorant student back then and don't really know things older than 2010s....)
kragen | 7 hours ago
Aurornis | 14 hours ago
Engineers actually use these in real products and embedded systems.
The combination of Linux and microcontrollers isn’t new. It’s a very valuable and common structure.
The comments here trying to dismiss it or call it uncommon are bizarre.
iamflimflam1 | 7 hours ago
kragen | 7 hours ago
The only difference is that a lot of them are on separate chips.
Probably programming a computer is too advanced for most to attempt, so that doesn't seem like a legitimate criticism.
dragontamer | 15 hours ago
Must be an embedded thing.
Aurornis | 14 hours ago
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.
dingi | 11 hours ago
Gibbon1 | 6 hours ago
That was a gut feel of mine 30 years ago. And it wasn't as bad then.
Newer gut feel but I remember a processor designer saying the same thing a few years ago. Modern systems the processor very often is doing basically jack all nothing 95% of the time. They aren't very power efficient in that mode. Where Cortex-M processors are.
A soft poke. An Arm Cortex-M4 is as powerful as an 486 of yore that was what people were running windows 3.1 on and playing DOOM.
harrouet | 8 hours ago
You keep the linux on the beafy cheip, and hand over the real-time stuff to the M0.
Schlagbohrer | 7 hours ago
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.
adrian_b | 7 hours ago
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.
mizmar | 6 hours ago
adrian_b | 6 hours ago
Anything with Cortex-A35/Cortex-A32/Cortex-A34 may be useful only for some embedded devices which run Linux. They are much slower than even the chips with Cortex-A53 that were used in the cheapest smartphones from more than a decade ago.
In fact anything with Cortex-A35/Cortex-A32/Cortex-A34 is too slow to be useful for anything, because much faster chips with Cortex-A55 are available at much lower prices from vendors like Rockchip and several others. Even some much better SBCs with Intel Atom CPUs are available for a price 4 times lower.
A board with Cortex-A55, PCIe, USB 3 and with everything else that the author of the TFA desired can be bought for a 10 times lower price than that ST development system.
I am using a lot of ST development boards, but they are various versions of the cheap Nucleo boards, which have an excellent price/performance ratio.
Their more expensive boards and more expensive microcontrollers that can run Linux are not competitive in price and features with the boards using cheaper N-series Intel CPUs or with the boards using various Cortex-A55, Cortex-A520, Cortex-A76, Cortex-A78 or Cortex-A720 that are available from Chinese vendors.
jauntywundrkind | 16 hours ago
But also: Cortex A35 is from 2015! And it's still just a trickle of these small application processor cores. Having a MMU enables so much more. Look at what Baochip and Xous are doing, with small cores but with MMU, for radically better interesting OS / systems architectures.
It just feels so cursed, is so beyond my surprise here well past half way through 202X that so many cores from early 201X are still not just alive but utterly dominant. Something has gone super super super wrong in the House of ARM!
duskwuff | 7 hours ago
The pipeline from new ARM cores to shipping silicon is surprisingly long. Cortex-M85 was announced in 2022, and there's still almost nothing on the market that implements it.
adrian_b | 6 hours ago
So if you are willing to pay a high price, which might not be worthwhile, it is not difficult to find MCUs or development systems with Cortex-M85.
zokier | 2 hours ago
adrian_b | 6 hours ago
The successor of Cortex-A7 was Cortex-A53, which was followed by Cortex-A55, then by Cortex-A510, and so on, until the current Arm C1-Nano.
The line of Cortex-A5 and Cortex-A35, which includes Cortex-A32 and Cortex-A34, can be considered dead, because using so slow CPUs instead of the best Cortex-M or Cortex-R cores (like Cortex-M85 and Cortex-R82) does not make sense.
brcmthrowaway | 14 hours ago