10-cent CH32V003 RISC-V MCU offers 2KB SRAM, 16KB flash, SOP8 to QFN20 packages
cnx-software.com
cnx-software.com
At some point (many years ago, well before the pandemic and subsequent chip shortage) STM8s were hit by a massive price hike, which led to them disappearing almost entirely from cheap Chinese electronics. Several companies developed pin-compatible alternatives, usually based on the ancient MCS-51 architecture; the ones from Nuvoton seem to be particularly common, with one of them even being in charge of driving RGB LEDs on my desktop's motherboard.
Here WCH seems to be particularly late to the party, but this RISC-V chip might finally start killing off the 8051 clones for good. It might even cannibalize WCH's own MCS-51 offerings, ironically.
Edit: btw the company might even started as a bootlegger doing counterfeit FTDI serial converters.
I've done some work on a CH375/6 based project, and it's sort of limited-- the fact you can only burst 64 bytes at a time is likely a factor of it being based on such a small MCU, but OTOH, you can always get them at pretty modest prices, while plenty of other parts seem to have gone up or outright unavailable.
When I went to get some USB-serialish adaptors, I went specifically for CH340 ones because I know they're explictly NOT a FTDI clone, so there's no risk of malicious drivers bricking them.
(And no information on it at all, so no idea what you linked there…)
The datasheet says it's programmed with "SWDIO" + "SWCLK" pins. Those names normally refer to ARM's SWD standard. If - and that's a big if - they actually implemented proper SWD, the lower layer protocols would be known and it might be possible to get OpenOCD to work to program the chip.
(Debugging is a much harder question though…)
They get to “$0.10” (not for you it won’t be) by trimming off the peripherals.
(PDF) https://datasheet.lcsc.com/lcsc/2201121900_WCH-Jiangsu-Qin-H...
https://datasheet.lcsc.com/lcsc/2205101630_WCH-Jiangsu-Qin-H...
These kind of controllers are more than sufficient for most simple control tasks. ARM is simply too expensive here, since the licensing itself probably costs more than the MCU itself.
[Ed.: Chinese datasheet says "RV32EC", in case anyone is wondering.]
Usually the biggest issue is lack of [good] documentation, but I suspect this will work itself out over time.
Looks like they have a semi-custom debug protocol, and there's a reverse-engineered OpenOCD here: https://github.com/fxsheep/openocd_wchlink-rv
As well as a copy of the source code for the vendor's version of OpenOCD here: https://github.com/kprasadvnsi/riscv-openocd-wch
Probably about good enough to get started with this device with a FOSS toolchain.
https://lcsc.com/product-detail/Microcontroller-Units-MCUs-M...
Amazing the CPU is priced at $0.10 and clocked 2-3x higher than the Macintosh computers I grew up using.
The available memory on these is a lot less than those old macs, though. They tended to have 4-32MB of RAM and 40-120MB discs.
Anyone know if this thing can run a simple Python app?
e.g. https://wiki.python.org/moin/EmbeddedPython
My guess is there probably isn't sufficient memory. Curious what the development workflow consists of for these boards. The lack of a network or display output port seems a tad limiting.
Install a manufacturer-specific toolchain, often based on some minimally changed Eclipse IDE and gcc, Write your software in as old a C dialect you can, sprinkle some generous helping of assembly in.
To know which registers to use, dig through thousands of pages of documentation, some more, some less helpful. Most functions are just accessible by flipping bits in specific registers.
Afterwards, build the software and flash it with a dongle on it, then run the code.
For debugging, you mostly have SWD or JTAG which allows you to poke and change at all registers and any memory, and stop the code when and wherever you want.
Which is desperately needed, as most MCUs are riddled with weird edge cases and undocumented behavior.
Source: Development on ATmega, STM/SPC
The first thing I saw looking at STM32 land is a whole heap of suggested manufacturer libraries that do who-knows-what behind the scenes. The timing properties feel more like using a general purpose OS rather than always having deterministic control over what the CPU was doing. The peripherals are still documented at the register level, but the scope is much larger and it seems you'd be likely to run into undiscovered errata if you attempted to use them in a different way from the manufacturer libraries.
Maybe I never got familiar enough with STM32 to appreciate and really understand it. That project was several years back and I got interrupted and have yet to return. I especially look forward to seeing what the Rust community has enabled on ARM microcontrollers in the mean time - I feel like there's a lot more hope for sanity on a ground-up implementation, rather than leaning on whatever the manufacturer dumps. And obviously modern languages are sorely needed, rather than C being considered the "high level" option. But if I were going to start a hardware project today that needed to be reliable, I'd likely still base the core around an 8-bit micro (probably AVR to go with the flow), with an ESP32 as an afterthought for wifi connnectivity.
This is an embedded microcontroller, not a general-purpose computer. You program it in C, and poke registers to make things happen.
Edit: forgot link.
IMO microPython is a waste of time.
If you want your pi Pico flashing some lights it seems suitable.
Fair enough if youre shipping 100k units and want to minimise the bom then fine, but that isn't most hobbyists.
On a microcontroller RAM is only used to hold program variables. The program itself is stored in Flash memory.
That needs a huge asterix. You are using a big generalization with a lot of examples to the contrary.
Look up why the Infineon XMC1x00 ARM processors has so much ram. Probably the 4x00 too.
Just needs a jig that connects to a wafer's worth of chips simultaneously with spring loaded contact fingers (not on the EFuses themselves, just power, ground, and any way to load code into the µC - i.e. you have bonding pads for this stuff anyway), and have the code burn through an unique combination of fuses.