[Eagle vs KiCad part 6]
In the last post, I managed to get most of the parts I needed on to the schematic in KiCad. There were some problems, though.
I couldn’t find the right four-digit, seven-segment LED display. The one example in the default KiCad libraries had a different pinout to the device I’m using.
- I didn’t much like the way the 74HC595 shift register was laid out.
- And although I didn’t mention this before, I also didn’t much care for the layout of the 74LS165 shift register (and, in any case, I’m using the 74HC165).
- The layout for the connector I’m using – the DIN 41612 64P (A & C rows only) – was all kinds of wrong.
So I was going to have to make my own parts.
To be honest, by the time I made my last post live, I’d already made my own part for the connector. And that went swimmingly well (although I’ve yet to create a footprint file for it). But that early success wasn’t to last.
It’s not the parts creation that’s the problem – that’s really quite simple and occasionally even intuitive, which is something you rarely get to say about KiCad (or Eagle, to be fair). No, it was the libraries that caused me grief.
Going to the library
My first instinct with the 74HC595 was to modify the existing schematic. But then I figured, hey, I want to learn something here, so let’s start from scratch.
Now, when it comes to handling libraries in KiCad I have to confess I became very confused. You’ll see a lot of tutorials online with conflicting information.
There is a part editor that you open from within Eeschema. Some tutorials will tell you that before you can create a new part, you have to open an existing library – which you don’t. It’s true that you need to have a ‘working library’ open in the part editor, and you need to pay attention to this, as we’ll see. But you can create a new part and then save it to a new library if you so wish.
But your new library doesn’t then just appear in the library list, meaning that your new part isn’t yet available. I’d saved my library in a folder I’d created for custom libraries, but KiCad doesn’t yet know to look there. So I had to go to preferences, add a new path to the list of paths for libraries, and then add the library itself to the list of libraries being used by KiCad. It’s all a bit clumsy.
When it came to creating the new 74HC595 component, I’d already created a custom library to hold the DIN connector. So I created the part, named it 74HC595 and saved it in that custom library. Then I went to place the part – and instead of my nice new part KiCad placed the old (default) version. This is in spite of the fact that when using the component chooser, the preview clearly showed my new part. I tried saving the part to a completely new library – same problem.
I thought the problem might stem from my having given the new part the same name as the existing one (even though it’s stored in a different library). Easy – just change the name. Well, if there is a way to do that in KiCad, I haven’t discovered it. I ended up opening the .dcm and .lib files – which are both plain text files – for my custom library and modifying the name there. Just to be on the safe side, I restarted KiCad. Sure enough, the part showed up in the library browser and component selector under the new name, with the schematic preview correct. But when I actually placed the part – you guessed it, I still got the old part.
Eventually I got KiCad to play ball by removing my custom library from KiCad’s library list and then re-adding it (the EDA version of turning it off and on again).
Here’s another example. The four-digit, seven-segment LED display in the library didn’t match the unit I’m using. So I created a part from scratch, again saving it to my custom library. But when I came to place it, the version that dropped on to the schematic was – while it was definitely my part – in a part-finished state, as it was about half-way through creating it. I went back to the Part Library Editor and, sure enough, it was complete. I clicked on ‘Update current component in current library’ (and yes, I had my custom library selected) but this appeared to do no good.
I suspect the problem here might have been that, while I was creating this part, I accidentally had one of the default libraries selected as the working library in the component editor. I may have saved the half-done part to that library instead. I switched the working library to finish the part. This didn’t help: it’s possible that, where there are naming conflicts, KiCad defaults to the built-in libraries. This time I didn’t have to edit files. Restarting KiCad once more forced it to play ball.
It shouldn’t be this difficult.
You’ll find lots of moaning online about KiCad’s godawful library system – and it’s all justified. This is basic stuff but seems, to me, flaky and unnecessarily complicated.
One gotcha to watch out for with the component editor is the zoom level when you open it. I drew a rectangle for the part outline and thought, “the outline is awfully thin – barely visible”. Then I added a pin which turned out to be similarly hard to see. It turned out I was zoomed out for some reason, so the part I’d drawn was enormous; when I dropped it on to an A4 schematic it overhung at both top and bottom!
Another detail I dislike is how pin positions are named. Under ‘Orientation’ you get the options of left, right, up and down. Now, call me crazy, but I would have thought selecting ‘left’ would have created a pin that goes on the left side of the component. But oh no – it’s a pin whose left side connects to the component. Up and down are similarly bizarre, although at least the words offer a little more of a clue. I have to double-think every time I set this.
Footprints are just as much fun. Eagle calls these ‘packages’ and I have no strong feelings either way, except that KiCad stores its footprints in files called ‘modules’ inside folders with the file extension ‘.pretty’. Are we confused yet?
(Some of this complication is as a result of improvements to KiCad while maintaining legacy compatibility – which never turns out well.)
The footprint editor acts in a similar manner to the schematic library. To create a new library, one route is to open a part from an existing one and then select the option to save the part to a new library. Now, KiCad as a whole gives you the option to set paths, including the ‘modules’ (ie, footprint) path. So why doesn’t it choose this as the default path when saving a new footprint library? Instead it selects the project path. I know many people like to save custom libraries for each project, but if you have a defined path it would seem sensible to default to it.
My new footprint library still wasn’t visible – there’s a footprint libraries wizard to help you handle that and a separate footprint libraries manager. (By the way, if you’re trying this at home, the wizard is where you should start.)
I’ll be getting into footprints in more detail when the time comes to lay out the board. But to get a glimpse as to how it works I created a footprint for the LED display. Spoiler alert: it was pretty easy.
By the way, I think my schematic for the display turned out pretty nice. Here it is alongside the one from the default libraries.
So, to wrap up, creating parts in KiCad is a breeze. But getting the library system to cooperate can be a source of frustration.
I mean, once you know all this stuff it’s not a problem. It just has the feel of a workflow that was a bit clumsy to start with and then, as revision followed revision, just became more and more hacked about, convoluted and compromised as it was burdened with new stuff. It’s ugly and is in dire need of complete refactoring.
As for the business of associating schematics with footprints, that’s for a future post. But from everything I’ve read, I can’t say I’m looking forward to it.