4 ms·
10-cent CH32V003 RISC-V MCU offers 2KB SRAM, 16KB flash, SOP8 to QFN20 packages
- huy0 4y agoit'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)
- dang 4y agoCouple points: (1) of course YC cares about hardware startups; (2) there's no connection between that and HN's front page either way.
- metadat 4y agoWill LCSC sell me a single $6.76 board? https://lcsc.com/product-detail/Microcontroller-Units-MCUs-MPUs-SOCs_WCH-Jiangsu-Qin-Heng-CH32V003F4P6-EVT-R0_C5187532.html 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 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.
- exar0815 4y agoNot 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. Source: Development on ATmega, STM/SPC
- tormeh 4y agoCan 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.
- mindslight 4y agoMaybe 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.
- unwind 4y agoNo, it cannot run Python. Even MicroPython [1] requires 16 KB of RAM, and probably at least 8 times more flash (code space) than this chip has. 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. [1]: https://micropython.org/ https://micropython.org/
- SV_BubbleTime 4y agoLast I looked, it was a 256KB rom requirement, and worth noting that the 16KB ram is just the interpreter. Your code adds on top of that. IMO microPython is a waste of time.
- benj111 4y agoWhy is it 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.
- pencilguin 4y agoYou could better program it in C++. Or even Rust.
- deleted 4y ago[deleted]
- UltraViolence 4y agoRAM is incomparable to desktop computers since it's used for both programs and data (i.e. variables used in the program) in the latter. On a microcontroller RAM is only used to hold program variables. The program itself is stored in Flash memory.
- SV_BubbleTime 4y ago> 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.
- goodpoint 4y agoIt cannot run MicroPython but you can use Nim.
- rasz 4y agoWCH sells a ton of general purpose microcontrollers and microcontrollers disguised as single purpose peripheral chips. For example all USB to UART chips are 8051 inside. Same for "USB Controllers" like CH375 http://www.wch-ic.com/products/categories/63.html?pid=1 http://www.wch-ic.com/products/categories/63.html?pid=1 used in https://www.lo-tech.co.uk/wiki/Lo-tech_ISA_USB_Adapter https://www.lo-tech.co.uk/wiki/Lo-tech_ISA_USB_Adapter Afaik all WCH chips to ~2020 were 8051 cores. They started experimenting with ARM and RISC-V two years ago https://special.wch.cn/en/mcu/ https://special.wch.cn/en/mcu/ Edit: btw the company might even started as a bootlegger doing counterfeit FTDI serial converters.
- hakfoo 4y agoI 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.
- downvotetruth 4y ago32-bit RISC core with 64KB RAM (ECC would be nice) would seem more interesting? https://www.aliexpress.us/item/3256804164096177.html https://www.aliexpress.us/item/3256804164096177.html
- metadat 4y agoWhy is that? What can you do there compared to this lil' guy?
- downvotetruth 4y agohttps://en.wikipedia.org/wiki/64K_intro 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.
- metadat 4y agoGot it. Does this also imply the requirement of a display output?
- downvotetruth 4y agoDisplay likely be remotable, but higher frequency & the vector extensions would be helpful.
- eqvinox 4y ago"Sorry, this item's currently unavailable in your location." (And no information on it at all, so no idea what you linked there…)
- downvotetruth 4y agoIt'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.
- spicyjpeg 4y agoThe 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.
- userbinator 4y ago8051 won't go away --- just like those small ARMs like the M0 (which this seems to be more oriented at replacing) haven't displaced them either.
- UltraViolence 4y agoThis 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.
- eqvinox 4y agoIt's a RISC-V core… so it's supported by GCC, unless they f*cked up something quite badly (which I doubt.) [Ed.: Chinese datasheet says "RV32EC", in case anyone is wondering.]
- FullyFunctional 4y agoThe 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.
- flaviut 4y agoGCC works fine. Following along the thread here, https://mobile.twitter.com/kprasadvnsi/status/1496012713423691786 https://mobile.twitter.com/kprasadvnsi/status/14960127134236... Looks like they have a semi-custom debug protocol, and there's a reverse-engineered OpenOCD here: https://github.com/fxsheep/openocd_wchlink-rv 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 https://github.com/kprasadvnsi/riscv-openocd-wch Probably about good enough to get started with this device with a FOSS toolchain.
- taffronaut 4y agoI wonder how they do the unique 64 bit ID in a 10c part.
- eqvinox 4y agohttps://en.wikipedia.org/wiki/EFuse https://en.wikipedia.org/wiki/EFuse 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.
- londons_explore 4y agoI believe it is normally done at the same time as the wafer scale test, so there is no additional time or cost.