Arduino Core for CH582-CH583

[0x0fe]

CH582 and CH583 are very useful and well performing BLE SoCs, with the native USB they have the potential to replace NRF52840 and similar in many scenarios.
Sadly, there is no Arduino core for them yet.

Is it possible to start an Arduino core for this familly?
If so it would be really important to implement the automatic flashing via USB, that is, no programmer required, the user can simply plug the native USB port and flash from the IDE (and get debug traces via CDC as well).

Usually the way we implement this simple mechanism is with CDC baudrate handler : when the user wants to upload some code, the host (PC, mac or linux) will issue a standard CDC baudrate change command and set the baudrate to an odd value, like 1200.
In the CH58x USB stack CDC handler, this value will issue a reset of the CH58x after setting the appropriate flag to stay in the bootloader after reset, meanwhile the USB flashing tool is started by the ARduino IDE and will find the CH58x USB peripheral since it is still in bootloader mode, it will then reflash it, after what the CH58x will jump to the user code.

[DeqingSun]

The most difficult part is not uploading, although you may need an extra circuit to power cycle the target chip to enter the bootloader. I've done a similar setup on CH573 and it worked perfectly well.

The difficult part is to create a usable wrapper for the bluetooth library. As far as I know, nobody has done anything in Arduino other than the NRF51 and NRF52.

[0x0fe]

@DeqingSun no, an external circuit is certainly not required to perform the automatic uploading and i described exactly how we do it on most chip, i personally implemented that on STM32 and others, it can be done only relying on standard CDC device definition in any USB stack and using an RTC register or alike as flag for staying in the bootloader after the reset, the reset is a simple system call from the USB stack, available on WCH58x as on many SoC/MCU.
All that is required is a few lines of code in the USB stack and in the bootloader. Besides i noticed this open source upload tool for flashing via native USB. https://github.com/ishiyakazuo/ch55x-tool/blob/master/ch55xtool.py
It works on CH58x, used in the core mentioned below.

Anway i did not mention the need of automatic uploading in regard to difficulty, the bottom line is, if an arduino core is written for this SoC, the most important point is that the automatic uploading works and user does not have to use an external programmer, this has always been the key to SoC adption by lambda users in Arduino ecosystem.

I do not think a wrapper is necessary for the BLE stack, we can just use the SDK code directly, in fact the only part of the SDK that should be wrapped is peripherals, UART, I2C, SPI, USB because so many third party libraries relies on these stardardized API, but it is just a matter of wrapping the SDK API calls most of time.

For the bluetooth, BLE chips do not have a standardized API anyway, and the WCH SDK BLE stack API is simple (contrary to Nordic's) so as long as a few examples are included it should fit most users needs.

A core has been written for CH58x, but aborted, so currently there is only the GPIO, UART and the uploading via the CH55, what lacks is the bootloader for automatic uploading, and the wrapping of periperals SDK libraries (and USB).
https://github.com/ElectronicCats/arduino-wch58x

[DeqingSun]

I did not use ch583 before. But on ch55x series, newer chips are not allowed to jump from user code to bootloader. So hardware reset is required.

When I was using ch573, I did not use a USB port so I just used an external chip to reset the target. And a python script will automatically upload the code after I compile the code in MRS IDE.

https://github.com/DeqingSun/ch573-Automatic-Uploader

And for the BLE stack, I generally do not want to write code in 3-5 different places just to add a characteristic. That is why I prefer the Arduino BLE library whenever possible.

[0x0fe]

@DeqingSun
there is no jump from user code to bootloader, when the CDC baudrate change notification is received from host we set a flag in the RTC domain RAM and reset, after reset this flag is checked by the bootloader , if set, the bootloader keep waiting instead of directly jumping to user app.

When I was using ch573, I did not use a USB port so I just used an external chip to reset the target

CH58x have native USB, so, the upload and debug should be done with it, just like NRF52840, there is really no good reason to use an external chip to make the reset.

Personally i use the vendors IDE and debug probe, so the upload is automatic and doesnt require external script, but most user in the arduino world find that too complicated, that is the reason they use arduino in the first place. They do not want to purchase an external probe, press button, launch a script etc. Just plug one single USB, upload, debug, rinse and repeat.

Regarding the Arduino BLE library, if the CH58x core is developed and the chip more widely adopted by DIY users, no doubt some third party will wrap the WCH BLE stack into this library.

[TianpeiLee]

The register structures of BLE series(excluding CH32V208) and 32 series are difficult to be compatible, and it may be necessary to create a new Bluetooth series arduino core library.

[0x0fe]

@TianpeiLee I see, so i assume the CH58x is not going to get an arduino core soon. It would have been a good candidate for meshtastic though, i guess we'll have to stick with nrf52840 then.

[DeqingSun]

Some update, I'm working on CH573 Arduino support recently and I got the Arduino compiled a working empty sketch, and the code is debuggable with WCH-Link. At this moment non of the Arduino API works except millis. But it does compile and Blink the LED well with WCH API.

Considering the update speed of arduino_core_ch32 from WCH, I don't think it is wise to wait for an official release for CH573 or CH583, I just add a wrapper to adapt to the register difference, it is OK and working. The toolchain is the same after all.

I used to think the porting of Arduino BLE library to CH573 is almost impossible, but now I changed my mind. I just need a wrapper to adapt nRF51822 code to WCH's TMOS library. So far my code can run the SimpleProfile example and use Arduino style API to change broadcast name. And I hope I can finish:

1. BLE peripherals with Arduino style API to add Services and Characteristics, and access data. Mostly by adding wrapper and copy code from sandeepmistry.
2. Adding CDC code with TMOS so the user can do serial communication over USB, also the user may use 1200bps touch to jump to bootloader and upload in Arduino IDE with one click.
3. Basic Arduino API such as GPIO and AnalogRead.
4. Add PR to Rust version of ISP tool so that it can enable/disable SWD, and support CH375DLL.dll so no driver change will be needed on Windows.

[hasaranga]

Some update, I'm working on CH573 Arduino support recently and I got the Arduino compiled a working empty sketch, and the code is debuggable with WCH-Link. At this moment non of the Arduino API works except millis. But it does compile and Blink the LED well with WCH API.

Considering the update speed of arduino_core_ch32 from WCH, I don't think it is wise to wait for an official release for CH573 or CH583, I just add a wrapper to adapt to the register difference, it is OK and working. The toolchain is the same after all.

I used to think the porting of Arduino BLE library to CH573 is almost impossible, but now I changed my mind. I just need a wrapper to adapt nRF51822 code to WCH's TMOS library. So far my code can run the SimpleProfile example and use Arduino style API to change broadcast name. And I hope I can finish:

1. BLE peripherals with Arduino style API to add Services and Characteristics, and access data. Mostly by adding wrapper and copy code from sandeepmistry.
2. Adding CDC code with TMOS so the user can do serial communication over USB, also the user may use 1200bps touch to jump to bootloader and upload in Arduino IDE with one click.
3. Basic Arduino API such as GPIO and AnalogRead.
4. Add PR to Rust version of ISP tool so that it can enable/disable SWD, and support CH375DLL.dll so no driver change will be needed on Windows.

I tried your fork with CH571K. BLE example is not working.

[DeqingSun]

@hasaranga how did you install the board?

[hasaranga]

@DeqingSun on arduino I used board manager. There was no board option for ch571k. So I selected ch573.

[DeqingSun]

@DeqingSun on arduino I used board manager. There was no board option for ch571k. So I selected ch573.

I asked you "how" you "install", which link did you use

[hasaranga]

@DeqingSun on arduino I used board manager. There was no board option for ch571k. So I selected ch573.

I asked you "how" you "install", which link did you use

I used https://github.com/DeqingSun/arduino_core_ch32/releases/download/arduinoPack/package_ch32v_index_add_ch573.json

I followed this tutorial: https://hackaday.io/project/202919-dead-bug-ble-led-blinky

[DeqingSun]

@DeqingSun on arduino I used board manager. There was no board option for ch571k. So I selected ch573.

I asked you "how" you "install", which link did you use

I used https://github.com/DeqingSun/arduino_core_ch32/releases/download/arduinoPack/package_ch32v_index_add_ch573.json

I followed this tutorial: https://hackaday.io/project/202919-dead-bug-ble-led-blinky

Let's do it step by step.
Have you ever used the board to upload other example from vendor to verify if you board functions well?
Can you compile the sketch?
Can you upload the sketch?
Can you observe the BLE device in a debugging tool on phone like Lightblue? You should be able to see the device broadcasting and connect to it, then see all characteristics.
Can you see the device in Webbluetooth scan window?

[hasaranga]

@DeqingSun Simple led blinking example works. it compiles, upload and run as expected. only the BLE example is not working. I used android mobile app called "BLE Scanner". It shows other devices except this. Webbluetooth is not working on my pc for some reason.