ch32v307, risc-v minicore with ethernet

[DiTBho]

Suggested here yesterday by a forum member, the ch32v307 looks very interesting (at least on the paper)

See here

risc-v@144Mhz
64K RAM
256K flash
Ethernet
USB2.0
i2c
spi
uart (8 channels!!!)
adc
rtc
...

very nice!

anyone going to use one? 

[hans]

Some STM32s also have 8 UARTs in 100QFP, I'm not that impressed by that single fact. However,  1Gbit ethernet Mac (on a MCU!) plus 480Mbit USB HS integrated phy, is quite interesting for a MCU. Both I haven't seen much before in a MCU, but perhaps that's also because they tend to be featured in way quicker chips. Those interfaces are quite overkill for a processor core at only 144MHz and 64K of RAM.
1Gbit ethernet can fill the complete RAM about 2000 times per second, and USB approx 940 times per second. It's absolutely crazy to think of any application that's so light on processing that it can work through 64K of data in 1ms (or 32K of data in 0.5ms etcetera). Perhaps fun to experiment with e.g. a A/D or D/A card that pumps data over ethernet. OTOH, it also depends a lot on the DMA controller and memory bus implementation: if that's done badly, it can make or break the utility quite a lot.

Integrated 10Mbit phy is quite nice to have. There was a recent discussion on the forum looking for such a device.

Some community sourced figures for Coremark (2.64/MHz) seems like this core is slower than a Cortex-m3/m4: https://gitee.com/elecb/ch32v307_core-mark
A Cortex-m3/m4 can reach 3.5 Coremark/MHz with a modern compiler.
It's actually more on par with a Cortex-m0.

[mon2]

Has anyone here heard of this company and used their ICs like this or other MCU ones?

Yes, WCH is a major player in Asia and had their start in the UART markets. We are in the same business and am impressed with the pricing for some of their silicon. Their target audience, in our opinion, appears to be the Asian sector based on the strength of technical support received to date. However, note that they offer a PCI 1S UART  @ $ 0.85 USD (pre-covid pricing) is almost impossible to believe. From reading through assorted UART docs, we do believe that numerous improvements could have been made but again, the price cannot be beat.

On the post of this thread - LCSC has a competition ongoing for which we asked about this 'free' kit promotion. Their reply for the kit being out of stock - NO ETA and not available. We only wanted to purchase the kit @ $10 USD to evaluate the core.

Next, we contacted WCH and they replied immediately and asked only to cover the shipping to us - we shared our DHL account - they shipped us 2 kits without charge. We have not yet had the chance to test the toolchain but hope to do so soon. Just too many other fires to put out due to the semiconductor shortages and screaming demand from OEMS to keep them running.

Summary: WCH is real but not sure on how much support there is currently for the English speaking markets.

LCSC has their silicon and kits in stock (as of this writing):

https://www.lcsc.com/product-detail/Development-Boards-Kits_WCH-Jiangsu-Qin-Heng-CH32V307V-EVT-R1_C2943980.html

Update - sharing a very responsible contact at the WCH factory:

Marketing Department：Jiamin Wang
Address: N0.18,Ningshuang Road,Qinheng Technology Park,Nanjing
Telephone number: 18951773252
Email: wjm[at]wch.cn
Nanjing Qinheng Microelectronics Co., Ltd.

[newbrain]

As I am a sucker for MCU dev boards, and had none with RISC-V, I've just ordered a couple from LCSC (they are in stock).
We'll see when they arrive.

As far as I could see, it should be possible to use GCC or clang, and the WCHlink on board can be bypassed to use some more supported probe (might it also be just a CMSIS-DAP with odd device and vendor Id?).

[westfw]

64K RAM
256K flash

Seems a bit tiny to run 8uarts worth of any modern networking stack.
Maybe it could run LAT.   

[ve7xen]

1Gbit ethernet can fill the complete RAM about 2000 times per second, and USB approx 940 times per second. It's absolutely crazy to think of any application that's so light on processing that it can work through 64K of data in 1ms (or 32K of data in 0.5ms etcetera). Perhaps fun to experiment with e.g. a A/D or D/A card that pumps data over ethernet. OTOH, it also depends a lot on the DMA controller and memory bus implementation: if that's done badly, it can make or break the utility quite a lot.

In both cases there is a wide gulf between 12Mbps FS USB and fully saturating the 480Mbps HS USB where a lot of applications live. GigE vs. 100M is probably tougher to justify, but there's probably not much difference in the complexity of the MAC so why not.

Integrated 10Mbit phy is quite nice to have. There was a recent discussion on the forum looking for such a device.

Definitely intriguing to get onto Ethernet with no external components. I don't think I've seen this choice to go with a 10M PHY onboard even though a much faster MAC is available, but I think it is interesting. Again, many applications that don't need much bandwidth but where having the Ethernet PHY integrated really simplifies and saves on the BOM.

The English datasheets and manuals look pretty complete and readable.

Thanks for the heads up, I will order a couple to play with.

[tszaboo]

Some STM32s also have 8 UARTs in 100QFP, I'm not that impressed by that single fact. However,  1Gbit ethernet Mac (on a MCU!) plus 480Mbit USB HS integrated phy, is quite interesting for a MCU. Both I haven't seen much before in a MCU, but perhaps that's also because they tend to be featured in way quicker chips. Those interfaces are quite overkill for a processor core at only 144MHz and 64K of RAM.
1Gbit ethernet can fill the complete RAM about 2000 times per second, and USB approx 940 times per second. It's absolutely crazy to think of any application that's so light on processing that it can work through 64K of data in 1ms (or 32K of data in 0.5ms etcetera). Perhaps fun to experiment with e.g. a A/D or D/A card that pumps data over ethernet. OTOH, it also depends a lot on the DMA controller and memory bus implementation: if that's done badly, it can make or break the utility quite a lot.

Integrated 10Mbit phy is quite nice to have. There was a recent discussion on the forum looking for such a device.

Some community sourced figures for Coremark seems like this core is slower than a Cortex-m3/m4: https://gitee.com/elecb/ch32v307_core-mark
A Cortex-m3/m4 can reach 3.5 Coremark/MHz with a modern compiler.
It's actually more on par with a Cortex-m0.

You don't necessarily stream continuous data at full speed through USB 2.0. For example it has 2x I2S, so with the right firmware and audio class 2 drivers, it could be a 24 bit 192KHz USB-I2S bridge. Which is only 9mbit/s but it doesn't fit to USB 1.1 speeds.
It looks like a very capable chip. Does this RISC-V4F have execute in place capabilities for external flash?

[DiTBho]

64K RAM
256K flash

Seems a bit tiny to run 8uarts worth of any modern networking stack.
Maybe it could run LAT.   

Probably enough for udp/ip, not for tcp/ip. LAT is in the middle and sounds more than doable.

LAT specifies that if a computer communicating via LAT doesn't receive an acknowledgment within 80 ms for a packet it transmitted, it re-sends that packet.

This can clog a network, tcp/ip is better here, but more complex.

[woofy]

It looks like a very capable chip. Does this RISC-V4F have execute in place capabilities for external flash?

Not that I can see, it does not have QSPI. It does have SD card interface though.

Probably enough for udp/ip, not for tcp/ip.

There are example Tcp Client and Tcp Server examples on their github page.


It looks to be an intriguing chip, I've ordered a dev board to play with.

[martinribelotta]

I have a ch32v307 EVK and the chip is impressive...
The eth10M with on chip PHY is essentially a god-tier in my bussines (industrial control)
But I have only one complaint: the toolchain stack

 - GCC is risc-v embed from Liviu Ionescu (xPack dev tools maintainer) but modified to add WCH-Interrupt-fast attribute for interrupts (verified with grep on cc1, cc1plus and lto1 binaries)
 - OpenOCD is modified to add wlink protocol and ch32vXXX flash algorithm

Both programs are GPL and the source code is not available (at least in my knowledge)

This in a clean violation of GPL code in a very stupid point... the toolchain not have any value for the hardware vendor and remember me the stupid way of microchip licencing of gcc on PIC33/PIC24

Anyone know wath about the source code access? especially for gcc since the version packaged by MounRiver is a quite old (8.2.0)

PD: The only purponse of WCH-Interrupt-fast is prevent the tool make a frame stack on interrupt entry (because the core have a 4-level hardware stack for some interrupts). (see: http://www.wch.cn/downloads/QingKeV4_Processor_Manual_PDF.html)

This is easily handling with custom ASM code for interrupt entries and C function call but this is not the point... WCH was modify a full-GPL code and any binary holder of this toolchain have the rigth to ask the source code...
 

[newbrain]

I've ordered a dev board to play with.

I will order a couple to play with.

I've just ordered a couple from LCSC

And we all chose the right day to do that 

[DiTBho]

This in a clean violation of GPL code in a very stupid point... the toolchain not have any value for the hardware vendor and remember me the stupid way of microchip licencing of gcc on PIC33/PIC24

Yes, it is annoying. It also happens with Note2 and Note5 (eInk readers), but also with the new Fonera (routers), and who knows how many others ...

ah, OpenSource, we are all open with other people's sources ... 

[ve7xen]

I have a ch32v307 EVK and the chip is impressive...
The eth10M with on chip PHY is essentially a god-tier in my bussines (industrial control)
But I have only one complaint: the toolchain stack

 - GCC is risc-v embed from Liviu Ionescu (xPack dev tools maintainer) but modified to add WCH-Interrupt-fast attribute for interrupts (verified with grep on cc1, cc1plus and lto1 binaries)
 - OpenOCD is modified to add wlink protocol and ch32vXXX flash algorithm

Both programs are GPL and the source code is not available (at least in my knowledge)

This in a clean violation of GPL code in a very stupid point... the toolchain not have any value for the hardware vendor and remember me the stupid way of microchip licencing of gcc on PIC33/PIC24

Anyone know wath about the source code access? especially for gcc since the version packaged by MounRiver is a quite old (8.2.0)

PD: The only purponse of WCH-Interrupt-fast is prevent the tool make a frame stack on interrupt entry (because the core have a 4-level hardware stack for some interrupts). (see: http://www.wch.cn/downloads/QingKeV4_Processor_Manual_PDF.html)

This is easily handling with custom ASM code for interrupt entries and C function call but this is not the point... WCH was modify a full-GPL code and any binary holder of this toolchain have the rigth to ask the source code...

Totally agree about the licensing issues, they really need to straighten themselves out, and it would be a great benefit to adoption of their chips. Hopefully they come around soon.

As a practical matter, it seems that vanilla xPack RISCV GCC works fine and there are two separate forks of ch552tool with programming support via the bootloader here https://github.com/MarsTechHAN/ch552tool/pull/22 and here https://github.com/Pe3ucTop/ch552tool/tree/global_rework . Not too sure about 'WCH-Link'; on the ARM side it seems to be CMSIS-DAP compliant, but GigaDevices at least appears to use CMSIS-DAP for their RISC-V micros too, and this appears to work with OpenOCD, so I guess it (or another CMSIS-DAP programmer) works here too. We will soon find out...

[westfw]

  Quote

LAT specifies that if a computer communicating via LAT doesn't receive an acknowledgment within 80 ms for a packet it transmitted, it re-sends that packet.  This can clog a network

Hmm.  So says wikipedia, but that's not the way I remember it.  Their reference for that particular statement is a product announcement for an Ethernet Bridge that prioritized LAT, so it's "marketing" rather than technical analysis.  The actual Spec says there is an 80ms Circuit Timer, but that the retransmit time ought to be more like 1s.

• SERVER_CIRCUIT_TIMER - In the range 1-100. This paranleter specifies 10 nlillisecond intervals. (The value 8 is recomended - 80 milliseconds).
• SERVER_RETRANSMIT_TIMER - In the range 1 to 2 seconds.
• HOST_RETRANSMIT_TIMER - In the range 1 to 2 seconds.

Of course, that's not the point so much as that LAT was more-or-less designed to reduce the performance and hardware requirements of the servers.   (huh.  I have no idea what was inside a DEC LAT Server.  T11?)
A similar cisco TCP terminal server from the same era pretty much required at least 512k of memory (on a 68k), and it really wanted a lot of that to be RAM (so much dynamic memory allocation!)  But then, it typically had a bunch of other features as well...)
   

[newbrain]

A small update:
I asked MounRiver for the GPLed code, and just got an answer with the OpenOCD patches.
As for gcc, they say they are in development of a new version.

I'm now on a plane, I don't know what's inside the tar, but I'll share the code here or on GH later today.

[DiTBho]

So says wikipedia

Yup, but so also says the manual of my DEC-terminal. 80msec is the max value you can set 

[DiTBho]

A similar cisco TCP terminal server from the same era pretty much required at least 512k of memory (on a 68k), and it really wanted a lot of that to be RAM (so much dynamic memory allocation!)  But then, it typically had a bunch of other features as well...)

yup, 512Kbyte on 68k; 1Mbyte on Tektronix MIPS R3K for LAT + Vt100, 32Mbyte for x11+tcp/ip+twm+xterm+telnet

In my case, the challenge is less than 32Kbyte ram on 68HC11(1) for (simplified) Vt100(1) + LAT + CS8900 driver. I cannot allocate more ram, I will probably modify the LAT protocol to create something new and simpler.

64Kbyte is the double on ch32v307(1), but it's has the same challenge

(1) CPU/MPU coupled to a little CPLD + dual-port-RAM (2) for the VDU part. The part that manages VGA timing, video-text ram and PS/2 keyboard.
(2) 4Kbyte for { 80 colls, 43 rows, 1 color, no attributes, hw-Vscroll }

[martinribelotta]

Nice colaboration! Many times, the only reason for non published source code is the ignorance of the GPL derived sources or simply a very tight schedule!

You can publish these patchs in github or via gits? I can integrate in openocd devel and send the patches for review (at least)

This repo contains a reverse eengineering of wlink protocol:
https://github.com/fxsheep/openocd_wchlink-rv
But lacks flash write support

[newbrain]

Nice colaboration! Many times, the only reason for non published source code is the ignorance of the GPL derived sources or simply a very tight schedule!

Yes, let's not assume malice, still no GCC, but they answered in a very short time!

Just got home and untarred the file.

As far as I can see (I have no familiarity whatsoever with OpenOCD codebase) this is the full source of their version.
The driver for WCHlink is in ./src/jtag/drivers/wlink.c (at least) and correctly marked as GPL - this shows at least a modicum of good intentions.
EtA: I found other references to CH32Vxxx in ./src/flash/nor/wchriscv.c

Everyone interested can find the whole shebang here:
https://github.com/newbrain/riscv-openocd-wch.git

I did not try a compare against OpenOCD code.

[newbrain]

BTW: a little note about GPL.
GPL does not mandate that the source be accessible to everyone, but only to the users of the SW.

That said:

• Nowadays, the simplest way to fulfil the rules is to make the source available for public download, especially since...
• ...the user can in turn redistribute it freely!

Some time ago I investigated about how many of our customers really requested for for our code (some of it is pushed upstream when suitable for general consumption, some is on public repos, but for the specific LGPL2 product I was involved in it is distributed on request).

I was told "We got about three requests in ten years".

[SiliconWizard]

Yeah, a few thoughts:
- Not to sound offensive at all - sorry if it does sound so - but, I think many chinese companies have a "loose interaction" with intellectual property in general (in particular that of others), and fully respecting open-source/free software licenses is not necessarily one of their main concerns.
- There are companies that make their modified source fully and easily available, but it only very moderately helps anyone building/maintaining their own version. Microchip comes to mind.
- And yes, as newbrain just said, I guess the huge majority of users do not care anyway.

[ve7xen]

@newbrain Thanks a lot for reaching out to WCH and posting their code publicly!

One of the main 'uses' of the GPL's 'viral' clause is for improvements / additions to be backported to upstream, regardless of whether the downstream developer is interested in doing that themselves. So the main 'user' of that code is going to be developers of the upstream project, and once it gets consumed this way, it's not really needed any longer. It's not that surprising that the number of requests is low, but that doesn't necessarily mean there isn't value in getting that code back to upstream.

The 'better' model of course would be for the vendor to just participate in the upstream development process, in which case the GPL's viral clause isn't really relevant, since their patches are being directly included.

Mostly end users are not going to be too interested in building/running a vendor fork, but there might be many users of the functionality once it gets backported upstream. Like in this situation, probably not many people will consume the WCH openocd fork directly, and may even choose to avoid those chips until it's integrated, but the protocol will get integrated upstream and lots of people will use that.

[tszaboo]

It looks like a very capable chip. Does this RISC-V4F have execute in place capabilities for external flash?

Not that I can see, it does not have QSPI. It does have SD card interface though.

Probably enough for udp/ip, not for tcp/ip.

There are example Tcp Client and Tcp Server examples on their github page.


It looks to be an intriguing chip, I've ordered a dev board to play with.

That's true, though I'm not sure if XiP requires QSPI, maybe it does. In any case I checked the datasheet, and the instruction decode is directly wired to the flash and SRAM so no.
Too bad, I honestly think the amount of RAM and Flash could be a bottleneck for this. If you start using more than 3-4 of those hardware communication channels, the usual bloatware will very quickly eat up that memory.
Ah well, it wouldve been nice to run micropython on this.

[SiliconWizard]

The 'better' model of course would be for the vendor to just participate in the upstream development process, in which case the GPL's viral clause isn't really relevant, since their patches are being directly included.

I agree, but even if the vendor has the best intentions here, it just doesn't always work.

You can ask people that tried submitting code to mainline GCC for instance, and see how far they have gone. It's a very tedious, and often frustrating process. And, if the feature you submit only concerns a particular optimization for a particular chip of a particular vendor, you get basically priority zero and your submission will get to the bottom of the pile, and it might take several years before it's included, if ever. And I don't even blame. That makes sense. You've got to set priorities when managing projects of this size.

So, while certainly not the ideal situation, I can understand companies maintaining their own fork, if they want to get anywhere.

[westfw]

so also says the manual of my DEC-terminal. 80msec is the max value you can set

Reference?  I scanned a few DecServer online manuals, and it looks like you can usually only set the retransmission COUNT.  Also, it doesn't make a lot of sense for the "circuit timer" and the "retransmission timer" to be the same.