Welcome back to the factory. In this week's episode, the PiicoDev Unified Library gets a nice quality of life upgrade for more advanced users, and we design another jig. Let's get started.

First up, I'm happy to announce there's a little bit of an overhaul happening to the PiicoDev Unified Libraries. A couple of months ago, a user by the name of Random Smith made the first pull request to the Unified Library repo, bringing quite a lot of extensibility. We've been developing PiicoDev for like educators and beginner makers. So a lot of the functionality is quite baked.

The I2C bus, for example, was locked down to whatever the default was that we chose. In general, that's I2C0 for the Raspberry Pi Pico and the Micro:bit and I2C1 for the Raspberry Pi. A lot of devices have more than one I2C bus and Random Smith brought in a really nice pull request that would allow selecting between I2C buses and even changing the speed. That's a really big deal because a lot of devices say this IMU, this is only selectable between two addresses. So the fastest easiest way to get more than two of these devices into your project is to just put the third on a separate I2C bus. Easy.

And Random Smith's contribution brings with it also a lot of structure, very extensible structuring, which is really appreciated. There's this thing called the I2C base class, and that basically just predefines a structure which is then inherited by other classes like I2C unified machine. So this would be the I2C class for micropath and devices that use the machine library. And then this would work with all those devices. There's another class for micro bit. So it's a real improvement on the existing PiicoDev structure because it really clearly defines those barriers.The existing PiicoDev unified library kind of branches within the backend functions. I really like this implementation. So if you're watching Random Smith, thank you so much for your contribution. PiicoDev is better for it. And I'm sure for rolling these changes into PiicoDev as it is now, Peter and I are both better programmers for it. Thanks again.

Moving along to the prototyping section, we were discussing the PiicoDev RGB LED prototype last week, the addressable RGB LEDs, and we took your feedback on board. This is what we have sent off to the PCB fab house. I've reverted back to three LEDs because it's a, I feel like that's a very natural number. Could have squeezed four LEDs on, but it was quite disruptive. We lose out on nice placement of the address dip switch. And also it interferes with the logo. Of course the logo can go on the back, but I think three, three is like, it's a, it's a pretty sweet spot. The back looks very much the same as it did before. The LEDs are now centered. Uh, I guess they're, they're aligned vertically and they're centered horizontally. So the design is a lot more balanced than the, the very early version that was pretty top heavy.

Uh, now my thoughts on the programming header, you may remember from last week, I mentioned this programming header. This may, this may not have to actually be five pins. See, we, we have to program this thing and test it regardless. And to test it, to do an honest to goodness test, we really do need to test both of those JST connectors on either end. Cause you have to make sure that the connectors are working. So if our test jig is going to be testing into those connectors, then it's probably not necessary to have those connections broken out on this programming.Header. In fact, this programming header could just be a single pin for UPDI. If the programming jig is also the test jig, then the power ground and two I2C signals, they're taken care of by the JST connector, which leaves just that one pin, the UPDI programming pin on that's that surface mount test point.

Just going to show you the PCB, just as a reminder, we have the JST connector on the top side of the board. And on the bottom we have the programming header. And you can see that the programming header four out of five pins are just the same connections as that JST connector. If we need to use that JST connector for the testing phase, then we could get rid of these four pins on the programming header, which leaves it just this one pin. And I guess that could, I could just stay exactly where it is. Maybe we could move it somewhere more convenient.

This is still in the, this, this design is still in the prototyping phase, but maybe, maybe I should just leave at least at the very least pin number one here, exactly where it is. We could leave these test points in provisionally. That might be a good idea. They don't, they tread pretty lightly on the design.

In any case, as you see it now, this is the prototype that we have coming in and when it arrives, we're going to need to program it. So we're going to have to make a jig. So I've been working on an idea just, just in the last 20 minutes yesterday that I'm going to flesh out now.

This is what I'm thinking. I've got this stack up of acrylic and that's going to hold a PiicoDev connector. And then I've made this, it's kind of like a saddle clamp, I guess you'd call it, um, that goes over that wire and secures it. And this actually, this remains pretty robust.I do a similar thing to test PiicoDev modules. Now, it's just like using hot glue through a circuit board, really in one of the old jigs. Maybe I can bring that up. But this is, this is the stack up that I've got for now.

And the idea is if the PiicoDev module can slide in and mate with that connector, this, this geometry is kind of fouling it at the moment. So that's what I'm going to work on now. If this can slide in, plug in and, and remain flat on this bottom board in this channel, we could have a sliding mechanism to plug into the other side of the PiicoDev module that would hold it flat onto the base.

And on the base we can have that single UPDI pin coming up and just touching the bottom of the PiicoDev module. So what good timing it is that PiicoDev is just now getting an upgrade to work on two I2C buses. Maybe you can see where this is going. We want to test that both connectors are working. And so it makes most sense to do that by using two separate I2C buses, because then you can guarantee that you're only testing one connector instead of both at the same time on the same bus.

Maybe this isn't very clear right now, but I'm going to work on it a little bit more and hopefully get something that works a little bit better. So here's what I'm thinking. I have this base plate with some fastener holes. This one can come on and this guy does the jigging. So this is where PiicoDev module will sit. And this is where the one of the connectors will be.

So then we have this saddle clamp and that's been engraved just deep enough to really have like a positive clamping action on the cable. Even with one fastener and that's not going anywhere. This will get loaded in, press down. And then on this side we haveA sliding carriage is used in this setup. It can be glued shut or have fasteners to secure it. On one side, there is a pogo pin for programming that connects to the programming header on the other side of the board. To lock everything in place and test the other connector, a slide-in mechanism is used from the right-hand side. The programming sequence runs with the UPDI programming pin doing most of the work. Power and ground are supplied through the connections, with one side being on I²C 0 and the other side on I²C 1. Once the device is programmed and passes, the connector can be pulled out and the jig can move on to the next one. The process is repeated by sliding the new module onto the connector and closing it.

It is expected that some parts of the jig will wear out over time. The connectors may get strained. The existing jig, which has hot glued connectors through FR4, has been used for thousands of PiicoDev modules without needing to replace the leads yet. If the part on the left wears out, it is relatively easy to undo the saddle clamp and replace the lead as it is a replaceable part. Similarly, if the assembly on the right is glued together, in its final form it may look different, but a batch of components can be laser cut and acrylic glued together with the leads. The current prototype is just for testing these ideas and the final jig would not look exactly like this.Be a little bit bigger, have more fixturing points, have maybe like a guide stop to stop this like sliding out the back. This is just to, to test the idea of this sliding carriage and this kind of jigging experience, just like bringing this board in and connecting it on, on one side.

This seems pretty promising. What do you think? That's one of the things I love about the laser cutter is that you can really rapidly prototype little designs like this really accurately that you can, you can just rely on the width of that laser to create the sliding fit between two parts. So if you want a part to slide inside another part, you can just cut them out in the same stroke. And the, the, the curve of that laser is, is kind of perfect for, for that purpose.

So I'm going to spend a little more time working on this, getting it into something that could actually be put on a jig. Like I said before, this is just a proof of concept for the mechanical idea of how we might fixture a device under test. But what remains to be developed is like locking this down so it doesn't want to fall out and just putting in the hole for the UPDI programming pin.

With any luck, this jig will be finished by the time the prototype PCBs arrive for the RGB LED module. So we'll be able to put it to use straight away for just doing the actual programming and firmware development.

That's all I've got for you this week. Thanks for joining me. If you have any thoughts on how this jig could be improved, or if you just want to see something a little bit closer, let us know on the Core Electronics forums. Thanks for watching.