Still calling your new 64-bit chips STM32, just like your 32-bit chips, instead of STM64, feels like your branding/marketing team is asleep at the wheel or just non-existent.
AMD Athlon 64 was also backwards compatible to 32 bity yet nobody was confused about that from the 64 in the name, that it would somehow only run 64 bit code.
It's more the reverse of that implication. E.g. 2 years from now a 64 bit only STM chip could well be released instead of a hybrid 32 bit and 64 bit that also is fully 32 bit compatible. That's not really a problem on backwards-compatibility focused x86 where ~20 years after AMD64 the newly launched 7950X still supports booting ~30 year old 16 bit MS-DOS (and maybe older, I haven't tried).
It's like when Microchip bought Atmel they released the XTiny series. And they're not even that similar, so it has caused just a bunch of confusion. I suspect the same will happen with the STM32s that kinda are but also aren't.
NXP also has an automotive line of chips called S32. In addition to only some of that line being 32-bit, it's terribly confusing to have those juxtaposed with STM32... would be nice for one of them to change their naming up a bit
> Do you take external DDR RAM on an application-class ARM core? You're an MPU.
The actual difference IMHO is the existence of an MMU. (Which is, fdpic/linux-nommu efforts notwithstanding, the general "Linux" condition.)
(Ex.: the SOPHGO SG2000 RISC-V chip comes with integrated DDR3 RAM, but is still solidly an MPU. I believe there are some ARM Cortex-A with integrated RAM too, can't think of any off the top of my head. [Ed.: nevermind, the SG2000 is dual RISC-V/ARM])
Then the 8-bit ATMega328p in the Arduino Uno is an MPU[1]. Except it's solidly an MCU. I'd say if it uses external RAM as its main memory, and external storage as its main storage, then it's an MPU. If the RAM is all internal, and the storage is all (or can be all) internal, it's an MCU.
That’s a gimmick. I’m talking about how given chip is supposed to be used in a real products, whether vendor supplies Linux builds in one way or another, etc.
MPU -> Microprocessor. MPUs typically have features that let it support a "full" OS; MMUs, speculative execution, advanced CPU pipelining features, etc. They also have a much higher RAM capacity. Often has more complicated power requirements when doing board design due to needing different voltage busses for different peripherals. Usually can't be run standalone, you have to bring some of your own peripheral hardware. For example, you usually need to bring your own RAM.
MCU -> Microcontroller. Low power, less RAM, limited MMU/memory protection features, typically run baremetal firmware or an RTOS. Usually so simple it only needs a single voltage rail. More or less self-contained. Has RAM and ROM on-die.
SoC -> System-on-a-chip. Actually a very vague term. But in broad strokes, an SoC is what it says: An entire system on a single chip. Could incorporate an MCU or an MPU, plus other peripherals, etc. You can almost think of it as a "single chip computer" as opposed to a "single board computer". It's almost more of a marketing term than an EE term. For example, the Apple Silicon stuff is a "SoC" because it has the MPU + GPU + RAM on a single die.
I tend to think of an SoC as "MCU with other peripherals not typically on an MCU", so BLE/WiFi radio or maybe gate drivers for motor control. But usually radios. As you pointed out "not typically on an MCU" is a moving target. Was a point where RAM and a decent ADC would be things you had to add externally.
Does anyone know why some of the balls in the (render pics) are missing around the edges?
Unrelated: Would this be suitable for a CV system eg in robotics? Eg do the realtime stuff on the Cortex-M, and run a linux + OpenCV/OpenVINO etc on the Cortex-A?
This is how it is intended to be used (real-time tasks on the Cortex-M, Linux on the Cortex-A).
Nevertheless its 64-bit core is optimized for low-power, so it also has low performance.
If the applications intended to run under Linux are more demanding, one may need at least some SoC with Cortex-A55 cores (e.g. from NXP), if not one with medium-size cores, like the RK3588 (with quadruple Cortex-A76 + GPU + NPU + some Cortex-M) or one of the overpriced SoCs from Mediatek, Qualcomm or NVIDIA (these latter 3 have worse price/performance than Intel/AMD CPUs).
Unless a price under $100 is a condition, the easiest way to make a CV system for robotics is by using one of the very small computers that are available with Intel N100 CPUs (there are models much smaller than a NUC, either at a Pico-ITX size or even smaller, while prices are under $200).
The balls are missing to enable making connections to inner balls in a board with fewer layers.
The outer balls take up space and so block the traces from inner balls. By strategically removing some of the outer balls, you create channels that can be used for routing taxes from the inner balls.
That makes sense! I wish I saw this on their MCU line... (Although you can thread a tiny trace between the balls depending on manufacturer, I don't like it!
It all comes down to cost. These BGA chips have pins under the device unlike older packages like QFP or DIP. The pattern of missing pins is designed so it a fewer signal layers to bring out all the sigal connections in a typical PCB process. Devices with full grids would need more layers or tighter tolerances.
The appeal of STM32MP1 is you can put DDR momery with the chip on a 4 layer board. ST even provides the layout.
FWIW, at least 10 years (maybe at 85°C) is expected of any µP/µC worth its salt outside consumer use. It's just that consumers have accepted somewhat junk-y electronics as a fact of life. (Ok, the improvement cycle is also still quite rapid, meaning a consumer might want to update after 3~5 years anyway.)
Considering warranty periods on some goods, you also really don't want to build stuff with lower rated chips—it'll come back to bite you. Imagine having to pay a professional to swap out the controller board on a smart heating system… people might have accepted swapping out their TV every few years, but for a stove or fridge we're not there yet (and honestly I hope we never get there.)
Leaving the consumer space, it's just expected. If your CNC mill has an x86 control PC, it's a ruggedized industrial build, and those use embedded CPUs with better ratings. Cars are off on a different planet for regulatory reasons, same for aviation or military use.
I worked on validation at Intel and the primary source of faults over time is electromigration in the lower metal layers and our failure rates went out to 7 years (and there are multiple scenario %-failure curves in that window), and we dialed that back during the war with Athlon. Other sources of error are bit failures in sense amps in low-voltage SRAM circuits. Hitting reliability above 105 C Tj was really really really expensive for the big die sizes of Intel CPUs in the 2000s. Claiming the crown for low-yield high-performance CPUs required relaxing a lot of failure rates. However, intel was so paranoid to begin with, it didn't lead to massive failures but remember that industrial consumers have much more rigid requirements around reliability than gamers.
STM32MPxx are MPU (microprocessor) families, taking more standard DDR* class RAM and running Linux.
MCUs are all well under 10MB of onboard RAM (often single-digit kbytes, but bigger MCUs exist). And if they support external RAM, its MCU-protocols like SPI-RAM (which rarely goes much further than 1MB)
> And if they support external RAM, its MCU-protocols like SPI-RAM (which rarely goes much further than 1MB)
That's not generally true. A lot of higher-end STM32 MCUs have support for external SRAM/SDRAM -- I have a STM32H7 board on my desk with 32 MB, for instance. (Support for memory-mapped SPI/QSPI/OSPI RAM is actually less common.)
You're correct that internal SRAM is typically no more than 1-2 MB on even the largest parts, though.
53 comments
[ 3.1 ms ] story [ 157 ms ] threadEven Nintendo figured that out ~30 years ago.
Like this for example:
"developers can use the same STM32Cube tools"
So maybe they are saving STM64 for something that has more breaking changes, requires a different toolset, etc?
And it's because of egos of marketing departments that think they know better than engineers.
I shit you not, Microchip has a over 400 page internal PowerPoint that covers decoding their schemes and they keep adding more.
Still seems very strange to label 64-bit processors STM32...
There's a blurry line sometimes, but Application-class (Cortex A* cores, like A5, A35, etc. etc.) are solidly MPU. Not even close.
The actual difference IMHO is the existence of an MMU. (Which is, fdpic/linux-nommu efforts notwithstanding, the general "Linux" condition.)
(Ex.: the SOPHGO SG2000 RISC-V chip comes with integrated DDR3 RAM, but is still solidly an MPU. I believe there are some ARM Cortex-A with integrated RAM too, can't think of any off the top of my head. [Ed.: nevermind, the SG2000 is dual RISC-V/ARM])
It’s a little outdated but this blog post is a pretty good overview of the options available [1].
[0] - https://www.nuvoton.com/products/microprocessors/arm9-mpus/
[1] - https://jaycarlson.net/embedded-linux/
[1] https://github.com/raspiduino/arv32-opt
As an aside, I'm pretty sure these chips were announced months ago despite what the article says.
For ARM, its rather simple. Cortex-M cores are MCUs, while Cortex-A cores are Microprocessors.
Cortex A72?? That's a Microprocessor.
Cortex M7? This is a Microcontroller.
MCU -> Microcontroller. Low power, less RAM, limited MMU/memory protection features, typically run baremetal firmware or an RTOS. Usually so simple it only needs a single voltage rail. More or less self-contained. Has RAM and ROM on-die.
SoC -> System-on-a-chip. Actually a very vague term. But in broad strokes, an SoC is what it says: An entire system on a single chip. Could incorporate an MCU or an MPU, plus other peripherals, etc. You can almost think of it as a "single chip computer" as opposed to a "single board computer". It's almost more of a marketing term than an EE term. For example, the Apple Silicon stuff is a "SoC" because it has the MPU + GPU + RAM on a single die.
MCU is a controller so you supply target to control.
SoC is a system so you supply tasks to execute.
disclaimer: above is all I hallucinating.
Unrelated: Would this be suitable for a CV system eg in robotics? Eg do the realtime stuff on the Cortex-M, and run a linux + OpenCV/OpenVINO etc on the Cortex-A?
Nevertheless its 64-bit core is optimized for low-power, so it also has low performance.
If the applications intended to run under Linux are more demanding, one may need at least some SoC with Cortex-A55 cores (e.g. from NXP), if not one with medium-size cores, like the RK3588 (with quadruple Cortex-A76 + GPU + NPU + some Cortex-M) or one of the overpriced SoCs from Mediatek, Qualcomm or NVIDIA (these latter 3 have worse price/performance than Intel/AMD CPUs).
Unless a price under $100 is a condition, the easiest way to make a CV system for robotics is by using one of the very small computers that are available with Intel N100 CPUs (there are models much smaller than a NUC, either at a Pico-ITX size or even smaller, while prices are under $200).
The outer balls take up space and so block the traces from inner balls. By strategically removing some of the outer balls, you create channels that can be used for routing taxes from the inner balls.
The appeal of STM32MP1 is you can put DDR momery with the chip on a 4 layer board. ST even provides the layout.
Considering warranty periods on some goods, you also really don't want to build stuff with lower rated chips—it'll come back to bite you. Imagine having to pay a professional to swap out the controller board on a smart heating system… people might have accepted swapping out their TV every few years, but for a stove or fridge we're not there yet (and honestly I hope we never get there.)
Leaving the consumer space, it's just expected. If your CNC mill has an x86 control PC, it's a ruggedized industrial build, and those use embedded CPUs with better ratings. Cars are off on a different planet for regulatory reasons, same for aviation or military use.
MCUs are all well under 10MB of onboard RAM (often single-digit kbytes, but bigger MCUs exist). And if they support external RAM, its MCU-protocols like SPI-RAM (which rarely goes much further than 1MB)
That's not generally true. A lot of higher-end STM32 MCUs have support for external SRAM/SDRAM -- I have a STM32H7 board on my desk with 32 MB, for instance. (Support for memory-mapped SPI/QSPI/OSPI RAM is actually less common.)
You're correct that internal SRAM is typically no more than 1-2 MB on even the largest parts, though.