Blog Digest

26 March 2025 What should have been a simple exercise in setting up a couple of push button turned into a deep dive (again). There was no problem actually reading the input pins and printing out messages like “Button 1 pressed” in the foreground task. But I really wanted it to be an asynchronous process, so I set up the EXTI external interrupt controller to generate an interrupt for each of the… Read more: CH32V203C8 & TM1637 LED Clock – Part 5

25 March 2025 Running overnight, the clock module seems to be keeping time well. I managed to minimize the hum it generates by wiggling the USB connection of the WCH-LinkE programming adapter, which is where the module and my development board are getting their power. Another thought I had to minimize the excessive noise is to display the time one segment at a time, completely obviating the function of the TM1637 chip.… Read more: CH32V203C8 & TM1637 LED Clock – Part 4

24 March 2025 Many hours later, I am still not seeing any LED segments that are compliant to my will. They just sit there, not illuminated, mocking me. It did occur to me to fire up the old J4-led-key project, just to have a look at some working waveforms. They would not be exactly the same, as the TM1637 and TM1638 are slightly different, but similar enough to perhaps, just maybe, give… Read more: CH32V203C8 & TM1637 LED Clock – Part 3

23 March 2025 Keeping the WCH-supplied SDK RTC example program handy, I will add the necessary portions to my original test program. The first task, as always, is proper initialization. Or is it? Here is the mystery of dealing with peripherals in the “backup power domain”. It might be ticking over just fine as the rest of the chip wakes up from its slumber. But how to tell? It seems I need… Read more: CH32V203C8 & TM1637 LED Clock – Part 2

22 March 2025 I found a little LED clock display module, driven by the Titan Micro Electronics TM1637 driver chip. I’d like to build a simple LED clock using this display module and a WCH CH32V203C8 RISC-V-based microcontroller. I already had some of the “Blue Pill” development boards for the -203 chip from WeAct Studio. They are the same footprint as the STM32-based “Blue Pill” development boards, and fit nicely in a… Read more: CH32V203C8 & TM1637 LED Clock – Part 1

13 March 2025 I’ve been thinking about some of my other assumptions with regard to these little chips and what it takes to program them. One thing is that I had been laboring under the false assumption that the interrupt vector table, should one decide to use one, must reside at location zero in the program memory. In truth, I understood that it could be located on any 1 KB boundary, and… Read more: CH32V00x – More Thoughts and More PCBs

13 March 2025 Continuing my investigation into why the CH32V003 SPI port sometimes just locks up, I have looked at the source code for the two functions that are involved: The SPI_I2S_GetFlagStatus() function and the SPI_I2S_SendData() function. They both do exactly what you would hope that they would do. What comes up as suspicious is my initialization of the port. Here are the values of the two control registers as well as… Read more: CH32V003 driving WS2812B LEDs with SPI – Part 14

12 March 2025 Big news! New chips have dropped! Today I was able to order some of the very new and hitherto unobtanium CH32V002 and CH32V006 chips. Very similar to our dear friend the CH32V003, but with more SRAM (4 KB) and in the case of the -006, more pins and 8 KB SRAM. I also spied a new development board for the top-o-the-line CH32V317 chip. It’s got the -WC package, a… Read more: CH32V003 driving WS2812B LEDs with SPI – Part 13

10 March 2025 Here’s an interesting data point that just came to my attention: the on-going experiment with the WCH-official development board for the CH32V003F4P6 device has hung up after 229,552,000,000+ loops. That’s 229 billion with a ‘b’. What caused the hang-up? Unclear. I was about to shut down the experiment as I thought it was no longer providing any useful data. Well, I was wrong about that. However, it looks more… Read more: CH32V003 driving WS2812B LEDs with SPI – Part 12

8 March 2025 Testing proves testing works. And the testing of the new bare-metal WS2812B LED driver overnight proves that the new bare-metal WS2812B LED driver works, as well. Running just over 12,000 updates per second, it has been running for approximately 16 hours with no unexplainable hang-ups. That’s around 700 million error-free transmissions, which is a lot. So that’s not the problem. I will take this opportunity to bring some closure… Read more: CH32V003 driving WS2812B LEDs with SPI – Part 11

7 March 2025 Today I find the WCH -F4P6 dev board has clocked over 35 billion loops without hanging up. The STK system timer is available in all the CH32V devices. On the QingKe V2 devices, such as our -003 test subject, it is a 32 bit counter that can count up or down and can trigger an interrupt when it hits a particular value. This makes it very useful for basic… Read more: CH32V003 driving WS2812B LEDs with SPI – Part 10

6 March 2025 Hmmm. Good news? Well, news. The absolutely simplest test I could envisage ran all night and did not hang up. You saw the code. It was only checking the SPI status register to see if the transmit register was empty (and waiting forever for it to be so) and only then shipping out a 0x55 test pattern to the SDO pin on PC6, and repeat, ad infinitum. This test… Read more: CH32V003 driving WS2812B LEDs with SPI – Part 9

5 March 2025 Now I am going to write a bare-metal diagnostic for this bizarre SPI timeout behavior. This will eliminate the possibility of some odd malfunction in the vendor-supplied SDK. It will also introduce the possibility of some odd malfunction as a result of my own programming. As I mentioned yesterday, I have had some limited success with writing bare-metal code for these chips, both in the C programming language as… Read more: CH32V003 driving WS2812B LEDs with SPI – Part 8

4 March 2025 Today I see that my overnight testing of the -F4P6 packaged CH32V003 chips shows no errors for over 144 million loops on the WCH board and over 91 million loops for my own development board. While I was able to induce some “power glitches” in my own board (enhanced wiggling), the WCH board proves to be more robust. Part of me thinks that this issue of the SPI locking… Read more: CH32V003 driving WS2812B LEDs with SPI – Part 7

3 March 2025 After building and testing what I consider to be a more robust prototype for our experiments, I was dismayed to find that it misbehaved in precisely the same way. So today we are back to the “gold standard” of the WCH CH32V003 development board. Let’s see how well it does on a longer-term run, say 100,000,000 loops. Now this brings up an interesting question: Does the code need to… Read more: CH32V003 driving WS2812B LEDs with SPI – Part 6

2 March 2025 The test apparatus doesn’t like it when I get up or sit down in front of it. This adds more evidence to the theory that the problem is an intermittent connection, and random vibration from the environment is causing something to conduct either better or worse than it was. There were over 100,000,000 loops and only 1,355 errors overnight, but there was a run of errors just as I… Read more: CH32V003 driving WS2812B LEDs with SPI – Part 5

1 March 2025 I am both displeased and a little disappointed to find my experiment still running today, with over 40,000 successful loops and zero errors. In order to help convince myself that this is not just a statistically unlikely run of “good luck”, I will eliminate the delays between color changes that I had inserted into the code to make the color changes more obvious to us slow(er)-brained humans. Once upon… Read more: CH32V003 driving WS2812B LEDs with SPI – Part 4

28 February 2025 So running overnight, there were over 40,000 loops of the blinking demonstration program, and it was still going. What I shoulda but didna do was add in an error counter that updated with each loop. There’s still time! Moving the experimental apparatus over to the “official” WCH CH32V003 development board was simple enough. I built another programming cable for power, programming and serial communications, as well as a little… Read more: CH32V003 driving WS2812B LEDs with SPI – Part 3

27 February 2025 I firmly believe that the only reason this article is not finished and already published on my web site (well, for you, Dear Reader, it is, but for me, your Humble Narrator, it is yet to be) is that I listed two goals in my introduction and only achieved the first. In retrospect, and following the also-applicable “one topic per email” rule of writing, I should have edited myself,… Read more: CH32V003 driving WS2812B LEDs with SPI – Part 2

26 February 2025 After thinking about the WS2812B driver (if you can call it that) for the CH32V003 chip that I described a few days ago, I determined to make a couple of small improvements: I created a new MounRiver Studio 2 (MRS2) project called, imaginatively, “F4-WS2812B-SPI”. This time I adjusted the system clock to the full 48 MHz, but using the internal HSI oscillator as the base instead of the external… Read more: CH32V003 driving WS2812B LEDs with SPI – Part 1

23 February 2025 I’d like to be able to control some WS2812B addressable RGB LEDs using the CH32V003 chips. I’ve designed a little development board with a CH32V003F4U6 QFN20 device and it has a microscopically tiny WS2812B-compatible LED on it. When I designed this board, I connected the data pin of the WS2812B LED to PA2, but only because I had written some earlier code that already used that pin to drive… Read more: CH32V003 Driving WS2812B Addressable LEDs

22 February 2025 Yesterday I was poking around inside the GPIO ports of the CH32V003 chip, and “printing” out the results to the “console”. The default applications created by the MounRiver Studio 2 “new project wizard” sets up a nice mechanism whereby us old-school programmers can use the printf() function from the standard I/O library, stdio. I tried, unsuccessfully to use the corresponding getchar() function to read a single character back from… Read more: Getting getchar() to Get Characters

21 February 2025 I was setting up a small CH32V003 demo project to see which GPIO pin got toggled in the default MounRiver Studio 2 application. On the CH32X035 default application, it’s PA0 (GPIO port A, pin 0). But there’s no PA0 on the CH32V003, even on the largest package. So which pin is it? The answer surprised me. It turns out that the default application generated by MRS2 does not blink… Read more: An Experiment to Satisfy My Curiosity

14 February 2025 I spent some more time debating with myself about expanding my coverage of these lovely Hershey fonts to some of the other sets, but have decided for the moment to pause with the plain and simplex versions of the Roman set. These more than meet my immediate requirements for the present project and are nice to look at as well. Now I need to go beyond plotting a single… Read more: Notes on RISC-V Assembly Language Programming – Part 19

12 February 2025 I can fit the scalar values for each glyph into a one-dimensional array. Then I need an array of pointers to variable-length arrays of coordinates. Others have been able to do all this with a single array, but I see a lot of wasted space in there. I’m trying to decide ahead of time if I need to reproduce the left column and right column values in the representation… Read more: Notes on RISC-V Assembly Language Programming – Part 18

11 February 2025 Now I can focus on compacting the vector data for the glyphs I need for the project. But first, I have to identify them. This has already been done many times in the past by many people, but I feel that I have to do it myself. Unless I change my mind, which is something I can totally do. A clever collection of interesting Hershey font information has been… Read more: Notes on RISC-V Assembly Language Programming – Part 17

10 February 2025 The little Python script I wrote last night was able to open the ‘occident’ file of Hershey font descriptions and then import them into a list of lines. I then iterated over the list, line by line, extracting the character number, the number of vertices as well as the left- and right-hand extents of each of the characters, then write them to the console. I added some more analysis… Read more: Notes on RISC-V Assembly Language Programming – Part 16

8 February 2025 It’s time to rename this series of posts, as I haven’t been using any sort of RISC-V assembly language at all in this project lately. So now on to bigger and bolder fonts. 9 February 2025 So not a lot of work got done on the project yesterday, but I did have some time to think about it. And it occurred to me that bit-mapped fonts are great when… Read more: Notes on RISC-V Assembly Language Programming – Part 15

7 February 2025 Now for some odd reason the display is not working at all today. Ummm, well, no, I’m wrong. It was working just fine. It was just displaying a screen full of zeros, as was right and proper for it to be doing. I was messing around with the screen initialization values, poking various bit patterns in to see where they showed up. Yesterday, the dots would show up in… Read more: Notes on RISC-V Assembly Language Programming – Part 14

6 February 2025 Today’s first objective is to capture and measure the SCL signal and see how close it gets to the requested 400 KHz that I specified in the I2C initialization function. After attaching an extension cable in order to tap into the SCL line going to the OLED module, I measure a SCL signal trying so hard to wiggle at 423 KHz, which is almost 5% over what I specified.… Read more: Notes on RISC-V Assembly Language Programming – Part 13