This was semi-discussed 4 days ago when someone posted the release announcement of the MP1, which is a few years old (https://news.ycombinator.com/item?id=37218879). Someone pointed out the MP2 had been announced in the meantime.
This announcement itself is from 2023-06-05, so not exactly hot off the presses either.
I'd probably choose a much more compute/graphics focused SoC for a games console, like almost any smartphone SoC or even an APU.
These STM32MP parts are designed for devices with realtime needs and real-world interface requirement, because they combine Application Processors that run Linux (albeit not quite as fast as a cutting-edge phone SoC) with a Cortex-M core made for realtime application use, as well as interface peripherals like CAN. Basically these are supposed to be a bridge between the "embedded" world and the "Linux" world.
The integrated Ethernet switch is only as useful as its software stack - I say this after an excruciating decade with TI's Sitara devices (and the built-in CPSW ethernet switch.)
' An OEM launch means that original equipment manufacturers are starting to get samples. Consequently, if all goes well, we expect general sampling to begin at the end of the year and mass production by the second quarter of 2024 for both devices and development boards.'
So a year away before the first Pi-a-like or SBCs for hobbyists/hackers hit the market
High-performance STM32 chips have been in short supply since 2019, with backorder times in the range of years. There's a reason why you don't see a whole lot of hobby boards using them today.
So, as a hobbyist, I wouldn't be getting my hopes up for 2024...
>So, as a hobbyist, I wouldn't be getting my hopes up for 2024...
Meh, if you're a hobbyist you can migrate to any other ARM board you can find on the cheap in your area. No need to pigeonhole yourself in the STM32 ecosystem.
Whether it was clear to you or that OP specifically was asking about the GPU, you shouldn't be so confident in universals like this. In this case, it turns out to be basically false in that the driver for the GPU is closed source:
There is an open source driver for Vivante GPUs, including the GC400 (or maybe GCNano? and the official docs are oddly vague on what GPU is used and 3rd party sources disagree) used in the STM32MP157: etnaviv. I can't seem to find anything on what's in the STM32MP2 though other than that it supports Vulkan though. Not sure why ST is so tight-lipped on what GPU IP they're using
This seems to blur the lines. Writing bare metal for Cortex-M is straightforward. For your desktop or laptop PC? Your phone? Doable OFC, but probably very difficult.
Sure. But that difficulty all comes down to whose shoulders you stand on. If the peripherals' functionalities and their registers are fully described in a datasheet, and you have a working toolchain, and a viable method for loading binaries, then you are set. Additional libraries on top would make it even easier, but you at least have the device's specifications.
Companies like Qualcomm, Broadcom, and Marvell are notorious for locking down their documentation. If you're not shipping millions of units, they're not going to give you the time of day. And even if they are willing to work with you, they're not going to provide you with full register maps, or really anything that would allow you to be independent of them. Instead, they'll give you binary blobs that handle low level details. Every datasheet is watermarked, and NDAs are required to get them.
Most of the other big players, STMicro, Texas Instruments, Nordic, Microchip, etc, are far more open. Just about all of their parts are well documented, and those documents are freely available.
ST's RMs are a bit of a pain, but the info is there, and reasonably consistent. The SVDs have many errors, and inconsistent between variants, but there are some open source patch systems available. (Like SVD2Rust).
It's nice ST is getting into this space, even though I don't have a use case for this type of device now. As you mention, Nordic's docs are great too.
I noticed for a certain ST part (rangefinder), instead of a documented register API, there was a C library for it. I posted on their forum because I was confused (and not using C). An engineer explained that they did it that way because at the hardware level, the device was very complicated, and they weren't sure the best ways to configure it; they wanted to leave open the option to change it later. So, not obfuscation like you're describing with the *COMs, but a technical decision to use a library.
the great advantage of risc-v is that you don't need to pay arm a license for every chip, but i think that's like 99¢ or something, which is too small to matter at the price point they're likely targeting
risc-v is better in many ways; the virtual memory architecture is much cleaner, you don't need a mode bit to switch between compressed and uncompressed instructions (which avoids all kinds of minor complications), the compressed instruction set is enormously simpler, conditional branches are usually one instruction instead of two because you don't have condition codes, and if you implement it in the same process as a similar-performance arm it uses less area and less power
it's worse in others; you don't have addressing modes with bit shifts, you don't have base+offset two-register addressing, there's no bitfield extraction instructions, you can't run rv32 code on an rv64 chip, and the compilers aren't as good. all of this means lower coremarks or dmips per mhz in an in-order chip and more verbose disassembly, but a lot of it can be fixed with instruction-set extensions, which are enormously easier in risc-v land
(ldm/stm and conditional execution is maybe a wash; they're pretty convenient for assembly, but they complicate things like exception handling, context switching, debuggers, and memory-mapped I/O, and to a great extent you can paper over the lack of them with millicode and/or macro assemblers)
but it's pretty rare that issues like these are the deciding factor in whether a product is successful. i mean we have compilers and dynamic binary translation so generally switching between instruction sets is not that hard
gigadevice's risc-v clones of popular stm32s, the gd32vf line, seem to have failed despite lower power usage. gigadevice's arm clones of the same chips (gd32f) are enormously successful
>the great advantage of risc-v is that you don't need to pay arm a license for every chip, but i think that's like 99¢ or something
99¢ would be a big deal for a microcontroller. I think you might have meant a different amount.
>gigadevice's risc-v clones of popular stm32s, the gd32vf line, seem to have failed despite lower power usage. gigadevice's arm clones of the same chips (gd32f) are enormously successful
As far as I am aware, there is no GD32VF line. There is a few variants of GD32VF103 and that's it. They are still at their first iteration of RISC-V chips, testing the waters.
Instead, I would look at WCH32V, as they have a range of RISC-V based families.
>it's worse in others
RISC-V always led in 64bit code density.
As of the recently ratified bit manipulation and code size extensions, RISC-V does now offer higher density in 32bit too, beating ARM thumb2.
>and the compilers aren't as good
Potentially still the case, yet RISC-V is rapidly building the strongest ecosystem.
for a cortex-m0 microcontroller it would be a big deal, but i think this chip is probably a 15-dollar 'microcontroller', and i'm pretty sure arm charges less for the cortex-m0
i'd say 'a few variants of gdvf103' amounts to a 'gd32vf' line, but they seem to no longer be produced. maybe you're right that they'll dip back in, especially as tensions continue to build over taiwan; i was enthusiastic to see the gd32vf though admittedly i haven't actually done anything with the ones i got
i agree that wch's ch32v line is extremely exciting, especially at the low end, where it reaches a 10¢ price point i've never before seen in 32-bit mcus (probably because arm's licensing fees are too high), and i should have mentioned it
i agree that risc-v has always led in 64-bit code density, and that with some extensions it beats thumb-2, but actually i think it was already kind of tied with thumb-2 on code density
i agree that risc-v compilers will probably eventually be better than arm compilers
but i also think that if your hardware budget includes enough ram and battery to run linux it's unlikely that issues like these will be very significant
this weekend i'm prototyping a jit compiler with the objective of keeping most of my code in a bytecode form that's denser than even thumb-2 or rv32c; i anticipate about 20% better code density and about a 2-4× slowdown, with on the order of 64 clocks per instruction of compilation time. i think this should mostly eliminate the rv64c code density advantage, which i agree is pretty killer. that's not why i'm doing it, of course (i love risc-v)
>but i also think that if your hardware budget includes enough ram and battery to run linux it's unlikely that issues like these will be very significant
Yeah, when you have that much ram, code density advantage matters less (although in L1$ it will still matter), and other factors weight more.
When it's designed for realtime, then high assurance and formal verification enter the game. There, I'd argue that the complexity of the ARM ISA runs counter to the goals, and RISC-V does an order of magnitude better.
>this weekend i'm prototyping a jit compiler with the objective of keeping most of my code in a bytecode form that's denser than even thumb-2 or rv32c; i anticipate about 20% better code density and about a 2-4× slowdown, with on the order of 64 clocks per instruction of compilation time. i think this should mostly eliminate the rv64c code density advantage, which i agree is pretty killer. that's not why i'm doing it, of course (i love risc-v)
Seems you're having a fun weekend. I am instead playing with old hardware, and reading some 80s book on serial comms.
> (..) yet RISC-V is rapidly building the strongest ecosystem.
Architecture & software support is one thing, quality implementations is another.
ARM has decades of evolution & optimization behind it. Implemented in billions of devices. From cheap, small, low power to high-performance cores implemented on latest process nodes.
True, RISC-V is picking up speed. But world domination is a big task. ;-) All the places that ARM already has gone, RISC-V has still to go.
>But market for products like these tend to have long support cycles.
I absolutely understand this, and that's exactly why it's appalling they're introducing a new line of microcontrollers today using an ISA that's already legacy.
As far as I'm aware, only the AM6x will has support for TSN stuff, not the AM3x. Second, you don't have to deal with TI's crappy tooling or TI themselves. I vote against TI parts every chance I get because it's almost universally a mistake everyone comes to regret.
I used beaglebone(also i.mx6 from NXP, thinking about using CM4 for next projects) to make products and they're robust to me, what's the real problem with TI? admittedly I have not used beagle boards to make products in the past few years but the past experience was good, is it because its software are now out of date and unmaintained?
TI processors tend to have weird misbehaviors and the support is far worse than competitors like NXP. Plus, their driver quality is usually low, and actually using driver or bsp code is difficult in a consistent, automatic way. You want to regularly upgrade drivers/bsps that you're carrying a couple dozen unofficial patches on top of. The tooling available forces you to do that semi-manually, which also means people make mistakes and introduce unnecessary regressions.
Even when their stuff works, I've had too many instances where the support resolution was "ensure you're doing everything in this 1,500 item checklist" (not exaggerating).
very helpful, I probably will stick with NXP chips then(its software seems updated fairly often and its chips are usually solid) instead of TI's, after all TI pretty much left the ARM chip space comparing to other larger ARM chip vendors. For NXP's imx6/7/8 I wish there were similar open source communities as RPi and Beagle board have, there are a few commercial i.mx vendors but not a well known open one for NXP, which is unfortunate.
even questions like this got downvoted at HN, maybe it's not encouraging or hurting your heart? This is just a normal practical question from an engineer, if you still sense that it hurts your feelings, I'm speechless.
I actually looked up this forthcoming chip and wondering if I should add it to my to-use list down the road, thus the question.
I’m curious if any hardware dev can chime in on this - would it be possible to use such an chip with an RTOS? I’ve seen rtos’es which run on esp32 style mmu-less chips, and it seems that anything with an a core runs an (non-real-time) OS. But could the A chip in this be used to run an RTOS without a host system, for repeatability and real-time operation?
There are a number of RTOS’s out there now, both proprietary (e.g. VxWorks) and OSS (Zephyr) that support A-series chips with an MMU, and can operate with a single (kernel) context. They still provide bounded latencies compared to full-fat OS’s, but don’t have as much determinism as microcontrollers without page tables and caches. The cores themselves (maybe not the A35?) don’t generally work without the MMU enabled, because most ARM cores also disable the cache if the MMU is off.
Well this thing is less available and will have less ecosystem support. Get a Raspberry Pi Zero W if you want something with a visual component and want to save some cash.
51 comments
[ 3.5 ms ] story [ 102 ms ] threadThis announcement itself is from 2023-06-05, so not exactly hot off the presses either.
Great to see this being more widely/deeply described. It looks very capable, interesting choice with onboard Ethernet switch.
Would be so much fun as a games console, but I guess even at this size programming the GPU bare metal will not be very accessible.
These STM32MP parts are designed for devices with realtime needs and real-world interface requirement, because they combine Application Processors that run Linux (albeit not quite as fast as a cutting-edge phone SoC) with a Cortex-M core made for realtime application use, as well as interface peripherals like CAN. Basically these are supposed to be a bridge between the "embedded" world and the "Linux" world.
I know GPU->opencl->MLC is often feasible but never hear anything a out the NPU
I am similarly curious how the NPU works software-wise
So a year away before the first Pi-a-like or SBCs for hobbyists/hackers hit the market
So, as a hobbyist, I wouldn't be getting my hopes up for 2024...
Meh, if you're a hobbyist you can migrate to any other ARM board you can find on the cheap in your area. No need to pigeonhole yourself in the STM32 ecosystem.
https://electronics.stackexchange.com/questions/512232/stm32...
Without 3+ you miss out on VAO which IMO is the last GL feature.
Companies like Qualcomm, Broadcom, and Marvell are notorious for locking down their documentation. If you're not shipping millions of units, they're not going to give you the time of day. And even if they are willing to work with you, they're not going to provide you with full register maps, or really anything that would allow you to be independent of them. Instead, they'll give you binary blobs that handle low level details. Every datasheet is watermarked, and NDAs are required to get them.
Most of the other big players, STMicro, Texas Instruments, Nordic, Microchip, etc, are far more open. Just about all of their parts are well documented, and those documents are freely available.
It's nice ST is getting into this space, even though I don't have a use case for this type of device now. As you mention, Nordic's docs are great too.
I noticed for a certain ST part (rangefinder), instead of a documented register API, there was a C library for it. I posted on their forum because I was confused (and not using C). An engineer explained that they did it that way because at the hardware level, the device was very complicated, and they weren't sure the best ways to configure it; they wanted to leave open the option to change it later. So, not obfuscation like you're describing with the *COMs, but a technical decision to use a library.
0. https://github.com/cpq/bare-metal-programming-guide
No, they aren't. Otherwise, they would have selected RISC-V ISA, rather than a legacy ISA.
I am sad to see a microcontroller family I favored sabotage itself into irrelevance like this.
the great advantage of risc-v is that you don't need to pay arm a license for every chip, but i think that's like 99¢ or something, which is too small to matter at the price point they're likely targeting
risc-v is better in many ways; the virtual memory architecture is much cleaner, you don't need a mode bit to switch between compressed and uncompressed instructions (which avoids all kinds of minor complications), the compressed instruction set is enormously simpler, conditional branches are usually one instruction instead of two because you don't have condition codes, and if you implement it in the same process as a similar-performance arm it uses less area and less power
it's worse in others; you don't have addressing modes with bit shifts, you don't have base+offset two-register addressing, there's no bitfield extraction instructions, you can't run rv32 code on an rv64 chip, and the compilers aren't as good. all of this means lower coremarks or dmips per mhz in an in-order chip and more verbose disassembly, but a lot of it can be fixed with instruction-set extensions, which are enormously easier in risc-v land
(ldm/stm and conditional execution is maybe a wash; they're pretty convenient for assembly, but they complicate things like exception handling, context switching, debuggers, and memory-mapped I/O, and to a great extent you can paper over the lack of them with millicode and/or macro assemblers)
but it's pretty rare that issues like these are the deciding factor in whether a product is successful. i mean we have compilers and dynamic binary translation so generally switching between instruction sets is not that hard
gigadevice's risc-v clones of popular stm32s, the gd32vf line, seem to have failed despite lower power usage. gigadevice's arm clones of the same chips (gd32f) are enormously successful
99¢ would be a big deal for a microcontroller. I think you might have meant a different amount.
>gigadevice's risc-v clones of popular stm32s, the gd32vf line, seem to have failed despite lower power usage. gigadevice's arm clones of the same chips (gd32f) are enormously successful
As far as I am aware, there is no GD32VF line. There is a few variants of GD32VF103 and that's it. They are still at their first iteration of RISC-V chips, testing the waters.
Instead, I would look at WCH32V, as they have a range of RISC-V based families.
>it's worse in others
RISC-V always led in 64bit code density.
As of the recently ratified bit manipulation and code size extensions, RISC-V does now offer higher density in 32bit too, beating ARM thumb2.
>and the compilers aren't as good
Potentially still the case, yet RISC-V is rapidly building the strongest ecosystem.
i'd say 'a few variants of gdvf103' amounts to a 'gd32vf' line, but they seem to no longer be produced. maybe you're right that they'll dip back in, especially as tensions continue to build over taiwan; i was enthusiastic to see the gd32vf though admittedly i haven't actually done anything with the ones i got
i agree that wch's ch32v line is extremely exciting, especially at the low end, where it reaches a 10¢ price point i've never before seen in 32-bit mcus (probably because arm's licensing fees are too high), and i should have mentioned it
i agree that risc-v has always led in 64-bit code density, and that with some extensions it beats thumb-2, but actually i think it was already kind of tied with thumb-2 on code density
i agree that risc-v compilers will probably eventually be better than arm compilers
but i also think that if your hardware budget includes enough ram and battery to run linux it's unlikely that issues like these will be very significant
this weekend i'm prototyping a jit compiler with the objective of keeping most of my code in a bytecode form that's denser than even thumb-2 or rv32c; i anticipate about 20% better code density and about a 2-4× slowdown, with on the order of 64 clocks per instruction of compilation time. i think this should mostly eliminate the rv64c code density advantage, which i agree is pretty killer. that's not why i'm doing it, of course (i love risc-v)
Yeah, when you have that much ram, code density advantage matters less (although in L1$ it will still matter), and other factors weight more.
When it's designed for realtime, then high assurance and formal verification enter the game. There, I'd argue that the complexity of the ARM ISA runs counter to the goals, and RISC-V does an order of magnitude better.
>this weekend i'm prototyping a jit compiler with the objective of keeping most of my code in a bytecode form that's denser than even thumb-2 or rv32c; i anticipate about 20% better code density and about a 2-4× slowdown, with on the order of 64 clocks per instruction of compilation time. i think this should mostly eliminate the rv64c code density advantage, which i agree is pretty killer. that's not why i'm doing it, of course (i love risc-v)
Seems you're having a fun weekend. I am instead playing with old hardware, and reading some 80s book on serial comms.
lots of realtime systems still don't bother with formal verification, even though it's enormously more accessible today than 20 or 40 years ago
Architecture & software support is one thing, quality implementations is another.
ARM has decades of evolution & optimization behind it. Implemented in billions of devices. From cheap, small, low power to high-performance cores implemented on latest process nodes.
True, RISC-V is picking up speed. But world domination is a big task. ;-) All the places that ARM already has gone, RISC-V has still to go.
As NASA and ESA both selected RISC-V, it'll go quite far, in the literal sense.
But market for products like these tend to have long support cycles.
Even if there's a new kid on the block, there can also be a market for updated version of existing products.
And following from that: entirely possible ST would introduce some RISC-V parts as well.
I absolutely understand this, and that's exactly why it's appalling they're introducing a new line of microcontrollers today using an ISA that's already legacy.
Even when their stuff works, I've had too many instances where the support resolution was "ensure you're doing everything in this 1,500 item checklist" (not exaggerating).
I actually looked up this forthcoming chip and wondering if I should add it to my to-use list down the road, thus the question.
A Raspberry Pi would be overkill, and their availability is still iffy.