The TSSOP package and 003 in the part number suggest that these chips are meant to be a drop-in replacement for the STM8S003 "value line" microcontrollers that used to be popular in China due to their $0.20 price point.
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.
I wonder if that concept gives them more supply-chain flexibility. If they just have a bunch of 8051 devices sitting around, they can program them to taste at the last minute.
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.
It's the least expensive CH32V307VCT6 development board I could find on aliexpress (no relation). Unfortunately, it looks like the WCH chip IP itself & its dev env (mounriver - eclipse based) used for debugging is closed with proprietary usb adapter & windows only.
Ah, Thanks, I actually looked at the chip earlier.
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.
https://en.wikipedia.org/wiki/64K_intro & C64 code. Would assume compilers are able to "double" pack/vectorize 2 16 bit addresses into a 32 bit register, which would be the inverse of the 8 bit era of using 2 registers for 1 16 bit address.
The data sheets says (page 2) the one linked by the parent has both, which makes that one super interesting. Of course I'd expect very different pricing, but still...
This sounds great! But as long as there's no GCC support it's usefulness is limited.
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.
The whole point of RISC-V is that there _is_ GCC support, since a decade, already. Even assuming they have proprietary extensions, it's pretty unlikely you need them in application code. At worst it's just in setup code. However I didn't see any of the usual "bragging" about extensions, so I doubt it.
Usually the biggest issue is lack of [good] documentation, but I suspect this will work itself out over time.
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.
Not knowing for this particular device, but generally for MCUs?
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.
Can confirm. Embedded development (this sort of development) kinda sucks, IMO. It has a certain sort of simple old-school charm, but it's mostly pain, although opinions probably differ.
Maybe I've just got rosy memories, but small microcontroller development felt a lot nicer than large microcontroller development. For PIC development, you could (and would) be in touch with the entire code base, precisely allocate how your interrupt(s) were used, know exactly how the hardware was configured at the bit register level, etc. Whether to use a multitasking system was a choice depending on the project, as was using a C compiler. If you did use a C compiler, you generally knew how your code was going to translate to assembler. Especially when you were writing routines where the cycle count mattered (interrupt routines, bit banging, processing throughput, etc)
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.
it's funny to read such news on YCombinator website, since YC don't give a f*ck about "hardware startups" and constantly looking "for the next facebook" (or at least wework)
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.
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.