4 ms·

That folks are still making new Cortex-A7 (2011) designs is wild. A-35 doesn't seem to be very popular or better. Cortex-M33 (2016) derives–as you allude to–fr

That folks are still making new Cortex-A7 (2011) designs is wild. A-35 doesn't seem to be very popular or better. Cortex-M33 (2016) derives–as you allude to–from ARMv8 (2015). But yeah it barely seems only barely popular, even now. Having witnessed some of the 9p's & aughts computing, I never in a million years would have guessed microcontrollers & power efficient small chips would see so little change across a decade of time!!

bsder 1y ago
> I never in a million years would have guessed microcontrollers & power efficient small chips would see so little change across a decade of time It's because the software ecosystem around them is so incredibly lousy and painful. Once you get something embedded to work, you never want to touch it again if you can avoid it. I was really, really, really hoping that the RISC-V folks were going to do better. Alas, the RISC-V ecosystem seems doomed to be repeating the same levels of idiocy.
- 01100011 1y ago
  Switching microcontrollers means you have a lot of work to do to redo the HW design, re-run all of your pre-production testing, update mfg/QA with new processes and tests, possibly rewrite some of your application.. and you need to price in a new part to your BOM, figure out a secure supply for some number of years... And that just assumes you don't want to do even more work to take advantage of the new chip's capabilities by rewriting even more of your code. All while your original CPU probably still does fine because this is embedded we're talking about and your product already does what it needs to do.
- marsven_422 1y ago
  [dead]
- danhor 1y ago
  RISC-V is even worse: The Cortex-M series have standardized interrupt handling and are built so you can avoid writing any assembly for the startup code. Meanwhile the RISC-V spec only defines very basic interrupt functionality, with most MCU vendors adding different external interrupt controllers or changing their cores to more closely follow the faster Cortex-M style, where the core itself handles stashing/unstashing registers, exit of interrupt handler on ret, vectoring for external interrupts, ... . The low knowledge/priority of embedded of RISC-V can be seen in how long it took to specify an extension tha only includes multiplication, not division. Especially for smaller MCUs the debug situation is unfortunate: In ARM-World you can use any CMSIS-DAP debug probe to debug different MCUs over SWD. RISC-V MCUs either have JTAG or a custom pin-reduced variant (as 4 pins for debugging is quite a lot) which is usually only supported by very few debug probes. RISC-V just standardizes a whole lot less (and not sensibly for small embedded) than ARM.
  - ryao 1y ago
    Being customizable is one of RISC-V’s strengths. Multiplication can be easily done in software by doing bit shifts and addition in a loop. If an embedded application does not make heavy use of multiplication, you can omit multiplication from the silicon for cost savings. That said, ARM’s SWD is certainly nice. It appears to be possible to debug the Hazard3 cores in the RP2350 in the same way as the ARM cores: https://gigazine.net/gsc_news/en/20241004-raspberry-pi-pico-2-risc-v-debug/ https://gigazine.net/gsc_news/en/20241004-raspberry-pi-pico-...
    - magicalhippo 1y ago
      > If an embedded application does not make heavy use of multiplication, you can omit multiplication from the silicon for cost savings. The problem was that the initial extension that included multiplication also included division[1]. A lot of small microcontrollers have multiplication hardware but not division hardware. Thus it would make sense to have a multiplication-only extension. IIRC the argument was that the CPU should just trap the division instructions and emulate them, but in the embedded world you'll want to know your performance envelopes so better to explicitly know if hardware division is available or not. [1]: https://docs.openhwgroup.org/projects/cva6-user-manual/01_cva6_user/RISCV_Instructions_RV32M.html https://docs.openhwgroup.org/projects/cva6-user-manual/01_cv...
      - ryao 1y ago
        Software division is often faster than hardware division, so your performance remark seems to be a moot point: https://libdivide.com/ https://libdivide.com/
        deleted 1y ago
        [deleted]
        magicalhippo 1y ago
        I don't think that library refutes anything of what I said. First of, that library requires you to fundamentally change the code, by moving some precomputation outside loops. Of course I can do a similar trick to move the division outside the loop without that library using simple fixed-point math, something which is a very basic optimization technique. So any performance comparison would have to be against that, not the original code. It is also much, much slower if your denominator changes for each invocation: In terms of processor time, pre-computing the proper magic number and shift is on the order of one to three hardware divides, for non-powers of 2. If you care about a fast hardware divider, then you're much more likely to have such code rather than the trivially-optimized code like the library example.
- ryao 1y ago
  The RP2040 and RP2350 are fairly big changes from the status quo, although they are not very energy efficient compared to other MCUs. Coincidentally, the RP2350 is part of the RISC-V ecosystem. It has both RISC-V and ARM cores and lets you pick which to use.
- fidotron 1y ago
  > It's because the software ecosystem around them is so incredibly lousy and painful. This is reaching breaking point entirely because of how powerful modern MCUs are too. You simply cannot develop and maintain software of scale and complexity to exploit those machines using the mainstream practices of the embedded industry.
duskwuff 1y ago
You can get a lot of mileage out of a Cortex-M7. NXP has some which run up to 1 GHz - that's a ridiculous amount of power for a "microcontroller". It'd easily outperform an early-to-mid-2000s desktop PC.
- adrian_b 1y ago
  There are no similarities between Cortex-M7 and Cortex-A7 from the POV of obsolescence. Cortex-M7 belongs to the biggest-size class of ARM-based microcontrollers. There is one newer replacement for it, Cortex-M85, but for now Cortex-M7 is not completely obsolete, because it is available in various configurations from much more vendors and at lower prices than Cortex-M85. Cortex-M7 and its successor Cortex-M85 have similar die sizes and instructions-per-clock performance with the Cortex-R8x and Cortex-A5xx cores (Cortex-M5x, Cortex-R5x and Cortex-A3x are smaller and slower cores), but while the Cortex-M8x and Cortex-R8x cores have short instruction pipelines, suitable for maximum clock frequencies around 1 GHz, the Cortex-A5xx cores have longer instruction pipelines, suitable for maximum clock frequencies around 2 GHz (allowing greater throughput, but also greater worst-case latency). Unlike Cortex-M7, Cortex-A7 is really completely obsolete. It has been succeeded by Cortex-A53, then by Cortex-A55, then by Cortex-A510, then by Cortex-A520. For now, Cortex-A55 is the most frequently used among this class of cores and both Cortex-A7 and Cortex-A53 are truly completely obsolete. Even Cortex-A55 should have been obsolete by now, but the inertia in embedded computers is great, so it will remain for some time the choice for cheap embedded computers where the price of the complete computer must be well under $50 (above that price Cortex-A7x or Intel Atom cores become preferable).
  - kvemkon 1y ago
    In embedded old Cortex-A53 (and A72) are the most "new" cores used compared to A9 (and A15). E.g. TI AMxxxx [1] and Xilinx UltraScale+ vs Zynq. [1] https://www.ti.com/microcontrollers-mcus-processors/arm-based-processors/overview.html https://www.ti.com/microcontrollers-mcus-processors/arm-base...
    - adrian_b 1y ago
conradev 1y ago
Isn’t there some dynamic at play where STM will put one of these on a board, that board becomes a “standard” and then it’s cloned by other manufacturers, lowering cost? (legality aside) STM32H5 in 2023 (M33): https://newsroom.st.com/media-center/press-item.html/p4519.html https://newsroom.st.com/media-center/press-item.html/p4519.h... GD32F5 in 2024: https://www.gigadevice.com/about/news-and-event/news/gigadevice-launches-gd32f5-series-mcu https://www.gigadevice.com/about/news-and-event/news/gigadev... STM32N6 in 2025 (M55): https://blog.st.com/stm32n6/ https://blog.st.com/stm32n6/ i.e. it takes some time for new chips to hit cost targets, and most applications don’t need the latest chips? I don’t know a lot about the market, though, and interested to learn more
- fidotron 1y ago
  The way you put it makes it sound like STM have a serious security problem with their manufacturing.
  - conradev 1y ago
    It’s a serious problem for their lawyers, primarily: https://olimex.wordpress.com/2015/11/09/chinese-clones-attack-stm32-microcontrollers/ https://olimex.wordpress.com/2015/11/09/chinese-clones-attac... cheap Chinese clones of US IP is a broader problem that affects more than just STM
- jauntywundrkind 1y ago
  Some chips that have come out in the past 3 years with Cortex A7: Microchip SAMA7D65 and SAMA7G54. Allwinner V853 and T113-S3. It's not like a massive stream of A7's. But even pretty big players don't really seem to have any competitive options to try. The A-35 has some adoption. There is an A34 and A32 that I don't see much of, don't know what they'd bring above the A7. All over a decade old now and barely seen. To be fair, just this year ARM announced Cortex-A320 which I don't know much about, but might perhaps be a viable new low power chip.
Neywiny 1y ago
At a trade show I saw a chip coming out with DDR3L. Imagine a 2025 chip with RAM from 15? years ago. They said it's all that they needed. Probably have a perpetual license or something.
- mrheosuper 1y ago
  even some new SOC from Rockchip use DDR2 RAM

bsder 1y ago

> I never in a million years would have guessed microcontrollers & power efficient small chips would see so little change across a decade of time It's because the software ecosystem around them is so incredibly lousy and painful. Once you get something embedded to work, you never want to touch it again if you can avoid it. I was really, really, really hoping that the RISC-V folks were going to do better. Alas, the RISC-V ecosystem seems doomed to be repeating the same levels of idiocy.

01100011 1y ago
Switching microcontrollers means you have a lot of work to do to redo the HW design, re-run all of your pre-production testing, update mfg/QA with new processes and tests, possibly rewrite some of your application.. and you need to price in a new part to your BOM, figure out a secure supply for some number of years... And that just assumes you don't want to do even more work to take advantage of the new chip's capabilities by rewriting even more of your code. All while your original CPU probably still does fine because this is embedded we're talking about and your product already does what it needs to do.
marsven_422 1y ago
[dead]
danhor 1y ago
RISC-V is even worse: The Cortex-M series have standardized interrupt handling and are built so you can avoid writing any assembly for the startup code. Meanwhile the RISC-V spec only defines very basic interrupt functionality, with most MCU vendors adding different external interrupt controllers or changing their cores to more closely follow the faster Cortex-M style, where the core itself handles stashing/unstashing registers, exit of interrupt handler on ret, vectoring for external interrupts, ... . The low knowledge/priority of embedded of RISC-V can be seen in how long it took to specify an extension tha only includes multiplication, not division. Especially for smaller MCUs the debug situation is unfortunate: In ARM-World you can use any CMSIS-DAP debug probe to debug different MCUs over SWD. RISC-V MCUs either have JTAG or a custom pin-reduced variant (as 4 pins for debugging is quite a lot) which is usually only supported by very few debug probes. RISC-V just standardizes a whole lot less (and not sensibly for small embedded) than ARM.
- ryao 1y ago
  Being customizable is one of RISC-V’s strengths. Multiplication can be easily done in software by doing bit shifts and addition in a loop. If an embedded application does not make heavy use of multiplication, you can omit multiplication from the silicon for cost savings. That said, ARM’s SWD is certainly nice. It appears to be possible to debug the Hazard3 cores in the RP2350 in the same way as the ARM cores: https://gigazine.net/gsc_news/en/20241004-raspberry-pi-pico-2-risc-v-debug/ https://gigazine.net/gsc_news/en/20241004-raspberry-pi-pico-...
  - magicalhippo 1y ago
    > If an embedded application does not make heavy use of multiplication, you can omit multiplication from the silicon for cost savings. The problem was that the initial extension that included multiplication also included division[1]. A lot of small microcontrollers have multiplication hardware but not division hardware. Thus it would make sense to have a multiplication-only extension. IIRC the argument was that the CPU should just trap the division instructions and emulate them, but in the embedded world you'll want to know your performance envelopes so better to explicitly know if hardware division is available or not. [1]: https://docs.openhwgroup.org/projects/cva6-user-manual/01_cva6_user/RISCV_Instructions_RV32M.html https://docs.openhwgroup.org/projects/cva6-user-manual/01_cv...
    - ryao 1y ago
      Software division is often faster than hardware division, so your performance remark seems to be a moot point: https://libdivide.com/ https://libdivide.com/
      - deleted 1y ago
        [deleted]
      - magicalhippo 1y ago
        I don't think that library refutes anything of what I said. First of, that library requires you to fundamentally change the code, by moving some precomputation outside loops. Of course I can do a similar trick to move the division outside the loop without that library using simple fixed-point math, something which is a very basic optimization technique. So any performance comparison would have to be against that, not the original code. It is also much, much slower if your denominator changes for each invocation: In terms of processor time, pre-computing the proper magic number and shift is on the order of one to three hardware divides, for non-powers of 2. If you care about a fast hardware divider, then you're much more likely to have such code rather than the trivially-optimized code like the library example.
ryao 1y ago
The RP2040 and RP2350 are fairly big changes from the status quo, although they are not very energy efficient compared to other MCUs. Coincidentally, the RP2350 is part of the RISC-V ecosystem. It has both RISC-V and ARM cores and lets you pick which to use.
fidotron 1y ago
> It's because the software ecosystem around them is so incredibly lousy and painful. This is reaching breaking point entirely because of how powerful modern MCUs are too. You simply cannot develop and maintain software of scale and complexity to exploit those machines using the mainstream practices of the embedded industry.

duskwuff 1y ago

You can get a lot of mileage out of a Cortex-M7. NXP has some which run up to 1 GHz - that's a ridiculous amount of power for a "microcontroller". It'd easily outperform an early-to-mid-2000s desktop PC.

adrian_b 1y ago
There are no similarities between Cortex-M7 and Cortex-A7 from the POV of obsolescence. Cortex-M7 belongs to the biggest-size class of ARM-based microcontrollers. There is one newer replacement for it, Cortex-M85, but for now Cortex-M7 is not completely obsolete, because it is available in various configurations from much more vendors and at lower prices than Cortex-M85. Cortex-M7 and its successor Cortex-M85 have similar die sizes and instructions-per-clock performance with the Cortex-R8x and Cortex-A5xx cores (Cortex-M5x, Cortex-R5x and Cortex-A3x are smaller and slower cores), but while the Cortex-M8x and Cortex-R8x cores have short instruction pipelines, suitable for maximum clock frequencies around 1 GHz, the Cortex-A5xx cores have longer instruction pipelines, suitable for maximum clock frequencies around 2 GHz (allowing greater throughput, but also greater worst-case latency). Unlike Cortex-M7, Cortex-A7 is really completely obsolete. It has been succeeded by Cortex-A53, then by Cortex-A55, then by Cortex-A510, then by Cortex-A520. For now, Cortex-A55 is the most frequently used among this class of cores and both Cortex-A7 and Cortex-A53 are truly completely obsolete. Even Cortex-A55 should have been obsolete by now, but the inertia in embedded computers is great, so it will remain for some time the choice for cheap embedded computers where the price of the complete computer must be well under $50 (above that price Cortex-A7x or Intel Atom cores become preferable).
- kvemkon 1y ago
  In embedded old Cortex-A53 (and A72) are the most "new" cores used compared to A9 (and A15). E.g. TI AMxxxx [1] and Xilinx UltraScale+ vs Zynq. [1] https://www.ti.com/microcontrollers-mcus-processors/arm-based-processors/overview.html https://www.ti.com/microcontrollers-mcus-processors/arm-base...
  - adrian_b 1y ago

conradev 1y ago

Isn’t there some dynamic at play where STM will put one of these on a board, that board becomes a “standard” and then it’s cloned by other manufacturers, lowering cost? (legality aside) STM32H5 in 2023 (M33): https://newsroom.st.com/media-center/press-item.html/p4519.html https://newsroom.st.com/media-center/press-item.html/p4519.h... GD32F5 in 2024: https://www.gigadevice.com/about/news-and-event/news/gigadevice-launches-gd32f5-series-mcu https://www.gigadevice.com/about/news-and-event/news/gigadev... STM32N6 in 2025 (M55): https://blog.st.com/stm32n6/ https://blog.st.com/stm32n6/ i.e. it takes some time for new chips to hit cost targets, and most applications don’t need the latest chips? I don’t know a lot about the market, though, and interested to learn more

fidotron 1y ago
The way you put it makes it sound like STM have a serious security problem with their manufacturing.
- conradev 1y ago
  It’s a serious problem for their lawyers, primarily: https://olimex.wordpress.com/2015/11/09/chinese-clones-attack-stm32-microcontrollers/ https://olimex.wordpress.com/2015/11/09/chinese-clones-attac... cheap Chinese clones of US IP is a broader problem that affects more than just STM
jauntywundrkind 1y ago
Some chips that have come out in the past 3 years with Cortex A7: Microchip SAMA7D65 and SAMA7G54. Allwinner V853 and T113-S3. It's not like a massive stream of A7's. But even pretty big players don't really seem to have any competitive options to try. The A-35 has some adoption. There is an A34 and A32 that I don't see much of, don't know what they'd bring above the A7. All over a decade old now and barely seen. To be fair, just this year ARM announced Cortex-A320 which I don't know much about, but might perhaps be a viable new low power chip.

Neywiny 1y ago

At a trade show I saw a chip coming out with DDR3L. Imagine a 2025 chip with RAM from 15? years ago. They said it's all that they needed. Probably have a perpetual license or something.

mrheosuper 1y ago
even some new SOC from Rockchip use DDR2 RAM