G'day, welcome back to the factory. Since the last video, there were a few comments on how to make the PiicoDev Glowbit module a little bit better. So this time around, we're gonna go through those, take on some of those suggestions, and see how we can improve this design. Let's get started.

First bit of feedback we have is from Oliver, and he says that moving the power LED or making it into like a soft switch, a soft-switched LED, nah, that's just a power LED. It's a power LED most of the time, but sometimes not. A power light is a debugging indicator first and foremost, and there's nothing worse than having a mysterious slash multiple possible causes for the effect you're seeing when debugging. So I guess what Ollie's trying to say is that the power LED should be just that, because that's like the most useful way for it to be used as a debugging tool. If it's on, there's power, and that's debugging step one. So yeah, totally agree with that. You're so right. I don't know what I was thinking, talking about making it something that was like user switchable. That's just opening Pandora's box of problems. If you find you've changed some setting, and now you can't figure out is your device even powered or not, just leave it as a power LED.

Jelly Nin says it would be great to have some pass-through as well for LEDs, the option to add glow bits or a longer strip. So, you know, if you have your glow bit tile with a strip of LEDs hanging off it, that would be pretty cool. I definitely thought about this. I thought it would be a cute feature as well. I've chosen not to go down that path because there's no real way to guarantee power management. Remember, the PiicoDev ecosystem is 3.3 volt only and pretty low current. At that. So I wouldn't want to introduce the capability of say drawing too much current on your PiicoDev bus by having a long strip of LEDs. It also complicates things a little, and there's also not too much space on a 25 by 25 mil PiicoDev module to include more headers.

So while I agree it would be a really nice feature, I've just put that one in the too hard basket. Jive Ben says that the daughterboard should not be on top of the classic hat, pressure stressing the HAT slash Pi pins. So I suppose what they're getting at there is if we have a test jig on top of a Raspberry Pi, then when we test on it, the HAT will cantilever on the pins, stressing the pins, maybe break them off.

But that's not a big deal because we can always put in some standoffs on the Pi's mounting holes to support that whole platform on top of the pi. So I'm not too concerned about that. RotorFluchtZwerg says that they would put a small button on the PCB instead of dip switches and implement all configuration like I2C addresses in a software within a menu. So you've got like a one button interface. I nominally agree with you. However, a real strong intention for this and other PiicoDev modules is to make them very easy for educators. And so what they're recommending is having a single button interface somewhere on the board and then like cycling through this one button interface and maybe using the onboard LEDs for feedback.

And with some amount of button pressing and combinations, you can set say the address parameter. This would work nominally and it would be quite a simple hardware fix. It would be like a fair amount of like software development to make that menu structure absolutely possible. But to service educators' needs, I'm thinking about the poor high school teacher who's got to like set a bunch of addresses for their students using this interface. And that's why I'm strongly in favour of something that you can just eyeball like from a distance and you can see that it's in the right state. Like a couple of dip switches, you can just eyeball, oh yes, switch one is on, switch zero is off, great. I know what address that's going to be. Of course, the drawback for dip switches is they're pretty big.

And that brings me to the next comment. User 2059 says, it would be good to get four RGB LEDs on the board vertically aligned. I guess that means like down the middle of the board, the dip switch could be shifted to the left, mirroring the chip. Yeah, I agree. For now, this looks, it's not great. We all know it. This is pretty odd looking with this very like top heavy three LED arrangement and then some switch down the bottom.

So it sounds like what they're suggesting is that this switch could move over to the left here and we could squeeze in a fourth LED and then everything could be nicely, evenly distributed along that center line. Let's give it a go. Start by copying out one of those LEDs. Re-annotate. Bring it into our board. Put it right there. Okay, so we've got a fourth LED in place and we need to move this. We need to move this switch over. So at the moment, it's probably not enough. Oh, it's close. We can't just put it in horizontally, but that kind of works. We could have it vertically and that would actually mean the switches were more upright. The only problem is, so here's the trade-off. It means that we would have to push this connector further up. In our render here, you can see the connector is now sitting on the pad. So we would haveTo move the PiicoDev connectors up. Not a big deal to deviate from, so by convention, we've been vertically centering these. We've been centering them across the center line of this horizontal axis. If we have to push them up to get a better experience for this one module, I think that's probably acceptable. You know, like rules are made to be broken.

Let's give it a go. It does mean that we have to move this jumper and LED arrangement though. Let's just start with the big stuff. I think that's probably fine. See, I made this dip switch footprint anyway, so this courtyard here is kind of like a best guess anyway. So that's what that would look like. You know, I think there might be something in that. There might, that definitely looks a lot more balanced. Let's even out these LEDs. Okay. We could be onto something. This does look a lot more balanced and a lot more considered.

Well, so another alternative so that I don't have to shift everything around quite so much. It just interrupts, it just collides with these I squared CLEDs. Could put the dip switch at 45-degrees. I don't know how I feel about that. Not sure if I mentioned last week, but there's also a little reset header here. So the idea being, if you short those two pads together, then you go back to whatever factory defaults is. And you know, that makes a lot of sense if you have say any programmable addresses or other settings that are like saved into EEPROM, you can always roll back to that factory default.

And over on Twitter, Bridan has said that batch programming and test jigs have been an ongoing task for them. And that because we're using an ATTiny, their Portaprog would be an easier and faster design to get going than the Raspberry Pi.

So let's take a look at what's going on with the Portaprog. So this looks like an ESP32 based portable programmer. Looking through the command set, it's set up for UPDI programming. Great, that's what our AtTiny devices are. And then it's operated over Wi-Fi. So you can issue commands to it from your computer to upload hex files to the Portaprog and then flash them to your device. It looks like the whole thing is drivable from TCP streams. Very well documented. And this looks like it is the source code repository. I can find the source files, but I don't see any files for the hardware for this expansion board that goes onto this development board. So I wonder if they're floating around somewhere.

In any case, this looks very fit for purpose. So I think it's worth a look in. So thank you everyone who commented and made some suggestions for how to make this just a little bit better. I was just slapping in a few of those changes, but now it comes the time to actually reroute the board and submit the prototype. So until next time, thanks for watching.