There’s a bit of a contest going on when it comes to which is the cheapest microcontroller, yet most of the really cheap ones have one big trade-off in that they have one-time programmable (OTP) memory, generally requiring the use of an (expensive) device emulator during development. This raises the question of what the cheapest reprogrammable MCU is, which [Jay Carlson] postulates is found in the Puya PY32 ARM Cortex-M0+ based series.
Although [Jay] has previously mentioned that these cheap OTP (like the 3-cent Padauk PMS150) MCUs make sense for large volume production) it’s also easy to see that for small volumes and for hobbyists it’s much easier and cheaper to just reflash the firmware in the same cheap MCU rather than using an expensive in-circuit emulator. This is where the Puya PY32 comes into play, with parts ranging from 8 cents a pop (basic PY32F002A) to $0.74 for the more full-featured models on LCSC, and packages ranging from a miniscule DFN, to LQFP and hand soldering friendly SOIC.
In his blog post, [Jay] covers the major advantage of these Puya parts in that they come with Keil support, English documentation and can use the standard ARM MCU toolchains. The parts themselves share similarities with STM32 parts, although they’re not directly (pin or binary) compatible. The PY32F002A is the lowest end part, with 24 MHz clockspeed, 20 kB of Flash and 3 kB of SRAM. The F003 adds DMA and more RAM and Flash, and the top-end F030 hits 48 MHz, 30 GPIO pins and a smorgasbord of peripherals.
Although it’s been claimed that the WCH CH32V003 is the cheapest non-OTP MCU, this is a part that’s much harder to obtain, with WCH apparently having pulled the part, at least on their AliExpress store, leaving it on TaoBao available for about 25 cents a piece. This would seem to give the Puya parts a definite leg up, and it gives the STM32F030 a definite run for its money in this budget part of the MCU pool.
(Heading image: PY32F002A diagram)
22 thoughts on “Puya PY32: The Cheapest Flash Microcontroller You Can Buy Is Actually An ARM Cortex-M0+”
I disagree with the claim this directly complicates the RISC-V narrative though, as RISC-V doesn’t compete directly against all the different architecture families that ARM offers. M0+ in particular is hyper optimized for low end applications and was designed to take on the 8051 head to head especially in transistor count and implementation size for older processes, and is really quite different from even other ARM Cortex M devices. RV32EC on the other hand is relatively new and unsupported, and isn’t as optimized of an attempt to bring RV32I to more minimal devices with very few breaking changes or optimizations other than reducing the register file by half.
RISC-V is really trying to compete more with fuller featured ARMs.
It took me a while to remember that the WCH CH32V003 is a RISC-V part. It was mentioned in EEVBlog #1524 just over two weeks ago. Maybe Aliexpress stock is simply sold out for the moment because of that blog.
Yeah, M0 (and M0+) are not only thumb only with a restricted feature set, but they’re also an older arm version compared to other Cortex-M designs, and they have a different ABI.
M3 or higher is where you start getting proper compatibility with the higher level arm ABIs and code. For most micros you’d never notice the difference other than the higher models having higher speeds, but if you do anything low level then you can end up with quite a few ifdefs if you try to support both
An example that comes to mind is the use of R7, which on M0s is the frame pointer despite that being r11 on newer ABIs, because the armv6 thumb can’t access high side registers in the same way as armv7 (thumb or not). Which means if you’re doing syscalls using SVC you can’t just use the standard examples and conventions based on the v7 ABI, but have to shift things to use R6 instead of R7.
“The Arm Cortex-M55 processor is Arm’s most AI-capable Cortex-M processor” ?
I can still buy 50 x Ch32v003 on Aliexpress for ~13$ shipped from the WCH store…
WCH had the good idea to make their own custom flasher, like their custom SWD.
This is very cheap for a Cortex-MO+. Can someone at ARM, Inc verify that Puya has a real ARM license and this is not something from the ARM China dispute? If it is from the ARM China dispute there is considerable license risk using these parts.
Sounds a bit sensationalist to me. For the hobbyist, the only real concern is that customs decide you must forfeit the shipment, surely? And if you are a volume manufacturer then your legal department does the due diligence, including talking to ARM if deemed necessary.
For the hobbyist – who cares if it’s a 70c part or a 3.00 part – unless you’re generating a DIY swarm of sensors 1000 deep, the cost difference is negligible – I and most people routinely buy a sledge hammer to crack a nut – even buying 100 of them, my time is worth more than worrying about the cost. I’m sure I’m missing the point entirely, but that’s my perspective currently.
Especially if you need a special programmer or debug adapter for the less common cheaper part.
Clone WCH Link debug adapters are $1.20 on Aliexpress. The problem is that they are proprietary and specific to the WCH chips so you can’t use the debug adapters you already own.
Exactly right. Unless you are after “bragging rights” about using the cheapest ARM on the planet, which is hardly anything I am about.
The parts famine is really getting bad, over here a large company had to postpone an order because a £2 component wasn’t available.
“Getting” is a strange perspective, for the last 2 years I know of companies revamping their product lines to use more available hardware, and that’s companies who already entirely expect a 6 month lead time on components normally.
It’s funny, since it’s been so long it’s actually made most of my designs a lot more robust inventory-wise. Found a lot of parts which were either footprint compatible or could be made compatible. Analog has a whole series of hot-swap controllers which can be made drop-in (except software) with configuration resistors, there are a bunch of USB load switches which are pin compatible if you limit functionality, etc. And then obviously for FPGAs and some uCs you can also target certain packages/devices which have the most pin-compatible parts available just to up your chances.
For the hobbyist the price is almost irrelevant. They’ll only be buying one or two IC’s or dev boards anyway.
Even if I were to create a commercial product, I’d rather focus on an established microcontroller part from an established microcontroller manufacturer preferably from a Western nation given how volatile politics is these days.
Also these parts seem to be very ‘similar’ to the stm32f0 parts….in fact, they seem to be almost cloned versions of the STM32F030. I’m not a big fan of using clones or ‘quasi clones’ in a commercial product.
They don’t seem to be clones any more than they both use ARM cores, in this article they even say they aren’t pin or binary compatible. Devices that use ARM cores aren’t automatically clones of STM products, loads of companies use ARM cores.
llvm working or not?
and next question will be: GDB support?
The 002 part it’s actually almost a 003, has 4KB RAM, PLL, DMA… Probably untested like the extra flash on the stm32.
The SOP-8 parts are back in stock at LCSC. I’ve ordered 10 out of curiosity. I’ll design a simple prototyping board for them.
I found a really useful Makefile/SDK setup here: https://github.com/IOsetting/py32f0-template
I bought a few dozen of a bunch of different models from lcsc, and have been playing around. So far, they seem really great, although by the time I factor in shipping at smaller volumes, it’s really more like $.50/ea by the time I get them in my hands.
For comparison, the similar M0+ STM32G030F6 (also from LCSC) is about $1.00 in hand when it’s all said and done – not all *that* much cost difference, and the level of support – tooling, documentation, etc is a whole other level…. I can’t really see myself using the Puya’s for much more than tinkering.
Please be kind and respectful to help make the comments section excellent. (Comment Policy)