Posts

Swindle : Downloading code to the CH32VXX faster

 Now that the new bootloader has shown that it can be fast to write to the CH32v3xx flash, time to revisit the swindle way of loading code. (Gemini was really helpful again. But as a smart assistant, no vibe coding here). Starting point: So we started around average speed of 3kB/S (including erase, download and write) Optim 1: use bigger blocks Before, we were configuring the block size/erase size to be 256 bytes (same as the small hardware pages). Reconfiguring the description to be 4kB gave a small speed bump => 5 kB (internally it will call 256 bytes multiple times, it just reduces the overhead). Optim 2: Faster writing to RAM The dominant slowdown is the amount of time needed to write to the CH32V3xx ram (then we call the flashstub to actually write it, that's pretty fast). Just the writing caps the overall speed to 9 kB/s , without even erasing or writing. So the optimisation is to use a fast_write_ram function there that is using abstract commands with auto exec to pipelin...
Post a Comment
Read more

Revisiting the CH32V303 bootloader (with gemini), it is now FAST

 The DFU bootloader i wrote a while back for the swindle running on the CH32V303/CH32V307 was a quick job. It contained a cut down version of Esprit (the framework) with FreeRTOS and everything. It was about 14kB big. Since i'm playing with antigravity/gemini, it was a good sample task to run it. (On the antigravity front : it does a good job. But you really want to give small tasks, with clear instructions and  check whatever it wants to do. It tends to circumcumvent/hide problems rather than solving them.) Now back to the bootloader. The previous scheme was to use the native 256 bytes for erase and write. Write is actually fast, but erasing the whole 240kB was slow. It happens than the CH32v3xx chips have 2 extra modes compared the the bluepill family  : 32 kB and 64 kB erase. So i switched to a slightly incorrect algorithm (basically if asked to erase 4Kb at the beginning of a 32kB block address, erase the full 32 kB, and dont erase already erased blocks). And now it's...
Post a Comment
Read more

RP2040+W5500 = Ethernet Swindle

Image
 I was not really happy with the CH32V307 Ethernet Version. It is a all-included & cheap version. But it's only 10 Mbps and there is not enough flash/sram to comfortably host swindle. The ESP32S3 wifi based version is sort of working, but the performances are not that great and i had to hack a lot to make rust + esp + cmake based project playing nice together. So here comes the new challenger : W5500 + RP2040 The RP2040 is probably the best host for swindle : - Clock accurate  SWD/RVSWD IO through PIO - Plenty of RAM/Flash - Top notch datasheet The W5500 is a nice UDP/TCP over SPI adapter. The MAC is completely managed by the chip so there is no latency bottleneck due to SPI. Since i'm in the "playing with agent" phase, i rewrote the w5500 driver with the help of deepseek and gemini to be very event driven and not polling driven. The agents  fixed a couple of subtle bugs ( & created some) It works, still need a bit of love.  Mega chain : a GD32F303 debugging ...
Post a Comment
Read more

ESP32S3 mini

Image
 A quick port to support the ESP32S3 mini over Wifi. The pic below is a ESP32S3 debugging a bluepill board (still over wifi) Github page
Post a Comment
Read more

Swindle Preview 6

New year version  Preview 6 https://github.com/mean00/swindle/releases Ethernet version for the CH32V307 eval board RTT & serial fixes Updated blackmagic engine Breakpoints in Flash for CH32V1/2 
Post a Comment
Read more

Ethernet Swindle and gcc vs clang

Image
 There will be soon a new flavor of the swindle : The ethernet swindle It's starting to work nicely, utltimately the goal is to use the CH32V208 that is available for ~ 4$ on aliexpress. It's basically a CH32V307 without HS usb and without fpu,  same flash, same ram (more on that later).  LWIP is pretty big and i'm running short on both flash & ram. While looking into it, i discovered a nice option that gcc has and clang does not "-msave-restore" Since the Riscv does not have stmia/ldmia style instruction, it must push and pop all registers one at a time when entering/exiting a function. That is consuming a lot of code space for short functions. The -msave-restore creates function to save/restore , all possible variants and call them instead of manually pushing/popping registers. Let's give it a try, baseline is clang + hw FPU: Clang + HW FPU    255 508   (+0kB) Clang + no FPU       257 632  (+2KB) Clang + FPU+LTO  232...
Post a Comment
Read more

SW breakpoint for the CH32V203 (and similar)

  The WCH doc clearly  states the QingKev4 b does not have hardware breakpoints. We saw that a bit earlier. The CH32V203 among others is a QingKeV4 b . I've added support for flash software breakpoint for the CH32V[2/3]xx to swindle. It is still a bit experimental. When such software breakpoints are used, under the hood the following happens : - Identify the page where the breakpoint is ( 256 bytes page for the CH32V[2/3]xx - Read the page - Store the 16 bits where the breakpoint is - Replace those 16 bits by a "ebreak" opcode - Erase the page - Write the modified page When removing the breakpoint the same thing happens except we put back the original opcode. It is a bit slow, but usable. The main drawback is that it will speed up flash wearing a lot. The framework is in place, if and when need it will be easy to add such functions to other chips. The main difference with other flashing operations are : - we want to use the smaller size possible. Usually we aim a bit hig...
Post a Comment
Read more