ch32v307, risc-v minicore with ethernet

[ddrown]

I haven't tested the USB controllers yet. I intend to test with TinyUSB (which supports the CH32V307), which I'm used to, and see how it goes.

In case you're interested, I took wch's USB high speed (480M) serial example and made some modifications. I have a blog post with more info on my goals, but if you just want the code it's at https://github.com/ddrown/usbhs-cdc

[tellurium]

I've received my dev boards and managed to write my first test program using mainline GCC and a makefile.

Would you be willing to share that GCC + makefile setup ?

That chip has Ethernet MAC and PHY onboard, which is begging for a baremetal webserver example, which we're willing to invest into.
But... 64k RAM and 256k flash only? How practical is having networking on that device.
OTA support needs 2x flash space, cutting 256k down to 128k, making the whole effort not really feasible.

[wilhe_jo]

Wch has a Webserver example on their GitHub already.

You can also configure the SRAM size... Seems they copy serial flash to SRAM and execute from there...

4MB SRAM is very, very cheap... So no problems with ota updating.

73

[mikeselectricstuff]

Wch has a Webserver example on their GitHub already.

You can also configure the SRAM size... Seems they copy serial flash to SRAM and execute from there...

4MB SRAM is very, very cheap... So no problems with ota updating.

73

..I assume you mean SPI flash - yes, crazy cheap - like under ten cents in small qtys at lcsc

[wilhe_jo]

Ahhh, yes ... SPI flash...

Jlcpcb even has one as a basic part... So no even no fee for pcba.
Pretty crazy.

73

[ddrown]

Would you be willing to share that GCC + makefile setup ?

That chip has Ethernet MAC and PHY onboard, which is begging for a baremetal webserver example, which we're willing to invest into.
But... 64k RAM and 256k flash only? How practical is having networking on that device.
OTA support needs 2x flash space, cutting 256k down to 128k, making the whole effort not really feasible.

I've converted a few wch examples to gcc + makefile

https://github.com/ddrown/CH32V307-makefile-example

And I have the base lwip too https://github.com/ddrown/ch32v307-lwip

[wilhe_jo]

Hey, that's interesting!

The "official" binary library is pretty annoying...
But I didn't bother to investigate how much effort it would be to port lwip or uip on my own.

Anyhow, that IC is relatively easy to work with...even though the documentation is basic and the software samples contain quite some chinglish comments...

73

[jnk0le]

So i suppose the chinese "optimized" the R1-1v1 .. To be "cheaper" , and it supposedly needs to switch fw , via USB load. Not buttons (cheaper mcu)
I'll try to find a WIN PC , and run the WCH-LinkUtility , as it seems to be capable of switching fw, on the wchlink.

WCH tools are installing a driver that's doing the switch. Their openocd on windows has also a hard dependency on this driver.
https://github.com/jnk0le/openocd-wch/commit/a82b7041570ed1495b48f2cca8706197cbc160cb#diff-434682464f8ddc4ea0f0cc856a6c8690edc056d4d46594f9e1a92cc7be262535R1079

 I'm also hosting windows builds from gpl lettered sources of their fork here: https://github.com/jnk0le/openocd-wch/releases

[ali_asadzadeh]

Has anyone done ModBUS TCP on this beauty?

[bingo600]

WCH tools are installing a driver that's doing the switch. Their openocd on windows has also a hard dependency on this driver.

Does that mean the "mode" switchin is retained or forgotten on "dongle reboot" ?

I'll be using the dongle on linux.
But might dig up a WIN PC    , for the mode switching.

/Bingo

[wilhe_jo]

I use this WCH 32v307 dev-board you can get eg. from elektor (fastest/cheapest option back then).

This has a wch-link that can be separated (it has jumpers if you don't want to snap it apart).
Never had any issues with it under linux... same with their Eclipse based IDE...

73

[tellurium]

Baremetal Makefile project for ch32v307 with Mongoose library is ready and working:  https://github.com/cesanta/mongoose/tree/master/examples/wch/ch32v307-make-baremetal-builtin

Some facts:
1. The firmware code (not counting toolchain/sdk files), is only 5 files including headers
2. Mongoose implements the whole networking engine (drivers, TCP/IP stack, HTTP/Websocket/MQTT/SNTP.. lib) in a single file
3. In main.c, all network-related code that sets up ethernet, TCP/IP, and implements a web server, is ~20 lines
4. The most amazing thing is that the driver for CH32V307 is ... the ST driver for F4/F7 series! Works with no changes. They use the same MAC controller as ST chips do. Even the address of the MAC controller is the same, 0x40028000 !


Steps to build & try (on Mac, Windows, Linux):
1. Setup build environment: https://mongoose.ws/documentation/tutorials/tools/ , most notably - symlink support for git & make
2. Install riscv toolchain, e.g. on Mac `brew install riscv-gnu-toolchain`
3. clone mongoose repo: git clone https://github.com/cesanta/mongoose/
4. Go to examples/wch/ch32v307-make-baremetal-builtin, start command prompt/terminal, run "make"
5. Attach serial console to USART1: TX pin A9. Use serial converter
6. Observe logs, look at the obtained IP address (see below for logs example)
7. Point your browser at that IP address


412    2 net_builtin.c:197:onstatechang READY, IP: 192.168.2.78
417    2 net_builtin.c:198:onstatechang        GW: 192.168.2.1
41d    2 net_builtin.c:199:onstatechang       MAC: 02:38:9a:a3:39:e3
423    2 main.c:107:main                Initialising application...
429    3 net.c:195:mg_listen            1 0 http://0.0.0.0
42e    2 main.c:110:main                Starting event loop
7dd    2 main.c:35:timer_fn             Ethernet: ready, IP: 192.168.2.78, rx:4, tx:3, dr:0, er:0
bc5    2 main.c:35:timer_fn             Ethernet: ready, IP: 192.168.2.78, rx:5, tx:3, dr:0, er:0
fad    2 main.c:35:timer_fn             Ethernet: ready, IP: 192.168.2.78, rx:5, tx:3, dr:0, er:0

[brucehoult]

Baremetal Makefile project for ch32v307 with Mongoose library is ready and working: 

Nice!

How is the code size?

[tellurium]

How is the code size?

Around 46k on flash


-rwxr-xr-x  1 cpq  staff   47220 22 Nov 04:36 firmware.bin 


RAM footprint:
1. Driver DMA descriptors: 1540 * NUM * 2. NUM is 4 currently, total 12320 bytes
2. Send buffer 1540 bytes
3. Receive queue 8k
4. Per-connection buffers, allocation granularity is tunable as MG_IO_SIZE (default 2048), so let's say 4k per connection.

There is no intermediate BSD socket layer, no intermediate tasks to pass data - so that's pretty much all usage

Summary:
  a) TCP/IP stack eats about 20k of RAM (can be tuned down twice the size, down to 10k)
  b) each connection eats about 4k (can be tuned down to ~1k per connection). Mongoose shapes traffic for file requests, so even downloading a huge file won't increase connection's RAM usage.

Integrating a full device dashboard like this https://mongoose.ws/device-dashboard/ would take:
a) Copying extra 3 files to the source tree
b) Increase on flash footprint ~50k

[SiliconWizard]

How does it compare to lwIP?

[ali_asadzadeh]

Baremetal Makefile project for ch32v307 with Mongoose library is ready and working:

Thanks for sharing, does you lib support modbus too?

[SiliconWizard]

I've done more testing - not the Ethernet peripheral yet.

The ADC, for instance. The docs say that the ADC clock should not exceed 14 MHz - since it has a 1:8 prescaler at most, that means a corresponding PCLK clock of max 112 MHz. I've tested it with a PCLK clock of 144 MHz and didn't notice any significant difference in performance. Obviously the max sampling time is going to be shorter, so you should take that into account.

Another thing: the I2C peripheral is specified for a max PCLK clock of 60 MHz as far as I can tell. There is no further prescaler between PCLK and the I2C peripheral. Experimenting will tell whether using a higher freq PCLK will work, and how.
I2C is not particularly well documented on this chip in general. The way it's implemented is a bit odd. Also, the divider to get a specific SCL frequency is not documented either. Looking at the source code for I2C in the SDK, they use several cases depending on frequency with different factors, that we don't know where they come from. In their provided examples, there's also no example at all (AFAICT) that handles the ACK response of a slave properly. So any practical implementation will require writing your own driver (which is not a bad thing, just don't rely on the SDK too much.)

I've tested USB HS with TinyUSB, works fine. (TinyUSB has quirks of its own with some USB classes, but that's beyond the port to the CH32V307, although I was not able to make any UAC2 class work with it, but hadn't tested UAC2 with TinyUSB before, so that may or may not be specific.)

Another thing I plan on testing after Ethernet is memory protection. And, overclocking the core - haven't yet checkd if it's even possible to generate over 144 MHz with the PLL, I guess it should be.)

[tellurium]

How does it compare to lwIP?

That is a difficult question to answer, let me try.
First of, lwip has 3 APIs: raw callback-based, netconn, and socket.
Depending on an API, the architecture of the whole stack is different.

The raw API handles frames in the same task: driver -> stack -> application, and data is passed via a direct function call.
This is also how Mongoose stack works. This is the fastest architecture in terms of performance. I won't cover LWIP netconn here: it is a "connection abstraction" built on top of raw lwip, very much like Mongoose, which also has a "struct mg_connection" abstraction.

The socket API organises frame handling differently. TCP/IP stack and user app run in different RTOS tasks, and data is passed not via direct function calls, but via a RTOS queue. This makes an implementation slower in comparison to the "raw callback" one, but on the other hand it allows blocking send()/recv() calls. A user app task can block whilst not blocking the driver or stack. Also, a typical lwip firmware runs a separate task to sense PHY status.

Socket layer organises it's own data buffering, to allow app to read data long time after it was received. Data gets buffered by each socket's send/recv buffers, and application has its own buffers. Mongoose built-in stack does not use sockets API, thus it does not have that intermediate buffering - as well as raw LWIP. That means that socket-based implementations are more memory hungry than non-socket. So, socket-based frame handling looks like this:
driver (queue)--> stack + socket buffers task (queue)--> application task

I've done a performance benchmark 6-7 months ago, comparing several implementations for fetching a simple "hello world" page, using "siege" benchmarking tool:siege -c 5 -t 5s http://IP. LWIP config was a default Cube one. All tests were done on a Nucleo-F746ZG, connected to an Ethernet dongle to the same workstation that ran the benchmark - so absolute numbers do not matter, what matters is relative difference.


                       Zephyr      LWIP sockets     LWIP raw    Mongoose
Requests per second    3           16               286         1080
Firmware size          117k        160k             114k        28k


I don't know why zephyr shows so bad there - maybe something was missing, I just don't believe 3 QPS.  LWIP's httpd server was used for the benchmark.

In terms of memory usage, I've shown Mongoose numbers above. LWIP has its own memory manager, and it could be configured to be very efficient with DMA descriptors, so overall I expect that raw LWIP can be configured less RAM hungry as Mongoose. I expect socket-based LWIP to be more memory hungry. Again, that all depends on a specific LWIP config.

[tellurium]

Thanks for sharing, does you lib support modbus too?

The answer is "partially yes".

Mongoose can do raw TCP, so whatever protocol is used on top - like modbus, you can handle "manually": receive data over TCP, and parse modbus manually.  Likewise, for send path, you can craft modbus packets and send them over TCP.

Currently, Mongoose does not have a built-in modbus protocol parser. Shall we add it? Could you share a practical use case please?

[ali_asadzadeh]

Currently, Mongoose does not have a built-in modbus protocol parser. Shall we add it? Could you share a practical use case please?

It would help a lot, since the ch32v307  is the very cheap, and it can be used in almost many industrial products that need modbus communication, for example a a data collector or data loger with modbus tcp.

[SiliconWizard]

                       Zephyr      LWIP sockets     LWIP raw    Mongoose
Requests per second    3           16               286         1080
Firmware size          117k        160k             114k        28k

Thanks, those results look pretty impressive. Basically a no-brainer. What's the catch with Mongoose if any?

[SiliconWizard]

Just a note regarding the official SDK for the CH32V3xx, that can be found here: https://github.com/openwch/ch32v307

There's a version of it in the "C++/Use MRS Create C++ project-example/CH32V307VCT6" subdirectory. And then there's another (newer) version of it in the "/EVT/EXAM/SRC" subdirectory. A bit of a mess to find out where the SDK really is and which is the latest version. Cleaning things up could be a nice touch.

Apart from this bit of a "mess", one thing is slightly more concerning. While the license mentioned in all SDK files in the former directory above is Apache 2.0, in the more recent version in the latter directory above, they have removed the Apache 2.0 license mention and replaced it with a mention that the files should be used only with WCH products. Yeah.

Of course you can write your own support files instead, if you have some time to invest. But as it is, it becomes unclear under which license exactly the files are released.

[jnk0le]

WCH tools are installing a driver that's doing the switch. Their openocd on windows has also a hard dependency on this driver.

Does that mean the "mode" switchin is retained or forgotten on "dongle reboot" ?

I'll be using the dongle on linux.
But might dig up a WIN PC    , for the mode switching.

/Bingo

I think its not persistent.

One more thing you could try is minichlink https://github.com/cnlohr/ch32v003fun/tree/master/minichlink, not sure how it handles this button less module.

[bingo600]

WCH tools are installing a driver that's doing the switch. Their openocd on windows has also a hard dependency on this driver.

Does that mean the "mode" switchin is retained or forgotten on "dongle reboot" ?

I'll be using the dongle on linux.
But might dig up a WIN PC    , for the mode switching.

/Bingo

I think its not persistent.

One more thing you could try is minichlink https://github.com/cnlohr/ch32v003fun/tree/master/minichlink, not sure how it handles this button less module.

That's the one i (ddrown) used , and it's complaining about the mode of the buttonless wchlink , but works fine with the wchlink-e

/Bingo

[tellurium]

Thanks, those results look pretty impressive. Basically a no-brainer. What's the catch with Mongoose if any?

Here's the catch:
Mongoose is dual licensed - GPLv2 / commercial. If your project is free, Mongoose is free for you. If you're making money using Mongoose, then it is not free (unless you comply with GPLv2 and open your sources). I am the original author of Mongoose, started working on it in 2004.

My company works on Mongoose full time, and selling licenses is our business model. Marketing plug: our customers are very diverse: starting from sole freelancers (license price is affordable for them), ending with big names like Bosch, Siemens, etc. Mongoose is run by NASA on International Space Station, serving results of scientific experiments in real time (before, they were physically shipping hard drives to Earth). </End -Of-Marketing-Plug>

I am obviously biased, but convinced that Mongoose is the best embedded network lib on the market.

Now, we started to make a modbus dashboard, the plan is to turn ch32v307 into an easy to use modbus-tcp master. Maybe not just TCP, but also a serial, serving both serial and Ethernet slaves, and providing Web UI dashboard. If anyone has strong opinions / suggestions, please PM me, or start a separate thread. The goal here is to create a simple, usable, open-source modbus master which can work on any chip with network (and by using modules like W5500, it is pretty much, any chip).