I want to use KiCAD. I really do. But I can't, and neither should you.
If you don't need a lesson in what EDA is about, skip ahead about five paragraphs, otherwise keep reading so you get enough background to understand what's wrong here.
What the hell are you talking about?
Open-source EDA (Electronic Design Automation) is almost a magical thing that we've dreamt of for decades and which, by some celestial intervention, has become a real thing. Electronic CAD is a really complicated and unique animal - entirely unlike CAD for ordinary solid objects - because it has to bridge two worlds, the logical and the physical. For every little black plastic "chip" you see on a board, there are (and I'm not exaggerating here) anywhere between one (1) and ten billion (10,000,000,000) gates inside it. (I'm kind of fudging here because while you can check wikipedia for the highest transistor-count device - around 150 billion at the moment on a single chip - the number of transistors per gate varies, and I don't know if there's a generally accepted multiple. Doesn't matter, you get the idea - a whole buttload.)
I don't want to get into the weeds, but what you need to understand is that since the advent of the integrated circuit, our designs haven't started with the physical chip you see on the board, but with the multiple logical functions inside it, and figuring out which logical function (the inverters and gates and the slightly larger things you make from inverters and gates, like counters) is going to be in which physical "package" is something that's usually decided later in the process.
So since the logical and the physical exist in two different design realms, you need tools that understand the correlation between the two.
Follow along; If I lay down a little gate symbol on the schematic diagram that is the beginning of the design process, the CAD system needs to know how those symbols relate to the physical chips in order to "package" the design when it moves from the logical world of the paper schematic to the physical world of the fiberglass printed circuit board. If I put a hundred gates in my design, and each chip contains four gates, obviously I'll need 25 gate chips - but much of the work is in figuring out which gate goes in which chip in order to simplify the connections between them, because 100 gates means 300 inputs and outputs, and each chip has 14 pins... you get the idea - you have to wire the chips to each other efficiently or it turns into a tangled mess.
So the key to the entire enterprise is what's called the "netlist", which is a database that keeps track of all those logical connections as you're drawing the schematic, and which, during the "packaging" stage, adds to that information the chips and pins stuff so that the connection information is maintained as you lay out the circuit board. And since designs are always evolving, being revised and corrected, the system has to keep track of changes that occur in the schematic so they can be carried through to the PC board - and changes in the board design that need to be propagated back to the schematic so that the schematic, netlist, and board layout are always in 100% agreement with each other.
At least, that's how it's supposed to work.
Back to KiCAD.
So along comes this French guy in '92 and he's come up with a schematic package and some other stuff and that eventually forms the core of the KiCAD suite of tools. And about 20 years later CERN starts throwing money and time at it and in a few more years it catches on and eventually joins up with the Linux Foundation, and because it's the first real free and open-source EDA suite it really catches fire because for the better part of 40 years everything has been commercial software at prices anywhere from a few hundred bucks for low-end PC stuff to hundreds of thousands for a really sophisticated suite running on a Unix workstation - Sun, HP, etc.
And this is, in theory, a really good thing, because for more than 35 years I've been using a number of those commercial packages - including the one that's been on my desk for nearly 25 years - and I felt that it was time to get updated. Using the same software as a lot of the people around me would allow us to share and build upon each other's work or even just check and correct or offer revisions, all of which are highly desirable. Also, the system I'm running is on a big old Unix workstation - not very portable - and KiCAD would have the extra benefit of letting me work anywhere on a light little laptop. That'd all be so great - and for free - can you imagine? Is this heaven?
So I did a fresh penguix install on an old laptop, stuffed in KiCAD (after receiving a recommendation from a trusted friend that the version that had been released in early 2023 was really ready for prime time), and thought I was made in the shade (note: I don't usually pack that many rhymes into a sentence).
Making a switch like this always comes with a learning curve, and I knew this would be no exception, so I started with an easy design: A circuit board originally designed by someone else more than 40 years ago, part of a system that hasn't been made for many years but is still needed by a select few. I was going to do a "reproduction", and as a board that's in no way challenging by modern standards, it promised to be a fast, easy, and relaxed way to learn the software. A couple of hours into the initial schematic entry, I had to edit a symbol, which is a perfectly routine operation. You find a mistake in a symbol and want to correct it, or just move some parts of it around in order to better suit its surroundings. In this case, a 555 timer, which anyone - even the most novice hobbyist - who's built any hardware since the mid-70s will recognize. The stock symbol (that came with KiCAD) was just wrong - it didn't respect the normal "inputs on the left side, outputs on the right side" convention that we try to adhere to for logical flow and readability, no different, really, than the Western convention of reading left-to-right. So I fired up the symbol editor, moved the pins and their names around to where they should be, found that the editor had a couple of nice features I hadn't ever seen before, and returned to the schematic, where I got a shock.
Pay attention - this is where it goes to shit.
Before editing the symbol, I'd connected some signal lines (wires) to its pins - let's simplify this by saying I connected wire 1 to pin 1 (on the left side of the little symbol box), and wire 2 to pin 2 (on the right of the box). Those pins have specific functions, and they were in the wrong places on the symbol - the one on the left should have been on the right, and vice versa. So that's all my little edit was - swapping the two.
Having swapped the pins, the wires should have stuck to the pins they were originally connected to: 1-1 and 2-2. But that didn't happen. The wire ends had stayed where they were, so now wire 1 was connected to pin 2, and wire 2 to pin 1. What should have happened was each wire staying connected to the pin I connected it to. Instead, those two connections were swapped.
This would not happen if the schematic software understood, respected, and maintained the connections the designer originally made. A properly-functioning system would have, after the edit, kept wire 1 with pin 1 and wire 2 with pin 2, with the wires stretching (what we call "rubberbanding") across the symbol body to their proper pins. It looks a little messy, but it maintains the design's integrity and is easy to clean up (that is, to restore orthogonal routing, as we say).
This is very bad, because where modifying a symbol is just a cosmetic operation meant to improve the organization of the drawing, not maintaining correct connections trashes the netlist (remember, that's the database of connections, and what the schematic is about) and in turn introduces errors into the board layout, and in days or weeks, after this schematic has passed through the PCB layout process and manufacturing and come back as a completed assembly, it wouldn't work because the connections were wrong.
Now, you may be thinking "What are you making such a fuss about? Isn't editing a symbol an edge case that's outside of the normal schematic editing process?" A perfectly reasonable question to which the answer is: No. In the normal course of events, a symbol - depending on its size and complexity as well as those of the surrounding schematic - can be modified (everything from a little tweak to a major overhaul) dozens, or even hundreds of times. But where the rubber really meets the road is that this failure extends to the schematic itself. You put down your symbols, you spend hours wiring them up, and when you have to move a symbol (that's "when", not "if") it leaves all of your connections behind, dangling on the page as though you never connected them at all. (That is, apparently unless you're using drag rather than move, itself a problem because these guys also suffer from the million-monkey-malaise - that everyone who thinks he has a Great Idea (tm) adds another command to a list that's already way too long rather than someone cracking the whip and saying "No, we have too many commands and too many menus and/or hotkeys to get there, so start paring it down and rationalizing it." I mean, their pull-down menus alone are out of control; when you click on a button and it opens a menu that has dozens of commands that extend below the bottom of the screen, you should realize you have a problem.)
A brief treatise on drawing schematics.
It's awfully simple, really. In schematic capture, connections (between wires and pins or between wires) can't just "happen" or "unhappen". That is, a connection or disconnection cannot be an inadvertent byproduct of some other operation, like moving a component. The creation or removal of connections need to be explicit acts - you're telling the software in no uncertain terms that this is how you want it wired. And as I explained, when you make a connection, it sticks to the pin, so if the two move relative to each other they remain connected. In practice, when you move something, the result is often a rubberbanded line that crosses an unrelated pin, line, or vertex (a bend in a line), and it's critical that the software doesn't do something stupid like connect them together just because they've touched. Instead, it should place a marker warning you that though these may appear to be connected, the netlist says you didn't intentionally connect them, so you need to clean them up. Strict observance of the netlist. If you didn't connect it, it's not connected. If it's connected, it stays that way until you disconnect it. How hard is that?
For KiCAD, it turns out, really hard. Move something and connections break. Or they connect where you had no intention of a connection being. Its "boosters" say "well, so you just have to carefully proofread your schematic before moving through to PCB layout," to which I say "what the hell is wrong with you? My system maintains the netlist so I don't have to scrutinize hundreds of lines on the drawing to catch mistakes because it prevented me from making them in the first place."
Now, back to how editing a symbol broke the schematic.
So, since this represented a failure of the most basic function of a schematic capture package - MAINTAINING NETLIST INTEGRITY - I figured I must have made a mistake, perhaps missed a step like clicking on a button that tells it that I've just modified a symbol, so please merge the changes and update the drawing. But I couldn't find anything like that, so I took the next step, which was to sign up to the forum and ask how to do it. Which I did.
And you'd think that I'd just fucking invaded Poland.
Because what followed was an online war of more than a hundred heated exchanges in which most of the skilled and experienced KiCAD users, after telling me I'd done everything correctly, explained that it was behaving as it should. Which, I carefully explained to them, is complete bullshit, which turned me into a war criminal.
To be fair, there were actually a few (well, maybe a couple) who had extensive enough design experience to understand what I was talking about and agree with me. But the rest? Fucking delusional.
Here's just one argument I received from topsy-turvy world:
"The main use of a schematic is to have a visual representation of a circuit that humans can interpret. That it can also create a netlist is a secondary goal...
It’s the same with programming. If I write a C++ program, the goal is to write text that is human readable and understandable... That the text is also supposed to pushed though a compiler is only a secondary or tertiary goal."
His initial argument does have a fragment of merit in it, but only outside of the EDA context. If you draw a schematic, and then hand-wire a prototype, anything in that drawing that looks like a connection to you, while you're building it, is a valid connection. In fact, I've done this a lot.
But it's completely out to lunch if the schematic is the means of human-friendly data entry for information that will then be fed into a pipeline of software tools, including the netlisting, packaging, and layout I described previously. And you get a glimpse of confusion in extremis when he tries to carry this argument into programming by claiming that the primary reason for writing software is for people to read it, not for it to be turned into executable code to run on an actual computer. How can you even communicate with someone like this?
To summarize, then, KiCAD's schematic capture is a joke. What looks like a connection, and you may think is a connection, turns out not to be one at all. It's a faux connection, one that looks connected but really isn't. Instead, it's just coincident points in space that have no actual significance to the schematic capture system. It's up to some downstream netlisting tool to extract that meaning, but by then you'll have had hundreds of opportunities to introduce errors into the diagram without the software doing its job, which is to try as hard as it can to keep you from making those mistakes by understanding the nature of what you're doing.
And that's why - unless and until someone I trust tells me that they've changed their tune - I won't be wasting any more time wallowing in this dumpster fire. One of the developers who was involved in that fray made it clear that what I was suggesting "isn't [their] paradigm", but he didn't explain what their paradigm is, if in fact there is one. Put that together with a comment from someone about the coming revision of the software having 500 commands, and you get a clear picture of the worst aspects of an open-source project: Badly thought out software completely out of control. Which is a damn shame, really, because for all I know they may have an outstanding PCB layout package. But since the schematic comes first in the design flow, as long as it stays fucked I'll never get the chance to find out.
And it's becoming an industry standard, not just because it's free, but also because:
Open-source software users tend to exhibit cult victim behaviour
This is fairly easy to understand. Open-source developers, who in general, are unpaid (at least initially) and doing the work purely for idealistic reasons, are viewed as being morally superior to the "code whores" being paid to write software for for-profit companies. Similarly, those companies are tarnished by being motivated simply by "filthy lucre" rather than... I dunno... the intrinsic nobility of the art? Of course, if the users of that software want to adopt that view, there's not a lot you can do about it, nor does it really matter - they're entitled to their own opinion. But in their fanaticism, there's a tendency to view the product of that morally superior process as technically superior as well, one conferring the other, regardless of how it actually stacks up against "competing" or "comparable" commercial packages. Such a conflation is, of course, ludicrous, but just try to make that argument and someone is likely to suggest that "perhaps this software really isn't for you" in the tone of voice that strongly implies that you're a heretic about two posts away from being stoned to death (I know because it happened to me). It's a short leap from idealism to zealotry. Come for the free software, stay for the brainwashing that this is the One True Way and without sin.
But lots of KiCAD users design good circuit boards, so where's the harm?
I've only recently figured this out. By chance I found myself redrawing a very bad schematic done in KiCAD, one that had been reverse-engineered from a small, simple circuit board, the original drawings for which had been lost. I wanted to reproduce this board (I only needed one for my own use, so I artisanally wired it rather than fabbing a PCB), and the schematic was so poor that I had to refer to data books and other schematics and (even) photographs - in addition to a healthy dose of inference - in order to figure out the things that the drawing should have conveyed. It was utterly chaotic - rather than providing a logical overview of the (very simple) circuit, with the signal flow left-to-right and top-to-bottom, with connectors on the periphery of the drawing, signals entered in the middle and went in all directions. Where there were a couple of latches grabbing signals to light indicator LEDs, one flowed left and the other flowed right. In a circuit trivial enough that I should have been able to take it in at a glance, I had to stare at and slowly unravel it in order to see how simple it was. It pissed me off enough to put a couple of days into redrawing it properly so I'd have a good reference document for myself (and anyone else in the community who might want to build one), as a thank-you to the board's original designer, and as a lesson in how schematics are supposed to look. Clearly, the guy who drew it had no idea what schematics are really about.
But I hadn't yet made the KiCAD connection.
Around the same time I built an unrelated widget - also for my own use - that had been designed by someone else using KiCAD. The board was fine and I didn't encounter any problems in getting it populated and up and running, but his schematic was hard to follow because - rather than consisting of contiguous, unbroken lines connecting symbols together - many of the lines were stubs and fragments that had been labeled, indicating that they connect to similarly-labeled stubs and fragments elsewhere in the diagram. This is really a pain in the ass - you have to waste time where's-waldoing around a drawing looking for the matching tags, and what usually happens is you get sick of it and break out the 10-colour hilighting marker set. I've worked with extreme examples of this nonsense in the past - diagrams spread over dozens of nearly-empty B-size sheets and with almost no lines connecting the schematic symbols; instead, every line-end tagged to indicate which tag on which sheet it's connected to. It was awful. You spend all your time flipping back and forth between pages, trying to find the connections, and can't get a coherent picture of what the whole circuit actually looks like.
Slowly it dawned on me what these two schematics had in common: They were bad because KiCAD makes doing good drawings harder - exactly the opposite of what CAD is supposed to do. Because the software doesn't have any understanding of what a connection is, moving anything is going to break the drawing and result in wasted effort reconnecting what you'd already connected (or so you thought) - or looking for the connections you didn't put there. Enough of that, and pretty soon you're just saying "Fuck it, there's no point in actually drawing these connections because they're just going to get trashed later. So let's sidestep the problem by putting a label on a stub so there's no line to mess up." Similarly, reverse engineering - even a simple circuit - is a lot of work because you usually just slap down the symbols, wire them up as you gather the connection information from the example PCB, then rearrange the drawing into logical sense. If that rearrangement process is a painful one, you're more likely to just leave the symbols where they were, regardless of how incomprehensible the drawing is as a result.
So the lesson here is that:
Bad schematic capture breeds bad schematics.
And that is how a gradual degradation of standards happens. The more people adopt (and are conditioned to accept) shoddy tools, the more bad schematics will become the norm, and the new generation will come up without understanding how these drawings should look and function.
Finally (I hope?), a personal note:
Another result of the widespread adoption of KiCAD has been the pernicious European influence on our schematics. I grew up reading Popular Electronics, but in the late 70s and early 80s I bought the odd issue of (the English magazine) Elektor and found the schematics not just foreign, but perverse (like German porn is to North Americans), so I'm going to exhibit a shameless North American chauvinism here:
Goddammit, we invented the electronics industry, and allowing the invasion of this software to drive a Eurotrash replacement of our symbols is not acceptable. Resistors are fucking zigzags, not boxes. Capacitors are curved, not flat. And (default) grounds have parallel lines - if you want to lay down a triangle, it had better be a different ground. So if you're in the US or Canada, show some fucking pride and use our schematic symbols rather than being a lazy piece of shit and letting these immigrants poison the blood of our schematics with their degenerate symbol libraries, motherfucker.
