#637 – CH32V003...fun! with CNLohr

Dave Jones: This is The Amp Hour Podcast. Released June 25th, 2023. Episode 637. CH32V003 Fun with CNLohr.

Dave Jones: Welcome to the Amp Hour. I'm Chris Gammell of Contextual Electronics.

Chris Gammell: And I'm CNLohr. I've got a YouTube channel and do a lot of online open source and open source hardware work.

Dave Jones: Welcome, CN. You are doing some awesome stuff. And in fact, you are doing stuff that I kind of always wish I would have done. Namely, like, do anything with that CH32 part. And we're definitely going to talk about that here. So thanks for not only showing the world what you're doing with the CH32 part, but also building some tooling around it.

Chris Gammell: Yeah, it was the CH32V003 was kind of the first time I looked at one of these cheap Chinese devices in the world of like giga devices in Poya. And I was like, this is it. This is the one. And when I looked to there was really no good tooling around it. It was either the proprietary SDK, which was really overburdened, or like the platform IO, which was also overburdened. And I was like, no, I think that this is the time to act. If we can make some tooling around this to really open up the power of the chip while this is hot. Like, I think a lot of people are going to have a lot of fun with this.

Dave Jones: I actually didn't realize there was a platform IO plugin for it. So that's been around since the beginning almost?

Chris Gammell: About the beginning. Yeah, it was enough to get the chip off the ground, but just barely. It used all the same Mound River EVT stuff. So Mound River is the proprietary sort of development kit environment for the CH32V003. And really the whole CH32V line. CH being WCH, the semiconductor in China. Yeah, and V meaning RISC-V. Oh, the V is V003, right? Oh, yeah, yeah, yeah. Yeah, the RISC-V is CH32V. Yep.

Dave Jones: Right, yeah. And actually, so Dave, my co-host, has also done, I think you referred to your video, you referred to his video, but like the Moon River, Mound River? Mound River, yeah. Yeah, yeah. And it's just like an eclipse-based IDE, right? It's nothing like, nothing fancy. It looks kind of just standard style tooling.

Chris Gammell: No, the IDE is just fine. It's just a lot of it has to do with sort of, the issue, I think, is that this entire space has sort of acquired a baggage surrounding it because of a lot of decisions that ST made about 10 years ago. And all the way down to, like, for instance, if you, the minimum blink program for the CH32V003 is like, I think, over a kilobyte. And it also has to do, like, software divide and multiply on boot up. Like, it's just, it's a bunch of, anytime you do pretty much anything with it, it brings in far more than you would hope that it should bring in.

Dave Jones: That's like in the, with like the STM32F0 line? Where did that, where did that come from?

Chris Gammell: Oh, yeah. Yeah, so in the STM32 world, they have sort of this, how they call it, the hardware abstraction layer, in order to abstract all of the hardware from most user programs, in order to facilitate people moving between processors in the STM32 family. And it kind of sort of worked-ish for them. It also had this interesting effect of sort of vendor lock-in, at least up until recently, because like, yes, you could be able to take your code and port it to something else. If you were conscious about it, but if you're already using the entire SDK from STMicroelectronics, then it's, it's a little bit harder to get out of that ecosystem. And it worked out like really well. And it also made it easier for some programmers to be able to hop in and like get started. It's just that it's still an abstraction. It still adds sophistication and complication and problems to the overall software development process.

Dave Jones: Yeah. Yeah. I think that, and it sounds like a mistake that's been many times. A lot of different platforms as well. Not just, not just there, just like the making it, making it easier and making the support load easier for the company that are building these chips.

Chris Gammell: Yeah. Yeah. And, and, and to an extent that kind of makes sense. If somebody says, Hey, I'm having trouble with my code. And it's like this gnarly drawn out piece of very hard to follow C code. That's going to be hard to support as, as a company. But if they're already forced to use your how, your, your abstraction layer, then that gets a little bit easier of like, Oh, well, you're doing this wrong. So you don't have to worry about some of the lower level things in that support burden. So I understand where those desires came from, but the tax is just so heavy that comes with it that it's just, for me, I've always kind of struggled to find some way out from underneath that, that load.

Dave Jones: That's interesting. So like, if you find a new part, say you found, you know, let's just say vendor X, so there's some brand new vendor. Are you like, are you more likely to throw away like a how that they provide and then go write your own?

Chris Gammell: I think it depends on what my goals are. If I, my goal is to use this part to accomplish a specific project, then no, I will absolutely use their how 100%. And I think it is crucial for programmers to understand these hows and why they exist. And I think that for me, using those hows sort of like keeps me up to date with that and keeps me my, my understanding of what they're trying to accomplish. Like it makes that very clear to me. If my goal is much more sort of like, this seems like a gateway to a lot of projects and a lot of really interesting stuff that could be done, then yes, I'm, my goal would hopefully be to engineer a new sort of like minimal SDK surrounding it. But the effort that it takes to build one of those SDKs to go all the way back to the metal and just build something that's fast and simple for users to use. It's, it's a couple months of investment. So I, I only do so very judiciously.

Dave Jones: Yeah. That's a lot of cozying up to a data sheet on a Saturday night with a glass of wine sort of thing, huh? A lot of, a lot of register maps in your future.

Chris Gammell: Yes, there, there had been many nights in the last couple of months where I'm sitting there on my cell phone, paging through the technical reference manual in bed, making sure that like, I'm not missing something. And, you know, it's like one of those things where it's like, this is really hard to do if a data sheet is a thousand pages. But when a data sheet is only 300, 400 pages, it becomes tenable for one person to actually, and like for several people to actually understand like what makes this chip tick. And I think that that's, that's a really interesting part too, about the CH32V is that it isn't a thousand page technical reference manual. And it is something where you can sit down and over the course of a few weeks, you can really understand, maybe not like all of the details of every bit in every register, but you can understand how the chip kind of fits together and how, like how you can leverage that in your own sort of engineering.

Dave Jones: Yeah, that makes sense. Yeah. And I think, especially like, as you're saying, collaborating and not having to like compartmentalize, you know, like there's abstraction layers, but then there's also just compartmentalizing for, as your team needs to grow, if you want to like have a faster timeline, then you start to grow how many people are a part of it. And then you start to compartmentalize and say like, well, I'll just do the ADC, but then you have to start agreeing on APIs and all that other stuff. Yeah.

Chris Gammell: Yeah. A lot of people, I guess. So going back to it, when I mentioned, oh, if, if I need to just do this one specific thing, I'll just use whatever hell is available. But also if I have a team of like 30 people and it's going to be some really big effort, like that's there are 10 people, five people, about five people, I think is where this, this trade-off happens. Uh, that's when other environments like free RTOS and stuff like that start to actually make sense, even though they themselves are a massive tax to debug ability and, and like general, like, like the number of times that I found where it's like, we're like, okay, now we have the thing almost working, but we're having to like balance the size of each one of the stacks and trying to get like, like, oh, but it's, it becomes so burdensome. But the answer is like, we wouldn't have been able to even get to where we were in the speed. We were able to, unless we had like a framework that a lot of people could speak a common language into. It just bothers me that the tax is so high. So when it comes to something that it's going to be me alone or me with a few other people going to be working on things, then I think there's a lot of value in just jettisoning a lot of that complexity.

Dave Jones: Yeah. It also is interesting thinking about like how, how far you would expect the chip to go. So like, there's the complexity you've already kind of talked to, like just in like, you know, sometimes they talk about like killer lines of code, but. Even I think actually data sheet pages is a good, like kind of hardware, firmware crossover one. Yeah. But then like how, if it was like a, you know, so I'm using this NRF 9160 a lot. And if it's like a dual core M33 plus cellular interface, like craziness, right. It's like, that's probably going to have more needs for outside libraries and like interface layers to like other, you know, third party plugin type things. And then like, at that point, then it probably makes sense to, to have more stuff than you might want to try and do with it. You know, it's kind of like how far, how far are you going to try and take this thing? That sort of thing. Like this, this specific part.

Chris Gammell: I think that that, that comes down to two pieces. One is sort of like some of what you've described, like if you were going to do something that requires significant and sophisticated integration with really advanced IP stacks, like, okay, fine. You're going to use like free RTOS and lightweight IP or something. But also it comes down to the programmer. Like, like a lot of programmers who have lived in that world are really only comfortable in that world. And there are other programmers who have not lived in that world and can go much further on just sort of the bare metal. And it's, I don't know, I w I would encourage. I would really encourage as many programmers as possible to, to sort of explore the bare metal arena to see how far they can push it because you can go so far so fast and you can produce products that don't have the sort of like the long tail of, of problems that sort of come with more sophisticated and deeper systems where you're like, yeah, 1% of customers, one out of every thousand times they turn on the device, it doesn't, it doesn't turn on. And they have to like reboot it. And you're like, okay, well, great. That's like, how do you debug that? And it's, it, a lot of that is a function of just how, how much complexity has been hidden away. Like when you, when you shovel complexity under the rug, it, it's still there. Like, it's not like the complexity goes away just because like, oh, well my, my application is only 40 lines of code and it does all of this cool stuff. Yeah. But like that, that's great. Like you were able to do that quickly, but like at the end of the day, as you keep abstracting things up, like you now you acquire all of the burden and all of the, the technical debt of all of the pieces underneath of the whole umbrella.

Dave Jones: See, now that's interesting because that, so we've been talking about our tosses and like kind of the, the dangers of an R toss, but that also, it sounds to me when you say like, it's only 40 lines of code, that sounds like kind of more modern interpreted languages that people are putting, pushing down onto micros as well. But like, yeah, it's only like, you know, it's like one line to get a, to get a network connection is like, okay, sure. Yeah.

Chris Gammell: But I mean, it, there is a sort of trade-off there. If it is a hobbyist, like, like there is, there's a lot of ease of use versus like,

Dave Jones: like long term longevity and, and security and everything else, right? Yeah. Yeah. Yeah. That's, it's interesting. So you said, you know, you're cozying up to the data sheet quite often. Mm-hmm. Given your experience, I actually had a friend tell me recently, he's like, the thing I'm most scared about switching from ARM to RIS-5 is actually just that I know the ARM instruction set pretty well. The CARTS-XM instruction set pretty well. Is it like, is it like reading a new language or is it like?

Chris Gammell: Yes. It's, I'm not going to sugarcoat it. I'm just not going to sugarcoat it. It's, it is, I know ARM assembly pretty well. I know extensive assembly better. And I know x86 assembly better than that. And it has actually been a struggle because there's, and I actually, I guess I know AVR assembly the best. Mm-hmm. And it has been a struggle with the, the RIS-5 architecture because there are, there are so many situations. And it sounds really nitpicky, but it.

Dave Jones: That is what we're here for, Cian. That's what we're here for. But this is what the amp hour, that's basically like a sub, a subtext of the amp hour. It's really nitpicky about electronics.

Chris Gammell: The, the, the funny part is like, there are things which on every other saying architecture are just a single instruction. And in, in like the RIS-5 world, that's just not the case. Like, like if you wanted to compare, like there's no, like, as far as I know, maybe I'm misremembering, but I don't think that there's any, any sort of like compare this register against an immediate and jump if. There's no like flags for like an overflow flag or like a negative flag or something like that. All of these things are, it's, it's very C centric instead of assembly centric. And it's very like, and I say assembly centric, it's still assembly, but it's like, there is sort of like when you code things in assembly, there's some nice things to have that like aren't necessarily in C or like that, that RISC-V is kind of geared around like, no, we wanted to make a processor, which is going to be like the reduced instruction set. And it's going to be able to compile from C to this very effectively. And they, they really accomplished it, but it means that when you're writing the assembly code for RISC-V, which inevitably you will always have some of like, we're going to get to that. I'm sure with the, the USB stuff, I'm sure you were down in the depths. Yeah. Well, I mean, it's not just that it's, it's a lot of places you find yourself writing assembly for a lot of things. But it's like, like, yeah, I did spend a lot of time writing assembly for the USB thing, but anyway, it is, it is sort of like, okay, I have to actually do all of the actions at a very low level and very carefully. And it's, it has taken me about as long to really learn RISC-V assembly as it has just about any other assembly. It's not like, it's not that it's like so close to some other one. I was able to just jump to it. Maybe there is, I guess like maybe MIPS, it's probably very similar to, but I never learned MIPS assembly. So it's, it's been a bit annoying. Hmm.

Dave Jones: Yeah, no, it's an interesting take. I mean, like, like we've kind of described here, you are kind of in the depths of the data sheet and you're doing all this stuff anyways. So it sounds like it's a, it sounds like a good thing to learn anyways. And, and the switch over is kind of, kind of tough. So yeah.

Chris Gammell: It's good to know. And I would say like, no matter what architecture you're on, if you know the assembly, like you're going to make better decisions when you're coding for it. Like if, for instance, if you're on extensa, like extensa, the ability to go load a 32 bit, like immediate, like, like, like a 32 bit value and loaded into register or do something with it is actually really slow. But like, that's not the case on, on risk five on risk five, it's two instructions, but it's, it's much slower on extensa. And so sort of like the way that you will write your C code should be slightly changed in order to kind of think through how, how is this going to really be compiled on the system?

Dave Jones: Yeah. I wonder, is there additional benefits to knowing the low level stuff? Because it's, it doesn't seem like the extensive stuff is often, you know, when we say extensive these days, I feel like, all right, we're talking about expressive, right? Yeah. Yeah. Yeah. It's not like a lot of people are using extensa otherwise, though it does exist. And, and it's like, okay, so it's on expressive parts, but those things are beasts, right? I mean, like they are really beefy processor. They're, they're like 150 plus megahertz cores and like, but they're not targeting it down at the low level stuff. Whereas the risk five stuff is trying to play in that low, that low end environment.

Chris Gammell: That is true. It's the same token. The risk five stuff is just generic. It just happens to be that somebody is playing with it in the really like low end space. And like going back to that, even like the, it is funny because risk five in sort of the space of where the CH32V003 lives. Actually, let's just clarify. CH32V003 is a risk five processor. It's got 48 megahertz. It's got 16 kilobytes of flash, two kilobytes of RAM. I was literally about to ask us to zoom out and ask about this.

Dave Jones: This is perfect. Yeah. Okay.

Chris Gammell: So it, it, it, it is like, it's basically an AT mega 168 with more RAM. Like it's, that's basically what it is. It's a little bit faster.

Dave Jones: It's got, it's got 18 GPIOs. It's got you art spy. I swear to see. I'm reading the page. I spy. I swear to see eight channel, 10 bit ADCs, timers, four different types of packages. Yeah. What else? Anything?

Chris Gammell: Oh, yeah. I mean, it's, it's basically an AVR. And like, I think that's kind of what drew me to it is just that it really is this basic part, except that it is, it's uses risk five, which is really nice for a few reasons. One is that like all of the existing compiler tooling is being done for you. You even get GDB, you get all of the extra, like the, the sort of low level tools work and they work really well because they've been tested across a wide variety of things versus like AVR GCC is like, I'm trying to remember, there was actually like a product I was working on where we found out every now and then it like lost in input. And it's hard to explain like why that's important, but like, it was literally just like X plus plus and now X isn't right. And we dug into it. It turns out there was a compiler bug where it literally couldn't reliably add a nut, like, like I equals I plus one on a 32 bit end. And it's like, how does that even happen for a mature compiler? But like, I mean, I would be, I understand that it's just because the AVR GCC doesn't have as much mileage on it as some of the other compilers, but it's still just wolf.

Dave Jones: Yeah. It is interesting too, because like you, it seems like you're still not still you're in that interstitial space, you know, where it sounds like you're kind of talking like a, like a grumpy gray beard, right. Of like I code assembly and I've dealt with tools that have this other stuff. And then, you know, someone listening now, they're like, well, of course everything works. Of course you have all free tooling. Of course you have compilers that are reliable. Like, you know, like that kind of like difference in perspective. Some of that is number of miles on you in terms of like how many projects you've done, but it's also kind of bridging the gap from the old microcontroller way into some of the new microcontroller ways. Yeah.

Chris Gammell: I think that, that Espressif was a very good picture of that, that there was only going to be one of these in the history of all of computing. And what happened with Espressif was they, they use their extensa core and they use the proprietary cadence GCC. The extensa GCC was not open source. It was, I mean, it was kind of open source, but only half open source. And to use the ESP8266 core, that was not open source. You had to use the proprietary compiler. And it was only through the efforts of a handful of people out in the community who like took it and was like, this is an amazing chip. If this had an open source tool chain, it would be amazing. And they did it. And sort of like, I think the only reason Espressif opened up and people might not remember that originally Espressif was completely closed.

Dave Jones: They didn't care at the beginning. They, they did turn, which is great. I mean, like they recognize the power of it. They're like, Oh wow. Look at, look at this community stuff. That's great. They definitely have invested in a lot.

Chris Gammell: But they only turned after the community stepped up and was like, this is so much more powerful than you guys realize. Right. And people started exploring that space and, and Espressif embraced it. So instead of like trying to fight it and doing takedown notices off of like, like literally all of the early ESP 8266 development was done on this, like leaked VM from some partner customer of Espressif. Oh really? Oh, interesting. So XP virtual machine that you run in virtual box and it had a copy of like the compiler. Sounds like there's going to be a book about this someday, huh? Maybe. I mean, I hope there was, because it was such a significant thing. Like people, people just don't, I guess like it was always the norm for all of the really interesting processors to be totally closed. And like AVRs were the exception, but that's not the case anymore. Now, more and more, the companies are starting to understand that like, no, actually, if we make it available to people first, it's, it's going to go better. And I think that that like WCH also realized that, like that was, I think part of their, their big effort was they really wanted to make sure that even if not a hundred percent of it was open, at least it was usable by anybody, even on their, their official Mound River SDK. And, and if it wasn't for Espressif having this fortune that they had where like, because Espressif didn't resist it because Espressif embraced it, Espressif grew. I don't, I don't know what their market cap was 15 years ago versus like today, but I'm pretty sure it's way bigger. It's way bigger. Yeah. I mean, they're listed on the Shanghai exchange now. Yeah. It's not because they, it's not because they had some magic Silicon. The Silicon was no more interesting than any of the real tech Silicon or any of the, the media, I guess media tech is bigger, but their Silicon wasn't that interesting. It was just interesting that you could actually do something with it. Like you think about the single, like one by one USB wifi dongles, those existed at that time, but nobody had sort of a way of which, Oh, well you can go code it and actually flip some GPIOs. And it was like, right. It seems so silly that like literally all any of these other companies had to do was just, okay, make it so other people can flip your GPIOs. But I really think it all comes down to that one leaked VM. Like, like I really think we would be in a different world today if that, if that VM had not leaked.

Dave Jones: Doesn't cost play into it though. I mean, like some of it is, I mean, I just, you know, much like we're talking about the CH32 V003 as well, like cost is a headlining feature in all of these spaces as well. It feels like, I feel like that can't be ignored, you know, like.

Chris Gammell: Yes, that, that is absolutely true. And I think that like, so if you look at the time TI sort of had their, I forgot the name of the part, but their CC series 24.

Dave Jones: Yeah.

Chris Gammell: Yeah. That one. Yeah. And that was, it was functionally almost as good as the ESP8266. Like if, if they had made the right play, it would have been, it would have been the thing that hobbyists would have used. But, but there is sort of, you're right that there is a sort of magic change that happens when the modules that you can go plug into your part is $5. You can get wifi for $5. And in reality, like, like we, we, people kept finding out ways of making that cheaper and cheaper. And so like, by the end of it, it was like, okay, well the reality of it is now it's a sub dollar part that you can go include on your schematic. And now you have wifi or, or the sub dollar part is your microcontroller and your wifi. Right. Now it's just like, you know, if you have any reason to have any connectivity, you'd be crazy to do anything else. And, and that is an interesting point. Cause like, so there, there were other companies who were playing in the space that like the cheap Chinese or, or a Taiwanese, like, like chip market that had wifi at the time, but their, their stuff didn't leak. And so they weren't able to make it right. And you had these other companies like TI who were playing in the space, but their stuff were really, was really expensive comparatively.

CNLohr: Yeah. Right.

Chris Gammell: And sort of like, I guess you're right that it is a confluence. It was a matter of them being cheap and it was a matter of them also like having the availability to do interesting things. Yeah.

Dave Jones: Well, read my book in 24 months as I read about the history. I'm just kidding. I'm never writing a book like that. That would be terrible.

Chris Gammell: I am unfortunately not an author at all. So somebody is going to have to, somebody else is going to have to write that. Yeah.

Dave Jones: Yeah. It's interesting. So we were talking a little bit before the show and about, you know, specifically with the 8266, you know, so a lot of it, you know, when I, when I look at the expressive stuff, I think the community-based growth is definitely when the Arduino port started happening. That really opened up a lot of things as well, but then that was layered on top of an RTOS, I believe. Yes. Yeah. It was, yeah. Yeah. Yeah. Yeah. And then, but then you started, so you have a YouTube channel, which people should go check out, of course. And you have some experiments on there where you're like, yeah, we don't, we don't need a NARTOS. And you kind of alluded to that earlier too. So what did that look like in that, in that space? It was, well, okay.

Chris Gammell: I guess the 8266 is interesting for, there's a caveat here. Well, okay. Let me say what I did and then I'll explain the caveat. So one of the things I did was I was like, well, you know, the ESP8266 is really interesting and fast, but there were aspects of it that were kind of being burdened. So they called their, their, their original SDK, the non-OS SDK, alluding to it being a pretty simple and Spartan development environment. It had timers and it had malloc. And that's, that's really about it as far as their like OS environment goes. And it was, it was, it was a really good thing to write stuff in, but, and then on top of that is how they built their, their, their wifi stack and their IP stack on like LWIP and their, their proprietary wifi stack on top of that. And it, it worked out pretty well. It was not nearly as heavily burdened as free RTOS was on the part. So like later on there was community port of free, sorry of yeah, a free RTOS to the ESP8266 and the non-OS SDK was, was a lot cleaner and booted much faster and more powerful. I would say, well, powerful, depending on your definition of powerful than the free RTOS stack. But eventually the company really decided like, no, we're going to go in the direction of the free RTOS. And so I was like, well, you know what, what happens if you just go the other direction, just kind of as like an experiment. And I was just curious, like, cause like now all of a sudden you don't have any of the same restrictions surrounding like how the hardware should be used. You can just use it to do whatever you want. And so I explored, I called it no SDK 8266. And the answer was like, oh, you can actually just like get it to wake up blank, do some basic stuff, use some of the basic IO. Like you could use the DMA on the I squared S engine to send and receive like 80 megahertz bit streams and stuff like that with like a kilobyte worth of code, which also then opens it up to like, oh, well now you can just run everything from RAM because now you don't have to have this huge amount of like space that is filled with all of the code to support the system. Oh, and you can also now flash it like in half a second. Like you're compiling and flashing processes basically instant. When you, when you get all of those pieces together, it is kind of this fun environment. And a couple of people did take that and like do some other fun little projects with it. Oh, the one of the other parts about that makes it interesting is that when you're in that mode, you don't have to work at 80 or 160 megahertz. You can just take the part up to around 380 megahertz and it works just fine.

Dave Jones: Wow.

Chris Gammell: Like if you're not limited by the same like, like sort of like assumptions, because like they made sure that all of everything surrounded the Wi-Fi chip and the way the part is configured, you really can't use the part at anything other than 80 or 120 and still use the Wi-Fi effectively. But like if you're not using the Wi-Fi, which no SDK 266 didn't do. That's the caveat. When I, when I wrote this nano stack, it didn't have Wi-Fi, but it is a pretty interesting microcontroller at that point anyway. And it goes crazy fast. And yeah, so it, it, it was, it was a fun, interesting experiment. Ultimately it was never really adopted by any major projects or anything like that. And I didn't really expect it to be, it was such a strange thing to take this part that people are like trying to now like go more in the direction of free artos with and then be like, well, what happens if we just tear it all out? And the answer was like, yeah, yeah. Contrarian. It was just an experiment and it, yeah, it was, it was fun, but there really wasn't that much that was that interesting about it. I think.

Dave Jones: It's interesting. So that is usually the, the point that I, I have a marker in the sand that says when there's a networking stack, when there's stuff that's going to be like internet based, I think it's in the artos land. Is that a, is that a fair, a fair characterization from your perspective or, or do you, do you put that marker in a different spot given, given our conversation here?

Chris Gammell: I, I don't, I, I don't, I don't. Well, there's really two parts. One is like, I acknowledge that is usually where the marker is, but I acknowledge that only begrudgingly in that, like I have done things with like IP stacks. Uh, one of the videos I did was Minecraft on a microscope slide where I literally made a circuit board on a clear glass microscope slide that had an AVR and a ENC 424J 600, which is a, an ethernet adapter or ethernet Mac and five. Oh yeah. And I ran Minecraft on it and a whole Minecraft server, multiplayer Minecraft server with, I think it supported up to eight players. And, uh, it had an SD card to store the chunks on. Um, and all of that was on this little AT mega 168. Oh no, it was 320, AT mega 328. So it's got like 32 kilobytes of flash, about two kilobytes of Ram. Uh, and it had no problem doing this. And it could also like serve webpages and, and stuff like that while it was working. So like, there's nothing that stops you from using.

Dave Jones: Sure. Okay. Yeah. These are rules of thumb that are probably not applying to CM lore. Is that fair? It's not just me.

Chris Gammell: Like there are a lot of other people who, who do, who sort of play in this space. Like I, I was definitely not the first one either. Like, uh, I can't remember his, I know he goes by Igor online. Uh, Igor plug was one of the projects he did where, where he did a similar thing where it was just like, like you say, I, I bit banged on, like you mentioned, I met bang on the AT tiny 85 at some point. Like, yeah, I did do bit bang. But as soon as that article hit hack a day, everybody was like, Hey, 10 years ago, this other guy did it. And how could they publish the article about it? And it was like, like, I had no idea.

Dave Jones: People in a hack a day comment section pointed out as something being done before. That's so odd.

Chris Gammell: I mean, it was, it was kind of embarrassing that like, I had not, not actually done the prior work and realized that or like, like check for it and be like, yeah, no, somebody had already done this like 10 years ago. Uh, and so it's, it's kind of a thing that's been done a fair bit. I, I've also. Sort of in, in, in working for other, other people, like I've seen. I've seen a lot of custom TCP IP stacks out there. Like lightweight IP is not the only game in town. And I think a lot of people forget that. And that there's a lot of other trade-offs that can be made. You're not limited to that. And the same thing goes for things like lightweight USB, which is a total misnomer. Lightweight USB is, is massive. It's, it's, it's a huge USB stack. I don't really know why it's even called lightweight. Maybe it started off as lightweight, but like there are lots of other options out there. And a lot of times, like, I think engineers are scared of, or project managers are scared of like, oh no, it's just USB. We can just write that. Or, oh no, it's just ethernet. Like it's okay. We can do that. Like, like you don't need all of these crazy stacks. So like, I don't want the flag to be at when you're using IP. Well, now you're using free RTOS because like, I've seen times where that's not true. And I just, I don't want, I, I wish engineers were not limited to that thinking.

Dave Jones: Cause interesting. Okay. Let me put on my project, project manager hat here then. So like, what about, so what do you, what do you say to a project manager? Who's like, well, what about the support burden? Cause I feel like support burden is, is the main reason in my head that I think like, don't write that from scratch. Is that fair or unfair?

Chris Gammell: I think the problem here is that it's, I don't think I would win an argument in this. Because I have been around the block and my experience says that no, there is a massive amount of support burden with free RTOS. I'm picking on free RTOS, but that's only because that's where I'd have it. And it's not because free RTOS is bad. It's not because there's some bug in it. It's because of the type of code that people who are using free RTOS, right? Inherently like free RTOS is great if you have like one thread, but the reason you're using free RTOS is because you have a lot of threads. That's right. Yeah. And, and when you start doing that, you start finding these really rough situations that you run into. Cause the, the burden of pushing and popping things off of cues inside of interrupts, instead of just doing the work in the interrupt is so high that you end up like burning a lot of your CPU. And even though you started with 144 megahertz or something like it's, it's just, well, now you've burned it all. And I think one of the problems is if you put on the business hat, you're like, well, we'll just buy the next more expensive processor and just solve it by putting in a more expensive

Dave Jones: processor, which we have the margin. We can, we can eat it.

Chris Gammell: Yeah. That bothers me a lot because if you multiply it out, if you're making a million of something and now you're spending 30 cents more per thing, that's $300,000. Whereas if you just made a different decision upfront to be a little bit more dainty with your, with your resources, then you wouldn't be in this position. So it's, it's something.

Dave Jones: It's interesting. It's interesting take for sure. And I, you know, I think about it with the, you know, like, so I'm in, I've been working in the Zephyr ecosystem and like in my head, at least when I think about these arguments, it's like, well, who's someone else is maintaining that, you know, it's like there's a bug fix. There's a critical, you know, there's like a heart bleed style thing where something has to be updated. You know, now your internal company, you know, your internal company that is, hasn't developed a stack, someone else has developed it and you're pulling it in or the community is pulling it in. Like then you get that benefit, right? You get that kind of network effect from a ecosystem of an RTOS. But that's, that's non-zero time as well, because, you know, moving up to the next version, you know, so it might, it might be equivalent in a best case scenario as well.

Chris Gammell: Yeah. It is a tough one to sort of articulate around and like really think through. I don't think that, that it's a hundred percent clear win, because if you think about the attack surface of a lot of these other things, you end up bringing in far more features and far more lines of code that are far more like each one of those lines of code are more susceptible because there's so many of, or sorry, not each one, each one of the lines of code is the same level of susceptibility. And like, yes, it's going to be fewer holes per line of code, but they're still going to be there. They still get discovered. They still like, it's, it's shocking how far things can go before bugs are found that may or may not have been introduced in a base. Like, like if you were to do it yourself, like there was a stack that I used for a commercial job I did a long time ago, which was, this is literally certified for aircraft. The stack was certified for use on aircraft. And we couldn't figure out why we're about one out of every 65,000 packets we sent through. It didn't, it didn't go through and we could resend it and it would never go through. And it's like, but like, like the last place we thought to look was inside of this, this stack and no, it turned out that they, they had missed one of the rules surrounding UDP, UDP checksum. So like, even though that was really mature and it was really sort of like, it was in a world where it's like, this is clearly a commercial product that was made by experts. There's still bugs. There's still holes. Totally.

Dave Jones: And, and like, right. And you had the burden of finding that too. It wasn't like there was an announcement that came down. You also found it. So then you also had to push it back up and say, you guys go fix this. And then it comes back down. You have to like implement. Yeah.

Chris Gammell: Yeah. So it's like those sorts of things, like they shouldn't happen, but so like if you, if you reason about like sort of the, the rationality surrounding why you would all like always, always, always want to use lightweight IP or always, always, always want to use one of these commercial IP stacks or always, always, always want to leverage this. It's like in the nominal case that is a hundred percent true and it's irrefutable, but in the like actual boots on the ground case, it's like, I think I would still use them like 90% of the time. And so I used it and it worked, it worked fine. As far as I'm aware of, like I've, I've been in contact with that customer for a while and have had no, no complaints. So, I mean, it's maybe I just got really lucky. I don't know, but it's, it's, it's, it's very strange to reason about because the, the, not the nominal case is a hundred percent. Always. You should be using like the, the extra, like free RTOS stack or any of the RTOS stacks and like a, an established set of libraries for all of the stuff. But in reality, it's, I guess it feels a little bit less clear.

Dave Jones: You know, I, I kind of think about it like the, you know, there's like a lot of pushback about, not a lot of pushback, but there's like people like, oh, you don't need a college degree. You know, you can prove out your, you know, and this is me saying this too, right? It's like, you know, some I've seen, I've met a lot of very interesting people that could prove their abilities and they've learned on their own and they could prove it through like projects and their past work. And like a college degree does not bestow that. But like in the general broad case, it's still like companies are like, yeah, but it's a pretty good indicator that I could hire someone to teach them. And so it kind of feels like the same thing where it's like this kind of general use case. It's probably, you know, it's a general rule of thumb and like, yeah, use this thing. But then, but there's going to be corner cases always. And this sounds like that might be one of them.

Chris Gammell: That's a really, really good description of it. Like I have never heard anybody make that comparison, but I really, I really like that a lot. That's because it really is like the college degree. It is a piece of paper. There's somebody who went and did a bunch of unit tests and yeah, their unit tests probably didn't test your one specific situation, but it does give you a pretty good baseline of expectation for the competency of that tool.

Dave Jones: Yeah.

Chris Gammell: And that's, that's a really good expression of it. I've worked with people who are absolutely stellar without college degrees, but you know,

Dave Jones: in general, if you don't really know, it's hard to hire it that way, right? Yeah. You're at Microsoft and you're like, all right, we got to hire 2000 engineers this time. It's like, how many, how many project portfolio sites are you going through? Like that's a little tougher, you know? That's yeah. That's a really, really good metaphor.

Chris Gammell: I really like that.

Dave Jones: Thanks. That's nice of you to say.

Chris Gammell: I just thought of it.

Dave Jones: I would, so, okay, let's, let's talk about, now let's talk about a corner case because there's interesting corner cases that you've been working on specific to the CH32V003. And I'm getting better at saying that part number. Thanks to you. Let's talk about USB. So you have implemented USB stuff. I'm not sure the full extent of the USB. I'm just following your Twitter account and it's in the bootloader. So, so what's going on with that?

Chris Gammell: So a couple of pieces here. One is I had actually, I have already kind of coded my own USB stacks in the past for a variety of things. So I do have like a background in USB and it's something that like, I always kind of like side eye, I'm like, like looking at it and I'm like, can I, can I somehow work this in?

Dave Jones: Yeah. And quick question about that. Sorry. Sorry to cut you off. The, the hardware that you have for, so one thing that's always scared me about USB is like, I, I, I don't have any protocol to code or anything like that. You know, I know that Eagle's a big one. I have a Luna on order with all apologies to great Scott gadgets. I've had a Luna on order for 18 months and it's, it is languishing and I can't figure out how to cancel my order. And so that's been one of the big scary things for me. I assume you have, do you have hardware on hand for decoding?

Chris Gammell: Yes, I absolutely do. I will say I, I don't think I would have been able to, cause like if, if I don't know anybody out there is familiar with VUSB, but somebody had actually coded a AVR software only USB stack for USB low speed. And I don't know how they did it. Like I literally do not know. Cause they did it in an age where there weren't cheap, easy to access. Yeah. USB things. Now we're at the point where like discount someone bringing a tool home from work though. I, I, that's a decent point. Yeah. If somebody had, but it is extremely difficult to code a protocol like USB without, without some sort of protocol decoder of some sort. And, and like being able to get all the timing to match up and all of that. It's, it's very hard, but when you have all of those tools so that you can go like write some code, fire it up, see what it looks like, see how this worked and then just keep iterating.

Dave Jones: Yeah.

Chris Gammell: Step, step, step, step. Oh, there's the error.

Dave Jones: Right. And then it's like, it's basically like a, yeah, it's a debugger basically in the physical realm.

Chris Gammell: Yeah. Like if you have all of that and I, and I do so like on my live stream, I actually, uh, so I did, I did all of the development of the base USB stack live on YouTube. Wow. Wow. But anyway, like it worked, don't get me wrong. It worked out to like five live streams, each like seven hours a piece.

Dave Jones: Like it, I'm just really impressed with people that can do live streams. I cannot concentrate. I'm like so like worried. I'm always like looking at the camera. I'm like, Oh, people are watching right now. And I get like so anxious, you know, like I, it's, I'm very impressed with people who can do that. I, uh, I, I, I ignore the camera. I don't know.

Chris Gammell: I didn't watch it. I don't ignore the camera, but I guess it's there's, there's, so it's kind of two piece. One is like, yeah, you spend more time like thinking out loud and talking to people, but that also means that there are rubber duckies. So if you say something stupid, you're like, Oh wait, no, that's not right. Let me go fix it. And better than that, there's actually a, somebody on my discord server named duck who is rubber duckies who would like be like watching over as you're coding. They're like, Hey, no line 49 fix line 49. And it's like, yeah, yeah, exactly. So there, there's, there's both a multiplier and a distractor from it. But like, I think overall it's, it's about neutral. It's way more stressful. I'll tell you that. But it's as far as like actual getting stuff done is concerned, it's probably not a strict loss. So the idea though, I guess backing up. So I had done my own USB stacks. I had actually done a ESP USB, which was USB on the ESP D 266, where I bit banged the USB on it. So like the idea is it runs at 160 megahertz. And then I, every 53.333 cycles, don't worry about how that works. You go either write or read a bit on the USB bus and you implement the USB bus protocol and that just worked. So I was able to go make a low speed device on the ESP 82 66 with it. I've done a lot of USB devices. Like I first started learning on V USB for the AVRs. I'd also done a couple USB stacks for the STM 32 of Oh, for two and the 80 mega three 28 U four and U eight or 80 mega 32 U four and 32 U eight. And sort of like, I was just ready to go with this because this is a 10 cent chip. Yeah. And I want to be able to say, plug a potentiometer into it and get a joystick out of it. Or I want a mouse jiggler. I want to something like, I want to be able to take input from the real world and control something in electronics. Or I want to be able to, from software on my computer, send messages to this device to go control some I squared C thing or magnetometer or, or accelerometer gyro thing, or you name it. Like any of this weird interconnection. Normally you need something which is a minimum of an STM 32 F Oh four two at 70 cents, or I guess that's what 80 cents now. And then, or an 80 mega 32 U four, which is a, like a, a very favorite processor of a lot of people to use, but it's, it's kind of slow and it's also like a dollar 40. So it's like not that cheap, but for this, this, this it's like, no, this is a 10 cent processor. This is 10 cents. You have no excuse for just putting into something. So I want to be able to control these things. I want to be able to do all this stuff. And by the way, it's not just 16 kilobytes of flash. It's 16 kilobytes of flash plus this 1920 by special boot area. And so like the gauntlet was on, it's like, okay, if I can turn this into an Arduino where I can flash the part over USB, so I don't need a programmer. Then like, that's interesting to me.

Dave Jones: Yeah. Yeah, totally. You know, another interesting thing that's about, about this too, is like the, you know, every, every thing that you add, you, I'm going to say you CN, but also like the community, like that encourages cloning. Like, like other manufacturers might look at that and be like, oh, we can make a part like that. Or that encourages more parts like this. Like, it's this weird, like that network effect, but like this weird groundswell that might drive other low cost parts and like other people implementing it. It just, it actually could have an influence on the market.

Chris Gammell: I really hope it does. And, and on top of that, like there, there's always the situation with providers where like, like manufacturers and chips and stuff like that. So if you have a product and you have a vendor A and vendor B, you might 100% know you're going with vendor A. Yeah. Like you might know that like vendor A is it, they, this is like, we have to use them, but that doesn't mean you shouldn't like, like the thing you're looking for shouldn't be in the last place you look, because if you look at vendor B and you start talking to vendor B and vendor B can do it for 10 cents on a dollar that a can, well, now you can go back to vendor A and be like, look, I know you guys are better, but these guys are making a really compelling case here. This is, this is 10 cents. This is an $1.40. Can we do a little bit better? And I sort of see some of this is doing that at, at sort of a macro level instead of a micro level. And I really hope that that happens. You're right. I do think that this could be a sort of groundswell. I do think that like with ever since sort of like the Puduks started to take in, like started to dig into the space. Puduk is a, uh, an eight bit, uh, yeah. Three cent. Uh, well, it really, the good ones are like six cents, but five or six cent micro. I think that that kind of started to make people like, yeah, actually, yeah, we could probably do this. We could probably make these, these, these things interesting in that space. And they, they did. And I think that I really hope, I hope we can look back in 10 years and be like, ah, WCH hit it. Like before they were really only known for being like cheap USB to serial adapters that you'd go plug up next to your Espressif chip. Like, I hope that we can look back.

Dave Jones: I do remember my first, my first experience with WCH chips were like, oh, I'm not going to download that, that, that, that windows driver from that random ass site. I'm just like, cause they were going on like cheap Arduinos, I think. And I think that was my first thing. And I was like, WCH, is a CH in there? Are they, are they Swiss? Like, I don't know why I thought that was Swiss. Is the CH something Swiss? I think so. Yeah. Yeah. Yeah. I just thought it was Swiss for some reason. And then I'm like, no, this is shady, shady looking site, but yeah, they're growing for sure.

Chris Gammell: Yeah. And I, I really hope that we can look back and sort of see, I really hope that they get rewarded in the, the grand scheme of things for sort of taking the risks and taking the, the stance that they have. Like there's no reason. I mean, other than, I guess, Poya trying to be poised for the space. I think I just feel like there's no reason for WCH to have done what they've done. And I just really hope that they, they're rewarded for it.

Dave Jones: Yeah. Yeah. I mean, we're, we're basically a commercial for like market systems at work right now. They're like capitalism. Reward the winners.

Chris Gammell: But yeah, I mean that, yeah, sure. Going back, I guess just to finish the USB discussion. So idea was get this, this, this USB stack up and running. And the idea is like, it's just, it's an interrupt that gets fired when the host sends a message to the device. And, and you just look at each one of the bits, each one it's 1.5 megabaud for USB low speed. And so every, you know, 0.66 microseconds later, you do another check, you do another check, you do another check and you go read a message. And then I do all that in assembly. And then I kick the message out to C, and then I process the USB packet in C, and then I go send a response back to the host in assembly. This has kind of been done before with Granium, but Granium, there was a lot of compromises like Granium never checked CRCs. They just assumed everything was fine. Granium never. I'm trying to remember what was some of the other things that they did that was just rough. Like the, it was never the right answer. It was just sort of like theirs was an experiment to see what is the minimum possible thing you can do and get a USB device to enumerate. And Granium is for 48 megahertz ARM zeros, like the really tiny micros that, that have no USB five, but you know, they're really cheap. And so for me, it was like, no, my, my, my, my flag in the sand, like the thing I'm going for is it's going to compute the polynomial for the CRC in line while it's receiving the messages. It's going to compute all of the stuff surrounding like the packet type and stuff like that. Like as it's going, it's going to do all of these things like as it's going so that like there's this funny thing that happens with things like a, like loofah and tiny USB where when they get a message that says, Hey, the host says it wants data. Their first response is always to knack it and say like, Nope, I don't have the data ready. Then they'll go and they'll have a user space, like, like, like let the user code figure out what to put there. And they'll be like, okay, I'm ready. Here's your data. And so I was like, no, I don't want to do that. I want to just, when, when the host says, give me the data, I want to have the data for it. And so I sort of like made sure that from the get go, all of those pieces were already designed into the low, the, the low end stack.

Dave Jones: Interesting.

Chris Gammell: And also like having to do things like retiming, which is where you like when the USB packet is sent from the host, well, maybe, maybe the processor was doing something that was time critical in that time. And now we started in the middle of a USB preamble and like having to resync ourselves to it. So all of those aspects, making sure that I handled all of that. So I, my goal is make a really robust USB low speed stack that can run on the device and then build the other part on top of it. And so the, the idea is for the normal stack, what I want to do is just make it so it's not space constrained. And so you can have whatever features you really want. And it is low speed. So you can't be like a USB MIDI device or something like that, but you can be a lot of fairly interesting things. And hit devices are way more interesting. I think people give them credit for because on windows and Linux and all platforms that I'm aware of, you can just as a user space application, be like, Hey, open this, this, this hid device. Oh, send this message. And it's not like, so with, with like serial and serial protocols, you have to have like framing where you're like, well, this is the start bite. This is the end bite. This is how I know how big it is. USB provides all of that for you. And the idea would be just make it so that the baseline is a USB fi. So that's the assembly file. And then all of the rest of the stack that gets built on top of it can have a variety of different uses and could be like keyboards, joysticks, just generic, whatever other input devices or, or egress devices. And yeah, sorry. I think that that kind of covers. That's great.

Dave Jones: No, that's bigger picture. Yeah. What, what about in the physical, in the physical realm? Cause like, so USB is differential, correct? Yes. Do you have to do something external? And then like, how do you configure the GPIOs that you're going into? Because like most USB has specialized transceivers and then actual like hard silicon that processes buffers at the frames. Right. So what do you have to do then to modify the external piece? Nothing.

Chris Gammell: Okay. Oh, no, not nothing. You do have to have a 1.5 kilohm pull-up resistor on D minus, but other than that, nothing. Okay. Wow. Okay. The nice thing about USB low speed is that it's only 1.5 megabit. And if you want to be able to send a differential signal, well, you just can turn on, you know, like flip the state of the bits when you want to flip the state of the bits. And it's, it's just really, really simple stuff. So it's, it just kind of works out.

Dave Jones: By default, is it like, so the pins are set as inputs and then as part of the processing. So like you were, you're always waiting to receive a packet, whatever. And then when you receive something, you do the CRC checking that you're saying in line, and then you turn around and start sending something back. Yes. Is that at the same time, then you're also turning those into outputs? Yep. Absolutely. And then driving? Yeah.

Chris Gammell: Yep. Okay. So just switch it around, be output, and then start sending the same sort of looking thing back at the host. And just using regular GPIOs is more than sufficient.

Dave Jones: See, I think that's the thing. Like I have avoided it so hard for so long that I have no knowledge of what even is really happening there. I'm just like, well, you know, make sure the lines are, you know, controlled impedance and, you know, run up and make sure the part has D plus D minus. And you're like, yeah, then I can, I like, I hook A to B and that usually always works. But because I'm never digging down into the stack like you're doing that, I don't really have any knowledge of how to do that stuff.

Chris Gammell: It's a lot less scary than you think it is. I think a lot of people make it really scary. Like when you look at the USB standard, it's like 340 pages for the base spec. But that doesn't even really cover like HID, which is like another, I don't even know, huge amount of like, it's like a book just for HID on top of USB. It's scary. But there's websites that really try to like actually show like, no, this stuff isn't rocket science. Like there's this thing called USB in a nutshell, which is somebody's effort to just, this is everything you need to know about USB if you want to implement it from the ground up in like in silicon or in code or whatever. And they succeeded. It's like, it's something you can read in like two hours and now you can just know how to do USB. Like it's, it's kind of surprising.

Dave Jones: I think starting from that idea of like, well, like that mindset, like we were talking about earlier of like that you can implement these things. And sometimes you should implement these things. Again, I'm never starting from that. And I think that, you know, you promoting that as a, as a good, I think from a learning perspective then and also from a practical, like you can enable interesting things. This is a really, really good example of that.

Chris Gammell: Yeah. I think, I think actually going back to projects with this. So USB wasn't the only thing. The first thing I did with this was the CH32V was make a Nixie tube controller. Yes.

Dave Jones: That's what caught my eye. Yeah.

Chris Gammell: So the Nixie tube controller was a really interesting example of it because anybody in their right mind, if you need a 200 volt supply, well, you're going to use some specialized chip to do it. Or you're going to use a voltage double chain with like a, with a hex inverter or like, like something like that.

Dave Jones: Or you're going to use a part that you don't mind blowing up. So it should only be 10 cents.

Chris Gammell: Yeah. Well, okay. But, but the, the, the sort of question for me was like, well, wait a minute. I already have a CH32V here. Can it just be the switch mode controller? And the answer is like, yeah, absolutely. There's no reason it shouldn't be a switch mode controller. And it's, it's kind of funny that like, we always think about it from like a, an engineering design standpoint of like, oh, well, if I need an X, then I'll go buy an X and put it in. If I need a Y, I'll buy a Y and put it in. But the answer is like, you just don't need it. Like you can just code that sort of stuff directly into the processor. And it's, well, it's surprisingly okay.

Dave Jones: You, you can, you can code it. And I, I need to say, it'd be a little longer for me, you know, like, yes. Given enough time and YouTube videos, I could do it.

Chris Gammell: But I mean, if, if you think about it from like, go to first principles of a switch mode. I mean, no, just, just, okay. I'll go for it right now. I never go there, CN. Okay. Let's do it. Okay. You want to be able to make, like, let's just instead say we're doing a buck. So, sure. You know, you have a P channel, you have your, your 3.3 volt rail, and you want to be able to make a signal on the output, like, like half the voltage or something. I don't know what you're going for. Sure. So, you have a PFET and an inductor. You just look up a schematic of like a buck converter, and it's like, everyone's going to just show you this is how it's done with a FET. And so, like, now I want to be able to control that. Well, how do you control that? Well, you just use a PWM. Well, how do you use a PWM? Well, I have an example. Not me. It was somebody else who's written it. Several, several people have come together and written a mountain of examples. I think we're up to like 35 examples of like how to use the CH32V003 and other hardware surrounding it. Everything from how does it become like a I squared C slave to an I squared C master to SPI DMA. Oh, by the way, that's the other thing. It has DMA like for 10 cents. Like what the heck? That's pretty great.

Dave Jones: Yeah.

Chris Gammell: And the idea is, so you want to be able to control this. So you have a PWM and you need some way of looking at the voltage on the output. Well, we also have an ADC. And so the idea is like, well, we'll just run the ADC. And if the voltage is too high, well, we decrease the PWM. And if the voltage is too low, we increase the PWM. Oh, wait, that actually just blew the thing up. It like locked up high. Oh, it's because we got the PWM backwards. Okay. So like, well, let's go flip the PWM around. Okay. Well, now, now, now it's, now it works. Like it's, it's surprising. It fucking works, right? It's, it's one of those things where it's like, this shouldn't work. This shouldn't work. This seems really hard. But then when you just do it, it, I don't know. I guess I've just been surprised by the number of times things have like, yeah, like, like the first time you do it, it never works. The second time you do it. Okay. Maybe it'll work somewhat, but like after you get through, like if you, I don't know, I probably for that Nixie 2 project, I had to compile the project. Like 500 times. But like, that sounds crazy. Like, oh, I had to do 500 times like iterations to make this work. But like when it takes you less than a second to compile and build and, you know, flush out the project. That's like, I don't know. How long did I spend on it? What's 500 seconds worth of time? Like, it's, it's just silly. Like you can just, I don't know how to explain.

Dave Jones: Like, just if you, if you break things down to first principles. It feels like it really enables you. You're, you're, you feel that this is a, this is a multi-tool. Yeah. To end multi-tools of sorts. Yeah. Right. It's, yeah. Yeah.

Chris Gammell: And it's, it's one of those things where it's like, in a way that before I don't think there is very many things that would have made a lot of sense there. Like a, like for instance, like you need an IO expander. Well, yeah, it's going to take you a couple of minutes to go write a GPIO expander, like slave thing for this price for C.

Speaker ?: Yeah.

Dave Jones: It pins, right? Yeah.

Chris Gammell: Yep. But, oh, by the way, actually, I think somebody else has already written one. I don't remember what the repo is for, but like, I think it already exists. But like, you have that now. And so now it's like, instead of spending 70 cents for the IO expander, it's, it's 10 cents. Oh man. So like. That's, that's cheap.

Dave Jones: I think I have seen some, some of those TI ones are real expensive. Well, yeah, yeah. I don't know if I would ever buy one of them. They're, they're too rich for my blood, but. Yeah. So now this is an interesting, like this sets us up into an interesting space because the first thing that I think when you start talking about this is like, yeah, I could put this in, you know, screw you chip shortages. I can, I don't need your, I don't need your, I don't need your, I don't need your TI switch mode power supply thingies. I can do it myself. And then my brain goes, Oh, wait a second. What if I can't get these parts? So, you know, it's like always a really scary question. Yeah. Yeah. I, I, I live, I live in fear given the past three years, I live in fear of all things shortages, but.

Chris Gammell: I mean, I would say I've gone through this, this mental gymnastics myself, and I would say the chances of this becoming unavailable, which by the way, I don't think we're really in the chip shortage anymore. In general, most things are available now. No, we've totally exited. We have exited. But even when it was like, would you rather have to get 30 different chips from 30 different suppliers? Right. That's an interesting point. In order for your product to be done.

Dave Jones: Yeah. Yeah.

Chris Gammell: Or would you rather just get one chip from one supplier and. Well, yeah. And low cost too. Yeah.

Dave Jones: Like probably lower cost than a lot of the silicon that's out there.

Chris Gammell: That's, that's true. But sort of like the risk is. It's like, I don't know how to articulate this being on a product where I had to like sort of, I was never responsible directly for actually getting the stuff, thankfully, but like being aware of and trying to be like, okay, well, if we can't get this one random switch mode thing, like I have been on LCSC before and going like literally just go to like DC, DC converters and clicking on every single data sheet down the list, just like click, click, click, click, click, click, click, click, click, click, click, click. And then tabs open. Finding, okay, well, which one has the same footprint? Is there any way we can use, you know, this chip instead of the chip that is now 52 weeks

Dave Jones: out, which, which insanity should we really choose here? Right.

Chris Gammell: Because they're just different flavors, right? Exactly. Yeah. So it's, I, you know, it's like, yes, it's a risk, you know, I mean, WCH has been around for, I don't even know, like 10 plus years. So they're probably not going to go anywhere, but even if they do, like, you know, it's, it's, they're all risks.

Dave Jones: Yeah. The only way to really do it is to build our own fab and design our own silicon. No risk there. Yeah.

Chris Gammell: I mean, there are some people in my discord server who are, I think are right there, but that's not me. Yeah. That's not me.

Dave Jones: Matt Venn is servicing that crowd with the, uh, with his online course. Oh, yeah. That's great. So, uh, we were on the Nixie tube thing. So what is, what is the opposite? So you built a 200 volt supply using a boost. I assume. Uh, we'll fly back. Fly back. Oh, fly. Yeah. Yeah.

Chris Gammell: The fun thing there is turns out I was just browsing LCSC one day, which I just do. It's like, I don't know. Some guys browse home Depot. I browse LCSC. And I came across this bizarre 10 to one transformer that in a 2.5 by 3.2 millimeter package. And just like, what in the world is this thing for? And, uh, I, at some point it's like Nixie tubes. And so I, I started talking to this guy spirit on my discord server who I knew had like some experience with it. And it was like, like, it was like, oh, this is actually tractable. This is actually doable. And so, yeah, like, like literally the entire, entire high voltage circuit is a CH32V003 using one of its GPIOs for feedback and one of its GPIOs for controlling a MOSFET. No MOSFET driver. Forget that. We just have a go and straight into a MOSFET. Really? Oh, wow. It's got enough drive current. Oh, plenty. It's got 50 milliamps of drive current. 50. Oh, wow. Okay. It's, it's pretty intense. Yeah. And the MOSFET, I do have a MOSFET cause I don't want to, I'm not completely insane. And then you just, just the idea is you use one leg of the transformer and pretend it's an inductor. So you like clamp it to ground. The other side is hooked up to five volts, charges up, and then you let go of that one side and it flips up. And then the second side now has 10 times that voltage on it. So you just go dump that through a diode into a capacitor. And that's, that's it.

Dave Jones: And the idea is you do a opto. Cause I know like flybacks sometimes have optos.

Chris Gammell: Absolutely. No opto. No opto. Because we don't need isolation. I'm not using the flyback for isolation. Cause I still like the idea is like, I still need to turn on and off all of the, the cathodes on the, uh, on the, the, on the tube. So there's no benefit from, from having any of the, the isolation. I only have the transformer here as, as a mechanism of getting higher voltage. So it's like, that's it. It's just the CH32V, a MOSFET and then the weird funky 30 cent transformer, a diode and a capacitor. And that's.

Dave Jones: Do you do a divider though, to get that voltage back down? Oh yeah.

Chris Gammell: I guess that is fair. I do. I do actually have a.

Dave Jones: That's, that's the thing I was really. Yeah. That's what I was asking about. Is it the divider?

Chris Gammell: Yeah. Opto.

Dave Jones: It's usually opto or divider or opto. That's true. Yeah. Yeah. Yeah. Yeah. Okay. That's. That's pretty cool. I mean, that's really, that's awesome. And then, so then the rest of the part though is controlling the rest of the tubes.

Chris Gammell: Yes. Yeah.

Dave Jones: And the parts of the tube.

Chris Gammell: Yeah. And it, it kind of handles like some of the fading between the segments and stuff like, cause you can't have multiple segments on at once. You have to like actually like chop it. And just, and it also is kind of the protocol engine so that you can go like command the, the tubes do something. And it, it handles taking on that command and doing the right thing. Hmm.

Dave Jones: So what can't we do with this part or really any, I mean, we're saying, we're talking about this part, but we're really saying microcontrollers, I guess. Yeah. What can't you do? Where do you find yourself being like, I got to go on LCSC and buy the specialized part. Silicon, I guess.

Chris Gammell: So I, I, I struggle with this question because I'll tell you the places, I'll tell you the things that immediately jumped to my mind and I'll tell you why that that's irrelevant. Cut, cut, cut is how we operate here. Battery charger. But this chip a hundred percent could be a battery charger charge control system. I'm just, I am personally a little bit too anxious to do it at this time. I still would buy a battery charge system. Sure. But totally no reason to do so. It could totally do it on its own.

Dave Jones: Yeah.

Chris Gammell: I would say ethernet controller, but on the other hand, who knows, maybe in a couple of months, somebody else is going to come out with a bit bang ethernet stack. I would say, uh, I mean, it honestly, it is a pain that like the USB, when you do low speed bit bang USB, it really is painful because it means that while you're sending and receiving frames, you can't be doing other stuff, which is, that's annoying. Yeah. I would say. So what we really need is we need WCH to come out with a 20 cent dual core. Oh, they are. Well, not dual core, but they came out with the O3.5, which does have USB built in. Oh, really? Oh, interesting. Okay. But that one's still kind of in its, I'm still kind of eyeing it. It's, it's not really clear how much it's, we don't know really. They haven't really, it's, it's like nominally 70 cents for some reason, but it's probably more like 40 cents, but that's still four times 10 cents.

Dave Jones: Yeah. Put two of them down on the board. I mean, that, that's another thing is like a multiplicative effect. You can just drop. I mean, aside from the hassle of programming multiple chips, then you could just drop another one on the board and one could be a USB and you could make a dual core quote unquote, by just having us. Yeah. You are between them or something, you know?

Chris Gammell: Well, actually it's funny. You'd say that one of the, one of the, the key features, this is, I think what, what sort of sealed the deal for me. Like I know where the six months of my next six months of my life are going with this was the, the, the debug interface for it. The, uh, it has a single wire you hook up and you go send it a special signature. Anytime you want to enable the debug part of the chip. Now the debug part is, is open for business. And now you can send and receive messages arbitrarily to that. You get to write into these two 32 bit registers, not anywhere in memory. You are limited to these two 32 bit registers, but you can ferry data through those two 32 bit registers and it doesn't, there's no like interrupt that happens. It doesn't like, I mean, it can, if you want, you can interrupt the code, but you don't have to, it can happen totally asynchronously. You can also then halt the processor and run debugging on it. You can go reflash it. You can do any of these things through that single wire. And so like, for instance, the Nixie tube thing, all of the demos that I did using that, I didn't use a, you are to talk to it. I just use that, that debug pin because it's like, it's really convenient. It's one wire and you just can talk bi-directionally to the part. And like, I can say, go to, you know, 180 volts. Well, what, what's your current output voltage? What's your input voltage? What's like all of these things. It's like a control interface more like a single wire control interface instead of a 50-wire. It's a single wire, it's a single wire everything.

Dave Jones: It's a skeleton key to the, to the WCH or to the CH32.

Chris Gammell: Yeah, it really is. And that's one thing that like kind of was a little annoying about the 203. So WCH has this whole line of these CH32V, V meaning RISC-V again, processors. But the 003, I think, I think is the only one that has the single wire debug interface, which is just so convenient.

Dave Jones: And so what is, you said six months, next month, six months of your life will be towards.

Chris Gammell: Oh, no, no, no. This was six months or not six months. Oh, this was like four months ago. When you were making that choice. Yes. Yes. Got it. I spent the last four months of my life, like, well, not, not my life. I have a day job, but like the last four months of every bit of time that I can spend outside of work, working on this, just because it's been, I was like, I, this is time to go, go, go. So.

Dave Jones: Interesting. Okay. So let's, we're, we're past the hour mark. What I, I, I'm hesitating to ask this question because I, I feel like I know the answer, but how would you say, so we have a wide range of people listening to the show right now. What is the first thing people should do with they want to go and get started? Using the fun, the library, which is called W sorry. The CH 32s. These years are three fun is the library, right? Yes. How do they go and get started right now and get to blink and go start doing fun things?

Chris Gammell: So on the webpage for the, the get the GitHub page for CH 30 TV, double O three fun. There's a thing where it's a link on the, the readme says getting started. You click on that and it has specific instructions on how to install the windows tool chain and use it and how to install the Linux tool chain and use it and how to install the OS X tool chain and use it. The steps should take no more than three to four minutes to do the full setup for everything and have your blink working. If you have the dev board off of, uh, Ali express, I think you have to like run a jumper to make like hook up the led. If you have one of my little, uh, CH 32 V double O three fun boards, you can just immediately program. Uh, I have a little demo that runs, uh, WS 2012, like Neo pixel like things. Uh, and I have four or six of those on the board itself. So if you just say like CD example slash WS 28, 12 B example, enter, make enter, it'll go build, flash the part and start the part. And you're have like a little glowing demo of some, yeah, some Neo pixels doing some fun stuff.

Dave Jones: That's great. Yeah. That's a great way to get to, to start too. Cause it's like having those examples there and just going through all of them as many as you can and just digging in, just figure out all the things that you can do first is great. What is, what is next? If you're willing to, uh, give a little teasers here, what do you, what do you hope to do next with this thing? So you mentioned the last six months, starting four months ago, you've got two months left on that term.

Chris Gammell: About maybe a month and a half. But, uh, the, the goal right now for me is take all of these things and make them really good. And I've been really trying to do that. So like the USB thing just isn't quite done yet. So I have to really make that a first class citizen to be able to just reflash it and make it. So the same level of how I described the ease of getting started, I want to be able to get there with, I don't even have a programmer. I just have, I just have the part. I want to be able to work with it and stuff like that. I really want to be able to get there. And I guess the second part of that is there's already people on my discord who are starting to write CH 32 V two Oh three fun or three Oh seven fun. And I really want to support them. And I really think that, I think that this is, I hope that I'm able to be some sort of like, like if nothing else, I want to be some old crusty person, like pointing in the direction of like you, we can do this. We can live in the world where it takes less than a second to compile and test our products. We can live in a world where we aren't overburdened with having to understand all these complicated libraries and everything else that goes so deep. We can just have the code that runs and makes our projects work. And I really, I think there's enough other people who are starting to glom onto this and starting to be like, okay, yeah, that actually makes sense. I like the idea of being able to just compile a program and run it on my part instead of needing mountains of libraries and code and other hidden abstractions in order to use the part. So yeah, I just continue to facilitate this.

Dave Jones: That's great. That's a really good goal. Where, where can people find you online? Where can they find the discord? How do people get in touch and watch your stuff?

Chris Gammell: I mean, I'm always available on my discord and I guess we should probably put the discord link on the GitHub. I think we'll do that. Yeah. I'll make a note to make sure that that goes there. So by the time this airs, the discord link will be on, on the GitHub. Okay. And for me, I'll continue to put all of the projects that I'm working on up on GitHub and all the public projects. And I will continue to make YouTube videos about the other interesting bits that I run into along the way.

Dave Jones: All right. Like, and subscribe. Thank you, CN, for being on the show. I really appreciate it. This has been fascinating. I have no excuse now, I think. So I got to go, I got to go blink some LEDs and get some stuff going on this part. So thanks for, thanks for all the work you've done.

Chris Gammell: You'll be one of the early ones. So let me know if there's any problems. So the next person will not have the same problem you had.

Dave Jones: All right.

Chris Gammell: Thanks for being here. Okay. Have a great day.

Speaker ?: Bye. Thank you.