Someone dropped this on Twitter. It’s a command line debug interface to CH32V003, a 10 cent RISC V processor. The chip uses a single wire protocol that looks a lot like 1wire but I haven’t checked the timings.
Adding an integration to my to-do list.
Does anyone nearby (EU) have one of these chips I could have?
I bought 50 on Ali express but I imagine theyll take some time getting here. I’m happy to share some if anyone wants to follow along.
@Taniwha mentioned on Twitter that using the ch32 debug while also using I2C would be helpful.
I’m trying to sketch out an interface that’s intuitive.
Maybe a “toolbox” concept with various utilities that can be applied to pins regardless of modes? Debuggers, programmers, flash loaders and dumpers. Right now the closest concept we have is frequency generation and frequency measurement, which have their own commands. Maybe the toolbox could be shaped by a collection of PIO programs that can be loaded.
Something to think about: VT100 has a secondary frame buffer. This is a second “screen” that pops over the main output. It’s not scrollable, just one page. Maybe we can use it for a more complex menu system, and use the ASCII frame characters for a proper 1980s drop down menu feel.
I got this project compiling. It’s CPP though, so a direct integration is a big project.
Installing this now.
I’m not sure this is in the category of tools, but what would be useful to me is a “sanity check” before some of the modes. For instance, if I wire up a UART port and it tells me the RX/TX pins are 5V (Oops!) Same with JTAG/SWD/12C/SPI. Or suppose I want to read some flash memory (using a SOIC8 clip), and it tells me one of the pins is in the wrong state. I know the voltages are displayed, but sometimes people make mistakes. Not me. Nope. Never happened.
I like that idea. There is definitely a need to handle bus states in a consistent way with reality checks. Especially initial state. For example spi clock levels, but also i2c levels.
In I2C there is an issue with devices holding the line after error (not usual in normal use, but a constant in prototyping), this stops the I2C peripheral from resetting properly. The solution is that we run hard reset three times after an error condition to recover.
Perhaps a reference start point for all pins, and if they don’t match 1. Issue error, 2. Attempt auto recover. 3. If auto recover doesn’t work, suggest user intervention .
I love it! And the best warning/error messages suggest possible fixes to the problem.
so for a chv32 I think the thing you should be trying to do is to be workalike with the dongle people are already using - I’m using a linux program wlink that talks to that dongle (that should give you the protocol on the computer <->dongle side) it’s here: GitHub - ch32-rs/wlink: An open source WCH-Link library/command line tool written in Rust.
I kind of think you’re right about modes and protocols: I should be able to set up i2c on these pins and software download of a particular type on those and maybe a 3rd on some other pins - somethings like software download/debug might want to use their own usb channel because they’ll have their own protocols
Good call. Ch32v003fun is great, but more importantly, tha author is brilliant and easy to work with. He runs a discord that probably has a higher concentration of participating '003 HW/SW nerds than the one by WCH themselves.
If you run into square pegs not fitting needed round holes and need advice or help filing them off, GitHub reports are monitored, but I think more eyes are reached in his channel. Those posters and readers are very much the audience if this product. (I’ll probably order after new year dust settles and US distribution works.)
Sorry if this sounds like a promo. I’m just a happy user /developer and since discord is a stinking unsearchable walled garden, though it might not show up in even a thorough web search, thought I’d toss. Out a personal recommendation.
cnlohr_projects is Charles’ and covers many of his. Related. Problems.
https://twitter.com/patrick_riscv/status/1514413606095720448 also mentions three of the best EE type people on Xitter (well. Mastodon now) to follow… these discords cover some of the arm/8051 parts but the focus now really is on all the WCH32[VX][0123]0[357] SoCs plust their billion “USB to something tha5. Needs a little bit-banging in silicon to some goofy front-end” parts.
For anyone tinkering with the new generations of WCH,. These are two great discords (oxymoron duly noted) to follow.
Thank you for the resources and recommendations. I got ch32v003fun up and running. I can implement the arduino compatible debug interface pretty easily, it just pushes and pulls from addresses. I’m really keen to start working on this one.
Cool! It’s a nifty family of parts (esp for .10. - I got a handful of freebies with a related order) and Fun really takes the sharp edges off of them.
The whole line of, basically, STM32 clones with Risc-V cores is pretty groovy but the tiny parts really do fill a unique hole in the industry. 8051 asm vs $0.10 32-bit c or c++ from a mainlined GCC or Clang? Easy choice! Anything that needs to go “down” from esp32 get first crack from WCH in my hobbyist designs these days.
I look forward to joining the BP5 family soon. I’m hoping it can replace a lot of throwaway “getting to know this peripheral” code on Nuttx (half my code ends up fighting Nuttx) or FTDI Friend (user space libraries never seem to work well) or whatever. Bring a scripting interface, LA, decoder, scope, JTAG ws281b in24 amd 32 bit forms, and everything else in one set of cables just sounds 
! Thank you.
Oooh, not to hijack, but that’s a fun thought. A scriptable, timestamped. Ws281x Receiver would Solve some. Interesting problems for me. PIO should be able. to do clock recovery and sampling at 800khz and just store 400 (whatever) RGBWs between EOFs to be picked up by a Real Computer later. Most successive pixels are similar color,.so even a simple Run Length compression may make it fit in the slow USB in nearly runtime. Additionally, most successive frames are similar to each other… I may have just talked myself into a project before even ordering one
Hack on!
I have not done something that complex with PIO, but I believe there is a Manchester encoding example in the SDK that may have the basic components.
Pushing through the USB is of course nice, but it probably requires crapware on the PC side. Logging to internal flash (and be drag and dropped out from the USB disk interface) or just an on screen explorer might be a less involved to handle that data. We really do need a basic nano/vim and hex edit tool that can be used straight from the Bus Pirate.
No crapware needed. In my case, id be happy with a stream of ASCII hex of each RGB (maybe RGBW) value if the data fit the time slice. Even throwing away every other pixel or some such subsample would still be huge for those developing led software that don’t want to test with miles of lights. The pio would have to keep count as there isn’t a “start bit” per byte. Once the drummer starts,. It’s one bit per N clocks. (Corrupting one bit is what turns these strings into a flickering mess.)
This is perhaps getting OT, but stuffing something approximately like
Into the project could be awesome. (Of course, seeing that project, I see it could also be done without BP but integrating it into sigrok and pairing it with a scriptable output would be big for this (tiny) market of devs. I just don’t really have a concept of how much headroom 2040 has while slurping an unforgiving 800Khz sample rate. Drift . 5% on a 10px strand is not big deal, but by the end of a. 1000px strand, you’re sampling the wrong sub-frame. The pio thing could probably bit bang (is the receiver version “bit slurp” or something? Since the strings can be long and the protocol is rarely able to be decoded and dmaed straight into ram.
Someone needs to do this (implement Neopixel receive) and I think it’s within my reach. I think I just talked myself into a project and will add one of these to my wish list. I’d thought about doing this with 'v003, but 2040 is such a better xhoice.
Oh, and of course, Bus Pirate needs HUB75 bus decoders. Later. I need that less. Unit testing Neopixel (et al) against known reference streams or renderinfg them into a web view for documentation would be lovely.
So I’m interested in helping with a ws2812 decoder, which I’m pretty sure we can pull off for at least a short strand and see where it goes from there.
(and the other message that was eaten by the mail response handler)
Re: hex dump and file editing.
Do we have curses? I’ve done tiny hex editors and vim clones in the past. I guess if you just nail the requirement to vt100 80x25, even building a “raw mode” curses (no FMLI) insnt THAT hard… Do the files all fit in RAM/mappings or do they need to be demand-paged?
If you’re willing to coach the design a little (e.g. “we don’t care about your VT-52 or ADM-3a”, " here’s how to do live monitoring without destroying the bus", “we officially don’t car about libe reload”, " file locking is critical ", etc.) I’m willing to do the carpentry on some features like that.
Sounds like we should indeed be friends.
I’d like to build a ws281x receiver.
I have relevant experience building file viewers and implementing “enough” of vi keystrokes in places where it “should not go” like kernel debuggers. Id help build either or both., esp if you have designs and/or UX mocks . (“Hexdump -C. Done”. Works for me…)
Show quoted text
Wow, that ws2812 emulator is awesome! It is definitely on my list to add. One nice thing is we have the 5v buffers to level shift both ways.
Curses is a good question! I have no idea if there is a simple C curses for arm GCC. I don’t see why there shouldn’t be, but I’ve never come across it. If it ran in the 80’s RAM shouldn’t be an issue.
curses/ncurses was complicated because it supported ANY terminal. If you assume a vt100-compatible, this would simplify things a bit. Instead of operation->database->escape code, you could eliminate the database in the middle. I found this simplified library for ARM devices. It might help. GitHub - infinnovation-dev/incurses: Minimal ncurses implementation for use in embedded environments
BTW, there may be other benefits. I noticed a few cases where the toolbar and typing confused the display and it was garbled. In the display command, you could add an option to clear the display.
Good find! It also supports a tiny emacs text editor:
If there’s a similar hex editor script I’d be thrilled
I would really appreciate this! have a bunch of this chips laying around.
I’ve deeper knowledge of WS281x than many, having enabled support for the nRF52 series of chips in FastLED and contributing to WLED.
If the Logic Analyzer works with Sigrok, personally I’d just use that and focus on writing a WS281x decoder for Sigrok.
Not a bad idea. There is a sigrok mode in BP, but I’m still a very new owner and haven’t explored that.
My involvement in similar projects is why I’m interested in emulating them. Debugging a km of strips or wiring and powering a ton of matrices is a drag.
Sigrok has a native decoder and a few add-ons like GitHub - vooon/sigrok-rgb_led_ws281x: Sigrok decoder for WS2812 LED My LA doesn’t play nice with MacOS (darn you, Sipeed!) so I’d discounted that idea long ago. Tripping through BP wouldn’t (shouldn’t) be worse than running it through SLOgicCombo8. Maybe I’ll pursue that. Thanks!
I recognized you had experience with them, simply because you referred to them as pixels instead of LEDs, but … kilometers? Wow… What sort of use case is this?
I didn’t think of WS281x pixels as reliable enough for any significantly large project, if only because the runs have to be short for them to update “close to” simultaneously. And then there is the power injection cabling alone … . Folks don’t realize just how much power these things can draw (matrices too).
If I was concerned about reliability, I would focus on:
I’ve not looked into the BP5 LA mode much, but I think you might want to lookin into using a proper analog analyzer for “real” analysis … it’s likely not the binary signal but the edges, bouncing, reflections that will be of interest in large display debugging. Get a “T” connector using your pixels’ connector type, and create a jig for tapping in by inserting that “T” inline between segments, hookup the LA, get your trace, fix things, move to the next section…
You’re very clever. I’m not so anonymous after all. (It’s not THAT big of a secret…)
Sorry to cloud the matter. I exaggerate. A lot. Like a million billion trillion times a lot. 
I sometimes get into thousands of pixels, but not actually kilometers. That would be torture…and wildly impractical given what Genesis fans know as “The Domino Principle” where losing one px takes out the entire downstream. You’re absolutely right that it’s worth the extra wires to have both a clock (for speed) and pixel bypass…and simply to have multiple controllers also in the bucket brigade via wifi or ESPNow or whatever.
I do have a real scope and it IS useful for detecting ring, overshoot, and generally bad connections on the WS bus. I started this direction, here in the V003 section, because I’d already given non-trivial thought about taking something like a WCH part or the PIO engine in a RP2040 and using it to capture the WS signal and display them on a computer without the annoyance of actuallly hooking up lights. THere are probably dozens of people in the world interested in such a case. (Even THAT might be an exaggeration, too.) Scores more will use the ‘color server’ mode where the controller sends what it thinks it sent to the bus, but we all know that timing glitches and bugs mean those aren’t always the same thing and those are the cases I’d like to capture. Well, designing effects with a dongle sounds better than dragging out the 500W supplies, too.
Something like a BL808 or the RV1103 might be handy because you could dedicate the arduino-class core (a “mere” 600Mhz) to babysitting the bit clocks and then have the Real core (a Ghz or more) to potentially run-length compress it and send over WiFi for analysis. Its pretty crazy that the WS signal is decoded by a $0.01 glorified light bulb but a total pain to receive with normal computing hardware.
You have lots of great ideas and are an asset to the forum. Thank you for the thoughtful conversation.