ch32v307 Modbus + Web UI firmware

[tellurium]

I think i'll get my other boards from ali soon , seems like they have cleared customs ...
Let's see if they have same issue.

Thank you, appreciate the effort!
Concerning the firmware functionality itself. Do you have a specific use case, where you might use the modbus functionality for some practical task?

[bingo600]

I think i'll get my other boards from ali soon , seems like they have cleared customs ...
Let's see if they have same issue.

Thank you, appreciate the effort!
Concerning the firmware functionality itself. Do you have a specific use case, where you might use the modbus functionality for some practical task?

No not really yet ...
I just liked the way the mongoose framework was presenting it self, "easy webpage" etc ...

But i do have a Solar Controller that speaks modbus, and was considering a "web status page" for that one.

I was thinking more in the way of Home Automation ...
Connect one of those cheap 4-chan relay boards, and make a webpage to turn on/off. Think mini "Tasmota" but for wired ethernet
Or Temp sensors etc ...
Maybe also control relay state via wget/curl, and read values via modbus and/or SNMP.
I like the way the APC master switches can be controlled via SNMP. Makes controlling soo easy from a linux server.

Note: 
I'm a hobbyist (w. a fulltime job) , so i might be "dreaming" a bit with the above ... 
I have never made any embeddd network programming or http page design.

/Bingo

[tellurium]

Great, thank you!
I am looking for a feedback from anyone who'd use that modbus firmware, regardless whether it is a hobby or a commercial project.
Those are not far apart anyways.

My idea behind this particular implementation of modbus firmware was to make it possible to relay modbus to MQTT:

1. Provide a UI to configure modbus endpoints: like, addresses, poll intervals, etc. That should be on the setting page, https://mongoose.ws/modbus-dashboard/#/settings
2. Provide an optional MQTT endpoint, also on the settings page. If that is configured, the result of every modbus poll will be relayed to MQTT. This can be used for home/building automation
3. The dashboard page, https://mongoose.ws/modbus-dashboard/#/, should just list configured devices (endpoints), and their status.
4. Optionally, a reverse MQTT path could be implemented. For example, by writing to a certain topic a certain message, one could write to a modbus endpoint. This way, this firmware could act as a two-way Modbus <-> MQTT gateway

That's what I have in mind, but that is something I just imagined. I'd like to have a feedback from someone who'd actually use that - or, similar functionality, before implementing it.

bingo600, that said, if you have some practical use case and you'd like it to be reflected in the UI - please let me know!

And I appreciate your time & attention so far.

[bingo600]

Got my new boards from ALI today

Here's the mongoose fw on the same type board , as used previously (with the Ether-Link issue)

Absolutely no issue ... with the new board

Code: [Select]

0      2 main.c:46:main                 Starting, CPU freq 144 MHz
5      2 main.c:51:main                 RAM/FLASH configuration: 64/256
c      2 main.c:55:main                 Heap size: 48032 bytes. RAM: used 1032, free 50823
14     3 stm32f.c:152:mg_tcpip_driver_s PHY ID: 0x00 0x00
19     2 main.c:70:main                 MAC: 02:50:37:7e:37:e5. Waiting for IP...
401    3 stm32f.c:201:mg_tcpip_driver_s Link is 10M half-duplex
406    1 net_builtin.c:202:onstatechang Link up
40a    3 net_builtin.c:302:tx_dhcp_disc DHCP discover sent. Our MAC: 02:50:37:7e:37:e5
412    2 main.c:26:timer_fn             Ethernet: up, IP: 0.0.0.0, rx:0, tx:1, dr:0, er:0 RAM: 10860/40787
7e9    3 net_builtin.c:302:tx_dhcp_disc DHCP discover sent. Our MAC: 02:50:37:7e:37:e5
7f1    2 main.c:26:timer_fn             Ethernet: up, IP: 0.0.0.0, rx:0, tx:2, dr:0, er:0 RAM: 10860/40787
bd1    3 net_builtin.c:302:tx_dhcp_disc DHCP discover sent. Our MAC: 02:50:37:7e:37:e5
bd9    2 main.c:26:timer_fn             Ethernet: up, IP: 0.0.0.0, rx:0, tx:3, dr:0, er:0 RAM: 10860/40787
fb9    3 net_builtin.c:302:tx_dhcp_disc DHCP discover sent. Our MAC: 02:50:37:7e:37:e5
fc1    2 main.c:26:timer_fn             Ethernet: up, IP: 0.0.0.0, rx:0, tx:4, dr:0, er:0 RAM: 10860/40787
13a1   3 net_builtin.c:302:tx_dhcp_disc DHCP discover sent. Our MAC: 02:50:37:7e:37:e5
13a8   3 net_builtin.c:281:tx_dhcp_requ DHCP req sent
13ad   2 net_builtin.c:408:rx_dhcp_clie Lease: 7132 sec (7137)
13b3   2 net_builtin.c:197:onstatechang READY, IP: 10.1.1.219
13b8   2 net_builtin.c:198:onstatechang        GW: 10.1.1.1
13be   2 net_builtin.c:199:onstatechang       MAC: 02:50:37:7e:37:e5
13c4   2 main.c:26:timer_fn             Ethernet: ready, IP: 10.1.1.219, rx:2, tx:7, dr:0, er:0 RAM: 10860/40787
13ce   2 main.c:75:main                 Initialising application...
13d4   3 net.c:202:mg_listen            1 0 http://0.0.0.0:8000
13da   3 net.c:202:mg_listen            2 0 http://0.0.0.0/
13df   3 net.c:202:mg_listen            3 0 https://0.0.0.0/
13e5   2 main.c:79:main                 Starting event loop
13ea   3 net.c:177:mg_connect           4 -1 udp://time.google.com:123
13f0   3 net.c:177:mg_connect           5 -1 udp://8.8.8.8:53
13f6   3 net_builtin.c:997:mg_connect_r 5 10.1.1.219:32768 -> 8.8.8.8:53
1791   2 main.c:26:timer_fn             Ethernet: ready, IP: 10.1.1.219, rx:3, tx:8, dr:0, er:0 RAM: 12060/39587
1b79   2 main.c:26:timer_fn             Ethernet: ready, IP: 10.1.1.219, rx:3, tx:8, dr:0, er:0 RAM: 12060/39587
1f61   2 main.c:26:timer_fn             Ethernet: ready, IP: 10.1.1.219, rx:3, tx:8, dr:0, er:0 RAM: 12060/39587
1fa9   3 net.c:151:mg_close_conn        4 -1 closed


So my first board is strange .... 
Only difference is that i have soldered the dual header rows on the first board.
But i have checked the soldering , and even cleaned it with a toothbrush and IPA.


I also got some of the boards you tested on first port .....
But it seems like i'd need to do DFU load on that one ... (Well it doesn't have the easy 10-pin header the other board has)
Haven't tried DFU yet , but i think there might be a "Boot" button ...

Edit:
Well DFU was just as on a STM32F4   - Press RST + Boot , then release RST , and then Boot.
I used the wchisp for programming that one ...

No issues ...

/Bingo

[bingo600]

I just had a headscratcher   

I got a few of these boards
https://www.aliexpress.com/item/1005004350410929.html

And tried to load the webapp.
This time putting the board in DFU mode , and use wchisp for programming via an USB-C cable.
One board was success , two other boards failed in verify.

I tried to switch to another USB cable ... Same result. 

After digging a bit i found out the boards came from the factory with flash protection active 

Below are my notes for disabling flash protection via wchisp.

Enter DFU mode (like STM32F4)

Press Reset + BOOT0
Release Reset
Release Boot0




***********  WCHISP ********

Commands
-------------------

> wchisp flash ./path/to/firmware.{bin,hex,elf}

> wchisp config info

> wchisp config reset

******************************

Info Unprotected
$ wchisp info
14:26:26 [INFO] Chip: CH32V307VCT6[0x7017] (Code Flash: 256KiB)
14:26:26 [INFO] Chip UID: FD-47-89-26-3B-38-C1-A6
14:26:26 [INFO] BTVER(bootloader ver): 02.90
14:26:26 [INFO] Code Flash protected: false  <<<---------*** UNPROTECTED
14:26:26 [INFO] Current config registers: a55aff0000ff00ffffffffff00020900fd4789263b38c1a6
RDPR_USER: 0x00FF5AA5
  [7:0]   RDPR 0xA5 (0b10100101)
    `- Unprotected         <<<---------*** UNPROTECTED
  [16:16] IWDG_SW 0x1 (0b1)
    `- IWDG enabled by the software, and disabled by hardware
  [17:17] STOP_RST 0x1 (0b1)
    `- Disable
  [18:18] STANDBY_RST 0x1 (0b1)
    `- Disable, entering standby-mode without RST
  [23:22] SRAM_CODE_MODE 0x3 (0b11)
    `- CODE-228KB + RAM-32KB   <<<-------****** Flash/Ram mode
DATA: 0xFF00FF00
  [7:0]   DATA0 0x0 (0b0)
  [23:16] DATA1 0x0 (0b0)
WRP: 0xFFFFFFFF
  `- Unprotected

*********************

Info Protected
$ wchisp info
14:21:38 [WARN] WRP register: bfffffff
14:21:38 [INFO] Chip: CH32V307VCT6[0x7017] (Code Flash: 256KiB)
14:21:38 [INFO] Chip UID: 3F-49-89-26-3B-38-03-A8
14:21:38 [INFO] BTVER(bootloader ver): 02.90
14:21:38 [INFO] Code Flash protected: true  <<<---------*** PROTECTED
14:21:38 [INFO] Current config registers: ff001fe000ff00ffbfffffff000209003f4989263b3803a8
RDPR_USER: 0xE01F00FF
  [7:0]   RDPR 0xFF (0b11111111)
    `- Protected    <<<---------*** PROTECTED
  [16:16] IWDG_SW 0x1 (0b1)
    `- IWDG enabled by the software, and disabled by hardware
  [17:17] STOP_RST 0x1 (0b1)
    `- Disable
  [18:18] STANDBY_RST 0x1 (0b1)
    `- Disable, entering standby-mode without RST
  [23:22] SRAM_CODE_MODE 0x0 (0b0)
    `- CODE-192KB + RAM-128KB   <<<-------****** Flash/Ram mode
DATA: 0xFF00FF00
  [7:0]   DATA0 0x0 (0b0)
  [23:16] DATA1 0x0 (0b0)
WRP: 0xFFFFFFBF
  `- Some 4K sections are protected   <<<---------*** PROTECTED


*********************

Config Reset (If info shows protected)

wchisp config reset
** Must power reset device after config reset ... "Flash unprotect" (like on stm)

*********************

Note that the config reset will set the MCU for default 32K Ram / 288K Flash.
And that it seems like wchisp doesn't have code for setting the Ram/Flash config .... yet.


If you're using wchisp , there is a way to get mongoose to set the (preferred) 64K Ram/ 256K Flash for you ... Thnx Tellurium 

1:
Uncomment this line in main.c , to have mogoose set the config.


2:
Do a : make clean all   (It will build for 32K)

3:
Upload that ...
Now the chip should be set for 64K Ram.

4:
Now build for 64K Ram
make CFLAGS_EXTRA='-Wl,--defsym -Wl,RAM_64K=1' clean all

5:
Upload that ....


wchisp won't touch/change the Ram/Flash config, unless told to reset config.
So you could "recomment" the line you uncommented in main.c. If you prefer mongoose not to alter the Ram/Flash config.

 
/Bingo

[S. Petrukhin]

If it's not difficult, please tell me how it works?
Does ch32v307 issue a Modbus exchange web page on an http request?

[tellurium]

If it's not difficult, please tell me how it works?
Does ch32v307 issue a Modbus exchange web page on an http request?

Correct. This is how it works:

1. A button click on the Web UI page triggers a REST API call, /api/modbus/exec:
https://github.com/cesanta/mongoose/blob/c8d45c9ff1b3042919d19ba823415d35ce1b0fbc/examples/modbus-dashboard/net.c#L262-L263

2. Which in turn creates a modbus TCP connection to the target device:
https://github.com/cesanta/mongoose/blob/c8d45c9ff1b3042919d19ba823415d35ce1b0fbc/examples/modbus-dashboard/net.c#L187-L188

The original HTTP REST request waits, but starts a software timer: https://github.com/cesanta/mongoose/blob/c8d45c9ff1b3042919d19ba823415d35ce1b0fbc/examples/modbus-dashboard/net.c#L192-L193

3. The modbus connection (https://github.com/cesanta/mongoose/blob/c8d45c9ff1b3042919d19ba823415d35ce1b0fbc/examples/modbus-dashboard/net.c#L144C40-L145) sends a request to a target device (https://github.com/cesanta/mongoose/blob/c8d45c9ff1b3042919d19ba823415d35ce1b0fbc/examples/modbus-dashboard/net.c#L147-L181)
and when it receives a response (https://github.com/cesanta/mongoose/blob/c8d45c9ff1b3042919d19ba823415d35ce1b0fbc/examples/modbus-dashboard/net.c#L104-L107),
it finds an original REST request (https://github.com/cesanta/mongoose/blob/c8d45c9ff1b3042919d19ba823415d35ce1b0fbc/examples/modbus-dashboard/net.c#L109-L111) and notifies it about the modbus response. An original REST request then sends a reponse to the Web UI (https://github.com/cesanta/mongoose/blob/c8d45c9ff1b3042919d19ba823415d35ce1b0fbc/examples/modbus-dashboard/net.c#L285-L292)

4. In case if modbus request times out, the original REST connection returns failure (https://github.com/cesanta/mongoose/blob/c8d45c9ff1b3042919d19ba823415d35ce1b0fbc/examples/modbus-dashboard/net.c#L281-L283)

[S. Petrukhin]

Correct. This is how it works:

Thanks for the detailed answer!
I have never used REST technology. 

That is, do you have your own application that exchanges with MK?

I'm asking because my devices have a WEB interface targeted for using the browser.
I did not find in JS the possibility of a direct binary request for Modbus exchange and made Modbus/HTTP.
The browser sends get requests, usint fetch request.
For example, /read?bank=4&startreg=10&count=2 and receives responses in the body in the form of values=34,56 or error=4

[tellurium]

I did not find in JS the possibility of a direct binary request for Modbus exchange and made Modbus/HTTP.
The browser sends get requests, usint fetch request.
For example, /read?bank=4&startreg=10&count=2 and receives responses in the body in the form of values=34,56 or error=4

JS inside the browser is limited only to HTTP and Websocket protocols. It cannot create arbitrary TCP/UDP connections.
Therefore, the Web UI talks (via HTTP REST) to a device, and a device in turn creates arbitrary connections. In our case, it is Modbus.

REST means "representational state transfer", but basically, if you think that "HTTP", "REST", or "Ajax" is the same - you won't be mistaken. It's the same stuff. That is, making HTTP requests to get some data.

[S. Petrukhin]

Thanks! I had a doubt that I was behind the times and missed the opportunities of JS.