Welcome back to another episode of The Factory! We are continuing our "Design a Product with Us" mini series, where we are designing a PiicoDev Servo Driver. In the last episode, we labored out a "Hello World" example from this little hardware prototype, which is an Adafruit breakout board that has the same chip that we want to use. We were able to see some signs of life from the servo driven over I2C at the end of that episode.

I mentioned we had a forum topic live where we were going to seek some of your assistance in designing this product. In this forum topic, which I've linked in the description for this video as well, we explore a couple of hardware ideas for how we might execute this module. Specifically, how to handle the high-power connections. servos are quite happy to draw in excess of an amp when holding torque, and the little PiicoDev cables that we use for our small signals and low-power modules, they're probably not going to cut it for you know upwards of two or three servos.

So, a very important first up before designing this hardware is to take a look at this feedback and decide on the apology of this module. How we're going to deliver power to it in an easy to understand, cost-effective, and kind of sustainable way. Like, we don't want to have to introduce lots and lots of adapters, etc. Let's get to it!

We're on the farm topic and this is idea one, where we're using USB-C just for power. So, in this use case, we have our I2C daisy chaining. We can daisy-chain through a servo driver, through another servo driver, and then continue with more small PiicoDev modules, more low-power modules. This idea works because we have external power coming in in this case with the USB-C connector, and power is daisy-chained separately. three volts on the data pins and then we can use the data pins for our PiicoDev bus

We have two PiicoDev connectors on each driver and two USB C connectors on each driver. This allows us to daisy-chain power off to another module if necessary. This servo driver should be able to take care of most makers needs in the first place. To get a second Servo driver, you're probably talking about some pretty serious projects.

We have two interconnects between each module, one of them being a USB C cable which is not as bendy as the tiny PiicoDev cables, but is a simple idea and easy to understand. There are two ideas: daisy-chain PiicoDev and daisy-chain USB C.

The second idea is USB C for everything. This looks similar to idea number one, except there is no second cable daisy-chaining the PiicoDev modules. We have USB C delivering power, our PiicoDev bus, and they are combined into a single cable that goes between Servo drivers. This USB C cable could potentially carry the R2C signals, the three volt power, and the high-power 5 volt power for these high-power accessories.

Once we get back to the end of our run, we can fan out and just bring out a normal PiicoDev bus. This was my pet idea and we'll see why it might not work. James came in with a very helpful post that got me excited for this USB C for everything. The debug accessory mode that's available for USB C means that you can basically say that all the data pins are for test purposes only and so a host device like a computer will just not interact with those pins. This means that we could potentially squeeze 5 volts on V Bus, three volts on the data pins, and then use the data pins for our PiicoDev bus.

The I2C bus in these test pins as well as the 3.3 volt power because it's low power, this is starting to feel a little bit risky though. Like, could we introduce damage to other people's devices? This debug accessory mode it feels like it's more of a production test, a production environment test than it is to be released into the wild type application. Honestly, you guys hated idea two too, I don't think anyone in the forum was in support of idea number two.

Which brings us to idea three, which is still a very easy to understand idea. I think we have the servo driver, we have some higher current interconnect, so not this normal standard PiicoDev cable but some beefier, maybe JST type like a JST XH and of course that would need all the conductors, you did 3.3 volt, 5 volt, the I2C bus, the ground. So this would be like a deviation from what is normal for picadev, which is why I kind of hate this idea, but we have to consider it. We have to consider that it's very easy to bring in an adapter and adapt to this. It just means that if we want to have small modules coming off the other end, we need a second adapter to kind of convert this large connector back to the small PiicoDev connector.

While there is while this is very easy to understand, there's probably more burden with this idea than with idea one. And just to reiterate, even though we're starting PCB design today, it's not too late to get your ideas in on this forum because we're just doing some prototyping, we're just seeing how various ideas feel, whether we can even fit a design onto a two unit PiicoDev module. So get in there and let us know your thoughts. So this James, the votes for idea one but with an alternative power option for the USBC connector. Idea two introduces some problems due to non-standard use of USBC pins. I agree.

As much as I love the idea, I agree it's probably too high risk and having power go over those data lines is probably just asking for trouble in the wild. Right, idea three is idea one but on a separate board. Yes, it is with the intention being that the adapting burden is worn once and not on every single board. Maybe a D3 is idea one but on a separate board it is. It's actually probably worse than idea one because you need additional hardware at the in and the out point. Jeremy also votes idea one, James votes idea one a lot more support for idea one than any other idea.

Okay, so until further notice we're going to proceed with idea one for now. Of course, everything is subject to change, this is just a prototype. We're going to see if we can even fit it on the board but I think we might as well get cracking because small changes like are swapping one connector for another and not a big deal if we decide we don't like that user experience.

Okay, so here I'm putting down the I2C device, this is the PWM driver and connecting up the I2C bus, that's the SCL and SDA lines just referring to the data sheet for some typical application information. Now we're putting down the servo headers for the servo channels and there's a little bit of a bug on the screen here right now but we pick it up later, don't worry about that.

If you've noticed, we set the addresses all to zero for now and I'm just putting the part on the PCB just to get a look at whether it's going to fit. So, I'll probably just drop down a resistor and connect that to ground and 10K sounds pretty good for that. We're already. have a clean bill of health

Using 10K elsewhere in the circuit for both the pull up resistors and the LED resistor is pretty crazy; you don't see this very much where you drive an LED with 10K, but the LEDs we use are insanely efficient so that's good. Part reuse, just having a look at these connections here if there's anything that we need to do to signal that we want power, but it looks like with USB C it's just the downstream facing Port that advertises how much power it can provide and that is done using these RP and RD resistors.

Since this is the device it's not the current Source, I think we are just right to proceed with this very basic setup and stretch goal we'll see if we can add some breakouts. I want a one by two on each and that'll just be good for prototyping, debugging, etc.

It's a good idea to run the ERC (Electrical Rules Check) - that's this button in KeyCad - and when we run this, oh boy do we get a lot of Errors, usually administrative stuff like power ports etc. For example, every single one of these pins I'm getting spanked for because it is left unconnected. So, we will intentionally leave a non-connect flag there; you can do that quickly with the QK, re-run and we're down to much fewer errors. I haven't annotated my schematic of course, so I'll ignore these duplicate items.

This is an interesting one; you'll probably always see this. This is when you have an input Power Pin not driven by any other pin, so that's referring to this 5 volt here. That's a bit of a metadata hack to fix that; here you need to attach your power net to a power flag. So, if I take that 5 volt and I just grab a power flag, what we're doing is we're just indicating that there is power coming from somewhere. When I run the ERC again, that error is removed and we basically have a clean bill of health.

Have aside from this one, we have only annotation errors, so I'll annotate my schematic now. Fully annotate, run the ERC, and we have no errors. That's always a good place to start because hey, you could have misclicked and you could have thought you made a connection where there is none. And when you get your PCB delivered, there's just a trace that doesn't exist because you never designed it in the schematic. And so when you get to the board layout, you don't see the rat nest that you're meant to connect. So a good PCB starts with a good ERC and we are ready to assign some footprints.

It's nice that with a lot of the built-in components for KeyCAD, there are a lot of device variants so this part already has the right stoic package associated with it. It's really just all the generic stuff that I included in the circuit that needs footprint assignments. So these con 1x3 males, I know I need a connector pin header and we do have Tiger Claws in KitKat. Oh, I thought we had Tiger Claws, maybe the naming change between KeyCAD 5 and KeyCAD 6, they just call it SMD. So I know I want a one by three with an SMD.

Of course, we need to make a decision about where pin one is, whether it's on the left or the right. It's probably safest for us in the long run, safest and most scalable for us to just make a composite footprint of the two, so that it doesn't matter if we get a pin one left or a pin one right, we just we can put any part there in case we need to change supplier or whatever. In our Core Electronics components Library, we've already done this a few times with some other connectors for other devices, notably this MegaVerse microSD adapter. We have a Target core header here and we've just doubled up on every pad so that if we can't get this exact header, we can just swap to a pin one, uh, what would be left variant.

Instead of a pin one right variant, I just put it straight on the same footprint. So, I'm going to have to make a copy of this. We can delete this and let's place the anchor right in the middle so we got nice clean rotations. That brings us back to our footprint assignment tool for electronics components one by three vertical SMD and we want to apply that to our three Servo channels. Done.

Okay, I think these, these I just want these power breakouts. I want is an unpopulated part, so that will just be a pin header on a 2.54 pitch. And lastly, we need a 10K resistor. I probably should have just copied one of the existing ones so I don't have to choose the part and that is all our parts assigned.

Oh, and now for the Moment of Truth: Is it all going to fit on the PCB? It's so often the case with PCB design that you start with a mechanical constraint and you have to fit the parts within it. As a hobbyist, you may be designing PCBs that have no size constraint and that's lovely, but constraints are good because nothing makes a decision easy like a constraint.

It's going to place these USB connectors. Oh boy. Oh yeah, I mean we got we got room we got room that's fine. But I can just say this is this is gonna be a nice size. I think three channels looks pretty good. You know we maybe we can put our put our chip down here because it really only has USB. I don't want the PWM crossing the ice squid C though, so maybe we need to snug this part up here.

But this is looking promising. Look at this, we had we've pretty much jagged it guys, ladies and gentlemen. Got some breakouts on the top. Uh, I am I am somewhat relieved about this. This is a great great reason to have a template as well. This would have taken so much longer having to do this from scratch.

Ing our resistor look.

At our CAD, it's looking appropriate. Do we have some CAD? Yeah, there we go. I'll just drop in some CAD for the other stuff, but this is looking pretty good. Three channels feels natural. Somebody did express, I think James who works in supporting Express, that four channels would just be like the perfect balance because you could imagine with four channels you could have a two-wheeled robot with a pan tilt. So let's stretch goal out for four channels. Ah, four servos , is it irresponsible to even drive four servos? Probably, but hey, got options, got real estate, got options. Just going to take this guy, Ctrl D to duplicate Servo 4, welcome to the party. Okay, how much can we cram in here? I don't know if that's gonna work. Let's take these away, maybe our orientation looks a little more like this. So now we can bring this. It's quite nice to leave it centered. I don't want to violate that pleasing visual symmetry as well. This I2C pull up header, this doesn't have to be on the front side. It's definitely in the Pro user space. Oh geez, it's getting close. Yeah, now we're running into the we're running a little too close to those USB connectors here. Maybe three is the number. It does seem a shame to have so much negative space at the bottom of the board, but these, the location of these PiicoDev connectors is almost inviolable. It's such a strong pattern that we've developed in the ecosystem that I would be extremely reluctant to move these around, not just for the visual consistency and brand integrity, but also because people are getting used to that and if we move that location, that has repercussions for mounting options that people come up with.

I'm very reluctant to move these down if I did we could recover vertical space and maybe squeeze in another Channel, but I don't know if that's necessary. Let me know in the comments what you think. I'll return to the schematic for now. We'll remove Servo 4 after all, we're already at three servos that's potential for like six amps if you're really pushing things. So maybe it's more prudent to not include the ability to just not have the option. You know it's such a fine touch, but it would be really nice to get some CAD on this board just so we can visualize things a little better.

So we're pretty much ready for routing tracks right, but one thing that gets me just about every single time is the artwork, especially for a public-facing product. Put the artwork down first, it's like the next constraint to PCB layout. You can really paint yourself into a corner and maybe I already have because I didn't do the labels for everything that's here. We're going to need labels for these power connections, we're going to need labels for these servo connections, and that artwork needs to take up some space. You can't just cram all the components together as tightly as possible unless it's like a really engineered product that's being tucked away. But this is more in the education space and so we need that really helpful self-documentation, so we need some space for the artwork and this negative space now is looking really good for things like a title. We're getting a little bit crammed up the top of the module here, maybe we bring the title down to the bottom so we can highlight the silk screen layer and press h to go into like high contrast mode. We can bring this text down.

You know this open source? Maybe it even goes on the back layer. If you could have a Servo driver, we haven't provisioned a link for that, but we will. It looks a little bit awkward with the title split from the applicative logo. It is the PiicoDev servo driver after all, that looks a lot more consistent with how we normally do things and probably just give it some room to breathe. Bringing these connectors down a bit, we don't want any references on the boards because we just don't need them, so I'm going to conceal all those references. It just makes for a much cleaner looking board.

Yes, if you're providing support it can be a little harder to refer someone to a specific component. Have you plugged into this pin on J1? Overall, we've found that this works just fine and it produces a much cleaner looking board.

Something that I absolutely love about the open source community is that we have people diligently working on incredible plugins for KeyCAD that are just making it the best free EDA or like electronics design tool available. We have this beautiful plugin to create labels called Key Buzzard, so we've been using these a lot on Makerverse products and they'll be making their way into PiicoDev as well.

When you start to put labels on things on circuit boards, you're really locking yourself down into a name. Of course, this is a prototype so it's no big deal, but this is going to affect the way that we produce the driver library for this device because you want a one-to-one relationship between what you refer to in code and what you see on the board. So choosing this text, like channel one, channel two, channel three, you're kind of committing to how your code is going to look and that's always good to be aware of. I think this feels appropriate for now.

Hot tip: You can put your fiducials under components, that way they don't take up additional board space.

Yeah, I'm just going to get routing and we'll see how far we get. Alarm bells, alarm bells, what's going on here? This shouldn't be 3.3 volts. I wonder how many people picked up on that and was screaming at me this whole time. Oh my goodness, this is the whole point of the device is to deliver 5 volts to these servos. Oh no! Ah, that was close.

You know, it occurs to me we're almost certainly going to need to provision some capacitance for these servers, both because I can see 84 did so it's clearly a good idea. But you know, we got three servers, we got sensitive electronics and we've got like transmission lines. We want some local capacitance. We already have a part on the Makerverse motor driver that I can probably reuse. I think that's about 47 microfarad. Oh yeah, thank you. Oh geez, that's large. Can't go down here, that's stupid. It's far away from everything and everything it needs to drive.

Oh no, we are maybe in a bit of trouble, maybe in a little bit of trouble. But let's sneak up on those mounting holes as much as possible, bring these down as much as possible. I don't I don't think that's going to make too much of a difference though. Oh geez, we are going to be violating some some courtyards. That's what we're up against. So, and I think that's where we'll leave it for today.

There's a little bit of work to do, maybe squeezing in that capacitor or a few smaller ones to make up a bulk capacitance to help drive those servers, drop in the tracks and we've got a prototype. Let us know how you think it's going on the Forum topic or in the comments below. We'd love to have your input. If there's anything that we can change, this is your opportunity to get that feedback in. Is that USBC can actually going to?

Going straight off to a power bank can be too much of a hassle or is it really convenient? I'll chip away at this in any case and get those traces routed and the Prototype submitted. Until next time, thanks for watching!