I don't like this tutorial. It purports to teach you "what everything on the PCB fundamentally does, and what every single component on your PCB is actually for!" but it gets the reasoning for a lot of stuff wrong, sometimes badly wrong. I think every single instance of a component with a numerical value picks the value with a misleading or even completely wrong justification. Even if the tutorial gets to an OK schematic in the end, it shouldn't be teaching shoddy reasoning.
(And the author doesn't seem to understand decoupling capacitors, but most people don't understand decoupling capacitors, including most datasheet authors, so that doesn't surprise me.)
Also, KiCad's "solutions" for BOMs are hilariously, absurdly terrible. But that helps me earn a living, so I can't complain too much....
I agree with the sibling comment that "How to decide what you need on your devboard" is the tutorial that would be nice to see. This article is trying to do too many things at once (design a dev board, baby's first schematic, baby's first PCB, baby's first JLCPCB order,...) and that's really the only one that's novel. The rest of it is standard EE stuff that's covered in a lot of places (with varying degrees of success).
As for decoupling, I've written about how to do it in various places scattered across the internet. I should really collect it all in one place one of these days.
This reads like the author just wanted to format his ChatGPT-aided build record in a lecture manual format, rather than being an attempt at such material.
At no point in the entire design process within KiCad does this design ever get part numbers assigned for its resistors or capacitors (to pick one thing). That's not acceptable for professional work. A Bill of Materials ABSOLUTELY MUST DESCRIBE THE MATERIALS used in the assembly of the PCBA. Internal part numbers are perfectly acceptable: assigning a generic RES-0402-10k or WIDGETCO-PN987654321 or whatever would be OK by me. KiCAD does not really do this, as evidenced by how this design reaches "design complete" without being... complete.
EVERYTHING MUST HAVE AN ORDERABLE PART NUMBER OR INTERNAL PART NUMBER.
But the resistors are the easy parts. SMD thick film resistors are basically all interchangeable. Things like the ceramic capacitors (MLCCs) cannot be substituted for each other because they all bloody well behave differently so good luck getting the same behavior if you randomly pick a capacitor vendor on LCSC each time you build boards! That's how EEs get fired, and deserve it.
When I generate a build package in Altium, it has complete lists of every part in the design, its MPN, at least one supplier to purchase it, and the SPN for that MPN. (Sometimes internal parts don't have suppliers assigned, but then they're tracked elsewhere in the project or company organization.) There are also assigned alternates in many cases, though they are typically inadequate. Larger projects should use entirely internal part numbering, but that's a real headwind for smaller stuff. All of this comes from a single master part database, plus a project part database, and never gets touched by hand after a library entry's birth.
KiCad is so crap at doing this that last month a client literally paid me thousands of dollars to fix up a garbage KiCad design package that didn't have this information properly stored. There are several add-ins for KiCad that claim to do BOMs better... but it's not standard, so if you don't document what you did and how (which you do not have to do in real CAD software, because it is built in and the CAD vendor documentation plus the years of built-up lore will cover you!) it may as well not exist. Certainly it didn't exist in any sort of usable form for this project.
I don’t think you’ve used KiCAD. Simply add an MPN attribute to your component and that is it. Use the built in BOM editor and exporter. Done. There are certainly ways to misuse any advanced software. But it definitely can and will produce a complete BOM without additional add-ons. Grated, the exporter is limited to CSV files. So I’m guessing your workflow requires something more interesting?
> Simply add an MPN attribute to your component and that is it.
No, that's the problem, right there. KiCad doesn't have a parts library. KiCad has schematic elements you can manually tack parameters on to. And everyone does it slightly differently!
There's no way to have a set of parts you can select from that are guaranteed-approved (because we used them previously or whatever). There's no way to have the software just show you the entire E24+E96 series of standard 0603 resistors so you can just grab one and go and know that it's orderable. There's no way to be able to get that confusing series of diode footprints and orientations right once and store it forever so the software gets it right for you from now on. (Diodes are the worst. At least Panasonic got out of the diode business. And, yes, I was thinking of their product line when I said that.)
Yeah, sure, you can do anything by tacking parameters on schematic components. Sometimes you even have to do that. Just like programming in assembly: there's no job it can't do. But sometimes you really need a little bit more, right?
And that's notwithstanding the fact that many people who use KiCad, like our article author here, don't even bother to tag parts with an MPN parameter! That's a cultural issue, but it is one the software can and should be pushing back on.
The nice thing with KiCAD is that a part is simply a symbol (schematic element) with enough parameters attached. You can specify footprints, MPN, ratings, value, etc. then store it in your approved and verified symbol library for use in all your projects. Use your R_4.7k_0603 symbol an it comes preconfigured with footprint, MPN, rating etc. Making these symbols is a lot of work but very simple.
Unfortunately there is no standard name for these parameters beyond footprint, value and some others. MPN, brand, rating etc. are not default. This hinders bigger adoption I think, and makes every project unique. This should be improved.
>When I generate a build package in Altium, it has complete lists of every part in the design, its MPN, at least one supplier to purchase it, and the SPN for that MPN. (Sometimes internal parts don't have suppliers assigned, but then they're tracked elsewhere in the project or company organization.) There are also assigned alternates in many cases, though they are typically inadequate. Larger projects should use entirely internal part numbering, but that's a real headwind for smaller stuff. All of this comes from a single master part database, plus a project part database, and never gets touched by hand after a library entry's birth.
Only if you've put in the effort to make that database in the first place, which Altium makes pretty annoyingly difficult. I really don't like Altium's mess of options for parts libraries, the defaults for which all suck and a sensible setup requiring a lot of fiddling. I haven't dived too deep into KiCad's setup here recently, but it'd have to try hard to be worse than Altium. The difference is cultural, not tooling.
I thought this article would first start with the most essential question: "How to decide what you need on your devboard".
Without that critical piece of design work, you may as well call this "How to build a Raspberry Pi Nano from scratch". Which, to be fair, is also a good article to write.
But step 1 for really building a dev board is answering the question, "What do I need from this that I can't get from a $5 Amazon purchase?"
Not sure if it was due to higher load from HN or my IP location, but your website is inaccessible to me right now: "This deployment is temporarily paused."
Honestly my problem is that all my designs turn into devboards since I always have a kind of "FOMO" of not breaking something out and then needing it later to bodge things... and then I'm left with a crowded board where I don't even use two thirds of things...
Test pads are great for these anxious breakouts. I usually drop tons and tons of test pads on the back of my boards as it's a very dense and unobtrusive way to expose traces that you probably don't need.
(And the author doesn't seem to understand decoupling capacitors, but most people don't understand decoupling capacitors, including most datasheet authors, so that doesn't surprise me.)
Also, KiCad's "solutions" for BOMs are hilariously, absurdly terrible. But that helps me earn a living, so I can't complain too much....
reply