Welcome back to the factory. A couple of weeks ago, we were doing a little bit of on-the-bench prototyping using an AVR and some GlowBits to make like a smart PiicoDev module prototype. And this is the progress that we've made on it.

   This is where we're starting. I have a PiicoDev standard outline module with three GlowBit LEDs on it and a AtTiny down here in the corner. This empty pad here is provisioned for a dip switch. We'll get to that later. But for now, let's take a look at the schematic.

If you've taken a look at any of our open-source schematics already, this will look pretty similar. We've got the PiicoDev connectors, the power LED, some pull-up resistors. But this is really where the meat of the project is. We've got a AtTiny, in this case an 806, connected to some dip switches. That's ostensibly for some address setting, but I have some further thoughts on that to come. And then here we just have a digital pin connected to a string of three GlowBit LEDs.

So this looks and feels pretty similar to where we left off in the previous video about this topic, where we just had an AtTiny connected to a couple of addressable LEDs. Now, this module, we could proceed using this module as it is now, but I think there's probably a few tweaks that we can make in the design just to make it a bit more friendly for both makers and educators.

Returning to the render, this footprint for a four-way dip switch or a four-pole dip switch, that would allow selecting between about 16 addresses. And that's probably a bit excessive for most educational and maker projects. Maybe selecting across, say, eight addresses might be better. That might save a bit of space on the dip switch. And so it got us thinking, what if this wereJust a two-pole dip switch and the third connection was done with a solder jumper? So this is what we have currently, and I'll just pseudo out what I'm thinking.

If we bring in a solder jumper and a two-pole dip switch, we could have something that looks like this, where we have three bits. So we have eight addresses that are selectable, most of which, half of which, the first four are really easy to reconfigure. You know, you just got two dip switches, very simple to move those around.

And by taking the third bit and putting it as a solder jumper on the board, we can maybe put that on the back side of the board and make it look a bit more like a four-pole dip switch. We can maybe put that on the backside of the board and save a bit of space on the front side, maybe reduce the cost of the part so that can get passed on to the customer. There might be something in that. So I'm gonna explore this new configuration.

I figured that those two switches should give you enough entropy to get a lot of devices on the board without soldering, and then to unlock that second tier of address space. You know, it's just a solder jumper. So it's just one solder jumper required rather than double the amount of addresses available. I think that's probably a good compromise for most use cases.

Now, of course, this means that you've got an address space that's only, you know, eight unique addresses when using these dip switches. That's not to say that we couldn't roll in some kind of soft address programming. So maybe there's an I2C command that we implement in the command set that allows you to write a new address to the device that's saved in the EEPROM. That would probably be worth exploring as like a nice-to-have, you know, thatLast 20% in the 8020. But I think this is a great place to start. So let's see what that will look like.

And you know, with that change, and maybe if we push the switch over to the side, we might just jag it so we can squeeze another LED in. That'd be pretty cool. I'm not gonna lose too much time on that for now, though I'm more just exploring this idea and how that might look.

And there's our third address jumper on the other side. So quite a lot of vertical space recovered for using what is a smaller, probably cheaper part. That's pretty cool.

Every PiicoDev module has a power LED. And you know, maybe it doesn't really make sense for this module to have a power LED, because it is a board full of LEDs. I mean, maybe it does because it will give you at least some sign of life, even if your code doesn't function properly. But maybe it makes sense to connect the power LED to the AtTiny. Then you get independent control over it. You can disable it using code. That could be pretty cool. Hmm, isn't feature creep a wonderful thing?

Here we have a perfectly well-solved problem, just a nice jumper to cut. I'm like, yes, maybe we can extend the command set and control it using I2C commands. What do you think?

Here's our programming header. This is a five pin surface mount connection. It's just on the backside of the board, kind of like a bunch of small test points. And the AtTiny is a UPDI device, which means that it's programmed using just one pin, this UPDI connection that just goes straight into the chip. The rest of the header is just for power ground and data and clock.

The point here is that we wanna take the PiicoDev module and sit it into a programming jig and have that jig flush the hex file and then run the test for.That device in the same place. So we just have one jig that's a program and test for a PiicoDev module. It's kind of a scary thing, like picking where is this header gonna go? Because if you get it right, it means that it can just stay there forever and you use the same jig for all your stuff. And if you get it wrong, now you've got a second jig and maybe a third as this header needs to move around. So I don't know, it feels like a big decision, but you've got to start somewhere.

I think it makes sense to just put the thing underneath one of the connectors. Because look, you've got one, two, three, four connections out of five, just right there. You don't have to do any funny routing. You probably, of course they all need a via, but that's not a big deal, especially when all the lengths are so short, you're not having to bring your header out to some weird part of the board and include all this extra routing that would otherwise be unneeded. So I think this makes a lot of sense. I just hope it doesn't come back to bite me later.

Now I'm very curious about this PyP project, the PyMCUprog or Python MCU programmer. It looks like this is a set of Python tools that you can use to program AVR, MCUs, or now any microcontroller made by Microchip slash Atmel. Why this is really interesting is because during production, wouldn't it be nice to just have say a Raspberry Pi with some kind of HAT on it, and that was your programming and test jig. You hold it on, does the flashing, does the test, you get a pass, off you go. This seems like it might be the way forward. The thing that I need to investigate is whether it can program without any additional hardware. It looks like it might be able to.

A precursor to that project is this.PyUDPI project, and it looks like it's well provisioned for exactly that. In this little diagram, we have a serial port with TX and RX connections, a 1K resistor, and the UDPI pin of an AVR. I've also seen schematics where this could be a diode as well. That might be the better way to do it, but in any case, I'm quite hopeful that we'll be able to put together some kind of custom HAT that will be our universal programming and test HAT for these PiicoDev devices.

Something pretty similar to this idea already exists in the wild. Looks like SparkFun has been making use of this kind of idea for a long, long time, but this is the Raspberry Pi standalone programmer, and it looks like it's a replacement for the six-pin AVR-ICSP programmer, and we can take a few cues from this. There's a lot of good knowledge baked into this.

It looks like they probably use just one per project, given that they've got the product name label on the hat, but this is great here. They've got a tap to program instead of a mechanical button. That's pretty cool for a dedicated programmer because you're not wearing out a button. They've got a rolling status light with pass-fail for fuse bits, flash, lock bits, and then the serial upload. Looks like there's some logic-level conversion happening. This is great.

There's a few design cues that we can take from this, although it's not quite a complete solution for what I would like to do. I mean, the ideal programmer would be just like in every programmer. Maybe the Pi connects to the network, grabs the appropriate hex file that you can select from like an LCD display. That's the dream. Something like this might be a little more realistic, but a man can dream.

You know, my concerns with jigging beforeWere that if that header were to ever move, I guess you could have your master programming HAT for the Raspberry Pi, and then like a daughterboard that goes on top, and that has the jigging required for the specific PiicoDev module.

So if you happen to make a different design, then you can have a separate daughterboard that goes on for that design. And you're not doing retooling on your major piece of work, which is that hat, its pinout, and its supporting circuitry. You're just basically doing the connector that goes into the PiicoDev module.

In any case, that's the progress that's been made on this smart line of PiicoDev modules, I guess you'd call them. I'd love to hear your thoughts on some of these ideas, whether you've used Raspberry Pi like this before, whether you've used any of those tools like PiMCU PROD, and just if there's any features that I might be missing or that you might like to see in PiicoDev modules like this.

Until next time, thanks for watching.