New low-end CH32V microcontrollers from WCH

[HwAoRrDk]

Seems there are new CH32V microcontroller models from WCH. English datasheets for them have recently been published. No English reference manuals yet, though. Although I hear they are producing a single combined reference manual for all CH32V00x MCUs.

CH32V002
CH32V004
CH32V006

No idea about availability. I looked at WCH's official AliExpress store, but something must be wrong or being changed, as at time of writing there are no MCU products listed there at all.

The '002 and '004 are pin-compatible with the existing '003, but differ in the following ways:

	CH32V003	CH32V002	CH32V004
CPU core:	QingKe V2A	QingKe V2C	QingKe V2C
Instruction set:	RV32EC	RV32EmC	RV32EmC
SRAM:	2 kB	4 kB	6 kB
Flash:	16 kB	16 kB	32 kB
Bootloader:	1920 B	3328 B	3328 B
User NV storage:	64 B	256 B	256 B
VDD range:	3.3-5V	2-5V	2-5V
ADC:	10-bit	12-bit	12-bit
Other peripherals:	Op-amp & comparator	8-ch touch controller	-

From what I understand, the 'm' in the V2C CPU core's oddly-named "RV32EmC" instruction set stands for 'multiplication', but is not full 'M' extension support. That is, it is supposedly Zmmul - multiplication without division support. I am wondering what compiler support is currently like for that - hopefully it is just a case of passing -march=rv32ec_zicsr_zmmul to GCC. I'm assuming, otherwise, existing code for '003 will just run as-is without re-compilation (presuming it's not trying to use missing or changed peripherals, that is).

The increased power supply voltage range is handy, as it'll be possible to run the new chips straight from a lithium-ion battery.

The '004 seems to essentially be a '003 but with more RAM and flash.

For the new ADC, it also says that it now has 3 internal channels versus the previous two (Vref and Vcal). I am intrigued about what the extra third channel is - perhaps Vdd, or maybe even a temperature sensor? The latter would be very useful. I could probably try and find out from the Chinese language reference manual (which I believe is currently available), but I can't be bothered to go to that effort right now. Edit: It says right in the datasheet: "the OPA internal output channel is connected to the IN9 input channel". Vref is IN8 and Vcal IN10. Yeah, very useful for a chip without op-amp...

Haven't investigated the '006 in any detail yet; it has 62 kB flash and 8 kB RAM, same 12-bit ADC, no touch controller, but retains the op-amp/comparator of the '003.

[PCB.Wiz]

Interesting family.
The 006 includes a 005 32k/6k variant, that comes down to QFN12 (2x2p0.4mm)
The 006 shows QFN32 but no TQFP32 ?

The 004 comes in only TSSOP20/QFN20 so is upgrade to 003.
The 002 (16k/4k) also comes in QFN12 and SO16N and SO8

Often dropped in the low end parts is a crystal oscillator, but I see these all have Xtal support, and even the QFN12 and SO8 pin out the crystal.
That opens up many logic replacement simple timing chain uses.

They appear to not have any 32.768kHz crystal support  ? 
Maybe they decide it is not a super low power usage part ?

 

[brucehoult]

RISC-V GCC has supported -march=rv32im -mno-div since at least 2018. But, yes, now there's an official extension for it.

It has always been legal to claim to support the M extension by, say, implementing mul in hardware but trap end emulate div/rem, but of course performance is better if the compiler calls the software div/rem routine explicitly.

[SiliconWizard]

As far as very cheap MCUs for small tasks, these are interesting. The new parts of the series have a bit more RAM and, most of all, an extended voltage range. I don't know if they have lower power consumption too.

As to hardware division, frankly for such small MCUs, that's rarely something that will be missing.

[brucehoult]

Arm C-M0+ also has multiply but not divide -- though Arm gives chipmakers an option of a 1-cycle (limiting clock speed) or 32-cycle (only 2x faster than an A32[1] software routine) multiplier.

[1] yes I'm aware Cortex-M doesn't implement A32

[tszaboo]

Interesting family.
The 006 includes a 005 32k/6k variant, that comes down to QFN12 (2x2p0.4mm)
The 006 shows QFN32 but no TQFP32 ?

The 004 comes in only TSSOP20/QFN20 so is upgrade to 003.
The 002 (16k/4k) also comes in QFN12 and SO16N and SO8

Often dropped in the low end parts is a crystal oscillator, but I see these all have Xtal support, and even the QFN12 and SO8 pin out the crystal.
That opens up many logic replacement simple timing chain uses.

They appear to not have any 32.768kHz crystal support  ? 
Maybe they decide it is not a super low power usage part ?

I typically would like to see high precision RC built in these smaller MCUs.
What's even your use case for the crystal?

Also I can finally see these parts at JLC.  The 003. Maybe then I can use them for a personal project.

[HwAoRrDk]

RISC-V GCC has supported -march=rv32im -mno-div since at least 2018. But, yes, now there's an official extension for it.

I presume the effect would be the same as specifying Zmmul?

[PCB.Wiz]

Also I can finally see these parts at JLC.  The 003. Maybe then I can use them for a personal project.

The 003 is looking like a 'test the waters' part, with these newer, wider supply parts more mainstream.
eg the older 003 lacks the 40kHz OSC option, and the 128kHz WDOG osc has an improved Icc spec.

I also see the Xtal Osc has more gain on the new parts, maybe they had issues ?
Crystals keep getting smaller, but that usually also means higher ESR.

I typically would like to see high precision RC built in these smaller MCUs.

Vendors have differing ideas of what 'high precision' means.
The new WCH part is not too bad, it has a 40kHz, 8.5uA OSC, with claimed  TA = -40℃~85℃ -3%~+2.5 %  (after calibration)
The older 003 has only the 128kHz, low current, but no stability specs at all.

Silabs are rather better, their LFRCO is 32.768 nominal, +/- 3%  (VT unclear)  and draws just 175nA

What's even your use case for the crystal?

These little MCUs are cheap enough to compete with logic, parts like HC4060, or 74HC5555 (now EOL) or even tiny logic parts like 74AHC1G42xx, but they need similar oscillator choices to replace the logic.

If you needed 'better than RC precision', that meant you were bumped to a bigger package around TSSOP20/QFN20
A xtal amplifier is also useful if you need a TCXO with clipped sine output.
Those are often cheaper and more widely available than CMOS TXCO.



 

[brucehoult]

RISC-V GCC has supported -march=rv32im -mno-div since at least 2018. But, yes, now there's an official extension for it.

I presume the effect would be the same as specifying Zmmul?

https://godbolt.org/z/oGTbs4Gsj

[SiliconWizard]

Yes, that's exactly the same. -mno-div existed way before Zmmul was defined, but soon enough the need to support a hardware mulitplier but no hardware division emerged. The original M extension included both multiplication and division. As I remember, strictly speaking, if you didn't implement division, you weren't compliant with the M extension, at the time. At least that's what I remember from the initial specs.

[brucehoult]

As I remember, strictly speaking, if you didn't implement division, you weren't compliant with the M extension, at the time. At least that's what I remember from the initial specs.

You must implement all instructions you claim to support in the ISA string, but for this purpose M-mode firmware is considered to be part of the hardware platform. Trap-and-emulate is legal for whatever instructions you don't want to implement in hardware.

Of course if you overdo that then performance is going to suffer, but that's between you (the core designer) and your customers, not between you and RISC-V International.

For example lots of cores -- probably the majority -- don't implement unaligned load/store in hardware, but this is required to be supported in all RISC-V implementations in User mode and System mode.

Accordingly, the standard OpenSBI implements trap-and-emulate for unaligned load/store. This code can be present on all machines, if that's convenient, because if a machine implements unaligned load/store in hardware then the emulation routines will never be hit. Or, you as a hardware designer could decide to implement unaligned load/store within a 64 byte cache block, but not spanning cache blocks. Or you could support spanning cache blocks, but not spanning VM pages. Or whatever you want. Whatever traps (if anything) will get emulated.

[tszaboo]

Also I can finally see these parts at JLC.  The 003. Maybe then I can use them for a personal project.

The 003 is looking like a 'test the waters' part, with these newer, wider supply parts more mainstream.
eg the older 003 lacks the 40kHz OSC option, and the 128kHz WDOG osc has an improved Icc spec.

I also see the Xtal Osc has more gain on the new parts, maybe they had issues ?
Crystals keep getting smaller, but that usually also means higher ESR.

I typically would like to see high precision RC built in these smaller MCUs.

Vendors have differing ideas of what 'high precision' means.
The new WCH part is not too bad, it has a 40kHz, 8.5uA OSC, with claimed  TA = -40℃~85℃ -3%~+2.5 %  (after calibration)
The older 003 has only the 128kHz, low current, but no stability specs at all.

Silabs are rather better, their LFRCO is 32.768 nominal, +/- 3%  (VT unclear)  and draws just 175nA

What's even your use case for the crystal?

These little MCUs are cheap enough to compete with logic, parts like HC4060, or 74HC5555 (now EOL) or even tiny logic parts like 74AHC1G42xx, but they need similar oscillator choices to replace the logic.

If you needed 'better than RC precision', that meant you were bumped to a bigger package around TSSOP20/QFN20
A xtal amplifier is also useful if you need a TCXO with clipped sine output.
Those are often cheaper and more widely available than CMOS TXCO.

They have built in high speed RC. For logic gate replacement, you can use a pin change interrupt and sleep while waiting for anything to happen. You can typically divide down the built in RC to any value you really want. Also, the crystals are expensive, compared to the price of these chips. And if you want a small design, then even a 2016 crystal with the bypassing capacitor will take up more board space then the chip itself.
I see two reason to use a crystal oscillator in a simple project ( there are a lot more). You need timekeeping of course. The other is in case a communication interface needs it to be accurate enough. There are some ST chips that will do USB connection without crystals now.

[Atlan]

I'm solving a minor problem. I moved the program from atmega328 to ch32v003. The problem is that in atmega it has 12kB and in ch32 over 15kB but I'm missing one more display font. Or will ch32v004 or 006 be on sale at all? Because all that's left is code optimization, and I'm afraid that 4 and 6 are in the tssop20 package and I have designed the ch32v003 for sop16.

[brucehoult]

I'm solving a minor problem. I moved the program from atmega328 to ch32v003. The problem is that in atmega it has 12kB and in ch32 over 15kB but I'm missing one more display font. Or will ch32v004 or 006 be on sale at all? Because all that's left is code optimization, and I'm afraid that 4 and 6 are in the tssop20 package and I have designed the ch32v003 for sop16.

I would not expect RV32EC code to be bigger than AVR unless you're dealing exclusively with 8 bit variables and no pointers.

Can you share some of the C and generated RISC-V code? What build options are you using?

[Atlan]

Do you think I should convert "variables" from 8bit to 32bit? I could also convert the character array from 8bit to 32bit, assuming that the 8bit font is stored in 32bit flash.

So far I've only compiled it, the question is whether it will work.

[jnk0le]

Are you using their SPL HAL for peripherals?

Do you think I should convert "variables" from 8bit to 32bit? I could also convert the character array from 8bit to 32bit, assuming that the 8bit font is stored in 32bit flash.

So far I've only compiled it, the question is whether it will work.

You can try to use their proprietary gcc build with "Xw" extension (which provides compressed byte/half load/stores, not compatible with Zcb).
Or whatever that has implemented it.

[brucehoult]

Do you think I should convert "variables" from 8bit to 32bit?

That shouldn't be necessary if you're using a compiler supporting their Xw extension (similar to but earlier than the standard Zcb extension) AND have enabled it, to get 2-byte opcodes for byte loads and stores:

https://gist.github.com/ArcaneNibble/461edd3bc88a5284098d48941172bfa4

But I was talking more about how AVR code needs two or four instructions to deal with 16 or 32 bit variables, while RISC-V needs a single instruction.

I could also convert the character array from 8bit to 32bit, assuming that the 8bit font is stored in 32bit flash.

I wouldn't do that. It might be ok for individual variables, especially ones that you load or store from RAM frequently, but is only likely to chew up the limited flash space more quickly for arrays.

[Atlan]

I have no choice. I hope I can find the original file with the characters. Because I really don't want to manually edit the 140x11 array to 32bit. That should save me 3x as much memory.

[brucehoult]

I have no choice. I hope I can find the original file with the characters. Because I really don't want to manually edit the 140x11 array to 32bit. That should save me 3x as much memory.

I don't understand this statement at all. Can you explain? Why do you have no choice? How does making an 140x11 array take 4x more memory save anything?

[Atlan]

Because there are 8 bit values ​​in the field. I assume they are written in Flash in 32bit. When I rewrite those fonts from 8bit to 32bit. They will take up one place in flash but will contain 4x8bit information.

It doesn't work.

[brucehoult]

Because there are 8 bit values ​​in the field. I assume they are written in Flash in 32bit.

No. Why would they be?

[Atlan]

How simple? It's easy to write an 8bit value to 32bit flash. They just have it solved somehow. Which brings me back to the original. The idea of ​​the inaccessibility of the uP with more memory.

[SiliconWizard]

I'm not sure what you were on about with this Flash thing. This isn't something you need to care about whatsoever on these chips (in terms of how it's organized). You may have fuzzy memories of the odd (and old) PIC architectures where Flash had a 14-bit data bus (IIRC) and so storing data by bytes would waste a significant amount. There's no such thing in RISC-V and ARM MCUs.

There's nothing much you can do except try and optimize your code so it takes a bit less.

Regarding WCH, they have the CH32V002/004/005/006/007 and 008 on their chinese website, with more Flash and RAM, but these don't seem to be available anywhere, at least outside of China.
So you may have to consider what's currently available. Like the CH32X033/035 series, or even the CH32L103. They will be more expensive, but still cheap.
For instance, the CH32V003 is about $0.14 per 500, the CH32X033 is $0.21 per 500. The CH32X033 has 20KB SRAM，62KB Flash. Check that it has the peripherals you need.

[corgon]

Actually, WCH sells them on AliExpress. 50pcs of CH32V002 for €10.13
https://vi.aliexpress.com/item/1005008493381343.html?gatewayAdapt=glo2vnm

[jnk0le]

Because there are 8 bit values ​​in the field. I assume they are written in Flash in 32bit. When I rewrite those fonts from 8bit to 32bit. They will take up one place in flash but will contain 4x8bit information.

It doesn't work.

How simple? It's easy to write an 8bit value to 32bit flash. They just have it solved somehow. Which brings me back to the original. The idea of ​​the inaccessibility of the uP with more memory.

If you have uint8_t array, then it will be packed inside 32bit words. no need to do it manually.

This kind of thing is usually done for speed. (i.e. to process/transmit 4 bytes in parallel)

[HwAoRrDk]

Actually, WCH sells them on AliExpress. 50pcs of CH32V002 for €10.13
https://vi.aliexpress.com/item/1005008493381343.html?gatewayAdapt=glo2vnm

Huh. I'm surprised, that's the first time I've seen any for sale anywhere. And I've been looking every few months since my original post. Curiously they don't appear on an AliExpress search for "ch32v002" - at least, not on the first couple of pages that I could be bothered to look through. No '004 or '006 either on the WCH store.

I find the WCH official store to be very odd - frequently they'll, for some reason, have zero product listings, i.e. the store is empty. I don't know what the deal is with that.

[corgon]

The search engine on AE is notoriously bad. I often use Goo..le instead, adding "Aliexpress" to my search.

[brucehoult]

Curiously they don't appear on an AliExpress search for "ch32v002" - at least, not on the first couple of pages that I could be bothered to look through. No '004 or '006 either on the WCH store.

You're right that the '004 and '006 don't seem to be available, but the '002 is listed in the store, not just the direct link.

2nd item in "sort by newest"

Perhaps it won't be long for the others.

[HwAoRrDk]

I didn't notice this earlier, but the one review on the listing says that the customer received unmarked chips.

Parts are not T&R, but in small jewel cases. They are also completely unmarked. The only indications on their tops is the mold mark by pin 1--so at least it's got that. I'm going to have to mark them all manually.

I don't quite understand what the seller reply is trying to say:

Hello friends, we are new to this chip, you buy the chip has not been engraved on the silkscreen. At that time, we have told you, if you mind, you can cancel the order. Now our chips are available to have a stamp!

Are they implying you would need to specifically ask them for marked chips, otherwise you'll be getting unmarked?

[PCB.Wiz]

You're right that the '004 and '006 don't seem to be available, but the '002 is listed in the store, not just the direct link.
2nd item in "sort by newest"

Does the 002 really come in an exposed pad SO8 as shown in the image?

[Atlan]

I'm writing to the store, I'm curious what price they'll offer me for the ch32v004 ssop20

There's no clear plan for mass production now, we need to wait a bit. Thank you for your understanding and your support of WCH, I will still let you know when 004 hits the shelves at a later date.

[SiliconWizard]

You're right that the '004 and '006 don't seem to be available, but the '002 is listed in the store, not just the direct link.
2nd item in "sort by newest"

Does the 002 really come in an exposed pad SO8 as shown in the image?

Doubt it. According to the one review there is on the AE page,

Color:50pcs CH32V002F4P6
Parts are not t&r, but in small jewel cases. They are also completely unmarked. The only indications on their tops is the mold mark by pin 1--so at least it's got that. I'm going to have to mark them all manually.

So the pictures do not reflect reality.

[Sacodepatatas]

There's rumours of cnlohr playing with CH32V006 engineering samples...

[_JakeG_]

 


I've seen the CH32V002 and CH32V006 for sale on AE, but they aren't on LCSC yet. Tossed together the symbol for the QFN32 in KiCAD so I'm hoping I'll have some of the 006 models arriving at my door at some point.

I'm excited for the new CH32V007 chips, looks like they are going to integrate the half-bridge drivers for motor control usage.

Just will be kinda cool to say its the double oh seven when someone asks what uC a design is using.

https://www.wch-ic.com/downloads/CH32V007DS0_PDF.html