Smashing job. I use kibot in a similar fashion locally to generate my fab packages for my kicad designs.
I had it set up as a CI job for a while, but I ended up disabling it for a few reasons, the main one being that I just don't think it's a good idea to constantly create build artifacts for circuit board designs. It has created problems when people have circulated intermediate schematics generated by CI that don't match the hardware we built.
You really only need to archive fab packages (by which I mean schematic, gerbers, BOM, assembly drawing, fab notes, etc) at the points in time where you fab and assemble a board.
Creating more artifacts just creates the possibility for more noise. It's not like software CI as there's not really a way to automate hardware testing in a CI server. Very little incremental value in continuous artifact generation as a result.
Yes, I was thinking of changing the pipeline to respond to only tags for outputs. Then i can just set a release tag when I am ready to send it to a fab.
This is what I'm doing. Though it does break down for smaller projects where I had combined firmware and electronics design in the same repository (not a great idea in retrospect).
That rapidly becomes a rough ride - especially when you've got different groups writing hardware and firmware independent of one another, but pushing to the same repo.
I've used kicad professionally for about three years now. That brief phase of using CI was in my current employer and we had some confusing weeks where no one knew which sch version was the right one.
Being able to share out autogenerated schematics is one of those rare cases where CI hinders you rather than helps you.
I'm sort of tunneling in on this one facet though. This is great work and I'll be reading it more closely when I get off the plane. I'll probably grab some of your kibot configs for myself!
I pointedly keep gerbers etc .ignored (directory naming convention where gerbers always export to GERBER_${TITLE}_${REVISION} ,and .gitignore includes GERBER_*/)
and only upload gerber zips as release artifacts
I do keep a bom.csv in the repo to link right in the readme. I consider the specific part selection part of the reference not entirely documented in the sch, and so it's source.
Same for .stl and other output meshes from openscad and freecad sources.
Which is kind of a pity because github has a neat stl diff viewr that's essentially useless if you don't want to check in stls.
> Is it hardware testing at the simulation/emulation level as a "digital twin"
This, very likely.
It's possible to set up simulations of certain sections of the hardware using some Spice software, but it's quite time consuming and I'm not sure if anyone's built a way to compare the output of the simulation to expected output.
Simulating any entire circuit as a whole is impossible, since lots of parts just cannot be simulated.
Given enough computing power and resources --both human and hardware-- one could technically simulate anything. However, in the context of a reality with practical boundaries, that is simply impossible.
Imagine being tasked with simulating an entire Raspberri Pi board. You would probably need dozens of engineers and likely more than a year just to write and verify the simulation code. And, of course, a supercomputer to run it.
Hardware isn't about isolated components. It's an arrangement of components on a physical circuit board with interconnecting traces and physical characteristics that interact with the finished board. And, all of this, exists in the context of environmental requirements (temperature, humidity, vibration, RF susceptibility and emissions, thermal requirements, etc.).
A "simple" DDR memory design consists of memory chips, the transmission line (traces) connecting to the controller (FPGA, processor, etc.), the PCB stackup (at speed, this matters a lot), decoupling capacitors, the power distribution system feeding them, thermal management and more.
And that's just two chips talking to each other in a fairly structured way.
Pretty much any kind of non-trivial digital logic. For instance emulating a typical ARM microcontroller accurately, while technically within the realm of possibility, would require a huge amount of effort; every bus and every peripheral's functionality would have to be replicated, including hard-to-gauge details like their power consumption. Even if you have access to the HDL that was used to build the chip (which you usually don't), such a simulation will never be 100% accurate.
spicyjpeg basically described the sort of thing I was thinking of, but even for more boring things like opamps or transistors, it's a big hassle to track down or design a simulation model.
There's a semi-standardized file format for simulation models, but there are still differences between simulators. And every manufacturer's website is a different kind of poorly-organized, so it's hard to even find the models.
The other thing is things where high frequencies exist, like switching regulators. It's possible to simulate them, but there's all sorts of parasitics (imperfections from the circuit being made out of real stuff rather than lines on paper) that impact the circuit. I've only used KiCad, so I don't know if the commercial software here can model these parasitics, but they can have a big on performance.
Things like pspice and microcap can simulate a lot.
But if theres high speed digital and switchers on the board, simulating it all could take tens of hours, if not more.
For firmware development I’ve done automated testing with the hardware on a fixture connected to JTAG, uart, and DAQ. It worked pretty well but every once in a while I’d have to press a button or something that the fixture couldn’t.
At my previous job I, too, set up CI/CD from Schematics/PCB data to device documentation PDFs, 3D models for mechanical integration, and packages for several of our EMS (electronics manufacturing services, each required different data formats) and other items, such as part database management (EOL checks, availability, prices). I, too, used KiCad and Gitlab, and was honestly quite happy with it. The biggest problem was that at a professional scale, KiCad was crashing a bit more often than one would like and it was tedious to find and fix the bugs or work around them if they were already fixed upstream (which they often were).
Still, this heavily sped up prototyping, as anybody could always fetch the data required to release or produce stuff. Shifting left works for electronics just as well as it does for software. :)
Most of that work was done 2016 - 2020. Typically we saw issues when people jumped on new features in new releases, so it's pretty much excusable and we'd just forbid the use of these features as long as we didn't really need them.
However, it was not uncommon. I always had a debug build of KiCad on my machine in order to replicate crashes or odd behavior others saw.
It should be noted that we're generally talking about PCBs that could get pretty big and complicated. We certainly uncovered edge cases that were hard to foresee that way.
What are some professional alternatives to KiCad? I've seen Altium (which already appears leagues ahead of KiCad, but the license fee is really high...) but none others.
I think the other two big expensive pro ones are Mentor Expedition and Cadence Allegro. There's also NI Ultiboard.
I haven't used any of them though. I don't think you need them unless you're doing really pro stuff (e.g. a PCIe card or motherboard) or RF design.
On the free side they mostly suck. KiCad is powerful but has AWFUL usability. Don't bother unless you're willing to fight the software and spend hours on tutorials for things that should be trivial. Think early Blender but worse.
The other free options are:
* Eagle: Terrible. Do not bother. No idea why anyone uses this. Doesn't even get copy and paste right.
* gEDA: Awful. Do not use.
* DesignSpark PCB. This is very Windows 95 and a bit odd in some ways, but it's probably the easiest to use software and it's not limited like some free software (frequently there are board size or component count limits). Very decent option. If you're new to PCB design and use Windows I think I would maybe recommend this. Either this or...
* Horizon EDA: A new option that uses the KiCad routing engine but is way more usable. I would say this is the best free option at the moment, and it's open source. Except maybe LibrePCB because...
* LibrePCB: I haven't actually gotten around to trying this yet so I have no idea. May be good, may be awful.
gEDA was quite good when it was active. In the last few years the ringdove eda project is actively maintaining and improving pcb, while the lepton eda project is actively maintaining and improving the rest. They're quite good.
> What are some professional alternatives to KiCad? I've seen Altium (which already appears leagues ahead of KiCad, but the license fee is really high...) but none others.
Kicad is on a good track to become as capable as Altium, if we judge over the last 3-4 years of the progress. I made it a habit to give them money annually via the Donate button on their front page: https://www.kicad.org.
At least for many common use cases that is absolutely true.
IMO other tools mostly excel at special tasks. Be it having a good component library, or less rocky integration with external tools, for example for FPGA/ASIC configuration or layout, so the stuff that is heavily driven by commercial interest in increasing an engineer's speed or lowering defect rate.
(Disclaimer: Haven't been doing electronics for two years, though, as I switched to Software.)
I'm a generalist with a degree in computer science and physics, experience in science (a little), software and electronics engineering, and a lot more non-technical stuff. While I'm certainly a lousy software engineer, it's more than enough to get hired in and around Munich.
Technically it's embedded, but the products are sufficiently complex that my day-to-day work involves everything from the usual embedded stuff (hardware set-up, FPGAs), managing devices, web development (Most devices have a reasonably modern SPA web interface using different frameworks) and signal processing. A lot of the work needs to scale from small embedded SoCs to bigger "appliances" and further. I'm pushing very much for modern techniques, such as shipping virtual units as containers for evaluation or development against our device APIs, which our customers quite like. While a lot of it is in C and C++, I'm generally also pushing for newer languages, for example a lot of the tooling I build is nowadays in Rust.
(If you're interested, feel free to have a look at the careers page. If you plan to switch and are a good fit otherwise, I'm certain that could be accommodated. In case you choose to apply, drop a note that you have a recommendation from an employee, it should speed things up. We are definitely looking for many new engineers as we're growing quickly. ;) )
I'm in a similar position (EE doing embedded programming with experience in Python C and C++ and a bunch of other stuff) and also thinking about switching to higher level stuff (web-apps, business apps, whatever). Also in Europe.
My motivation: the higher level stuff seems easier with up to twice higher hourly rates, but most importantly: it seems way easier to get fully remote jobs in the higher level programming areas. I would even take a pay-cut in exchange for fully remote: it's my nr 1 motivator to switch to something else.
What's your motivation if I may ask? Just curious.
>What's your motivation if I may ask? Just curious.
Same. Mostly the possibility of WFH which is absent if you ever need to touch lower level HW. Pay I can take it or leave it.
> the higher level stuff seems easier
It's not really easier though. I had a 3 month stint doing some backend contract work and the amount of framework fuckery and the speed of development on live web systems that customers use, can be crazy stressful compared to embedded.
It's like changing the components of a car, while driving it. Shit breaks much more often. Embedded felt much less stressful since any of my commits to production didn't instantly impact thousands of customers at once like on the web, with the risk of fucking their data or experience.
There's probably no single field where you will find more solutions to the same problem, maybe except for text editors? Common ones would be Mentor Xpedition, PADS, Cadence or OrCAD, though. Another irritatingly common one is Eagle, but last I used it it was quite a bit worse than KiCad.
However, this is a small subset of the actual list. Chances are, there's many companies working with proprietary PCB designers that were discontinued 20 years ago or just maintained for a few companies.
Eagle was popular because you could get it for free as a hobbyist. That suckered me in years ago, convinced my employer to pay for the license, and then they got acquired by Autodesk literally 2 weeks later and refused to honor the license we had just bought, so I had to guard my installer binary with my life.
And then we ourselves got acquired by a company that could afford Altium.
Last I used KiCad for much (ca 2018), I found the workflow to be kind of clunky so I never expended much effort to get really good with it. For instance, their footprint assignment scheme caused so many errors because you couldn't, at that time, assign footprints to a given part in the component editor. Thus, you could spend a lot of time getting the footprint just so, then not notice you fat fingered the footprint assignment unless you did the old trick of printing out your solder mask and hand populating your board.
But whatever KiCad's current flaws, its not Fritzing, so that helps.
I used Eagle in my first few years of hobby PCB design. It was fine, worked well. I really jumped on KiCad after development started to pick up and Mac support became really reliable. The workflow for managing schematic symbols and component footprints has _massively_ improved. It's definitely more usable. I think shortly after I started using KiCad, Eagle was acquired and that really soured me to it. Autodesk's products are fine, but I don't really care for their business practices. Your noting they were unwilling to honor a license brought prior to purchase is more kindling for that fire.
Eagle's poor copy and paste when I had to use it at university was a real shocker. So much work for such a common task. And it was so easy to get it wrong.
Sadly, it's not like KiCad excels there either. At least to my knowledge it's not possible to replicate a routed part of your module like it's already possible to reuse schematics sheets, is it?
It's kind of a miracle that the output files from all the solutions are standardized and work across the industry to automate production and you can get a PCB made for $1. In the mechanical CAD/manufacturing world there is a LOT of manual work and discussion required. There are now automated quoting services, but they just put the onus on the user to upload files and manually input details into a proprietary system.
I'm not an expert for mechanics, but isn't what you discuss for mechanics usually tolerances or properties that are not directly involved in the outline of a part, such as materials used or roughness?
This stuff you still need to discuss. It's just that the basics are often enough. But, in my experience, if you want less than 0.3 mm tolerance on your PCB outline or a component needs a certain soldering cycle or method, you better tell your PCB manufacturer and you better do it on the phone, they may or may not look at the drawings. Once we only accidentally discovered that an isolator in a medical device was soldered using a temperature profile that exceeded its maximum temperature and thus the isolation was no longer guaranteed by the manufacturer.
Yes, tolerances and other things need to be discussed. STEP files can technically convey most of these things, but in practice most MCAD software cannot output these details to STEP files, and most machine shops won't check these details anyway. Both parties tend to revert to 2D PDF drawings to agree on details, and more importantly figure out whose fault it is in case of a mistake in production.
ECAD is way more standardized than MCAD for information sharing and version control, and at least has industry standard best practices. MCAD is still a wild west, with mostly proprietary tools used for version control (several thousand dollars per user per year) with no hope of interoperability. And each vendor that offers automated quoting uses a proprietary system, with a lot of manual inputs.
Granted, mechanical parts can be much more complex and it's easy to make unmanufacturable parts in MCAD, whereas ECAD is basically a stack of 2D layers. But still, as a mechanical engineer I am amazed at how easy it is to order a PCB or even an assembled PCB compared to ordering the simplest machined part.
All of that will probably be solved when an AI is released that generates code-based mechanical CAD models (supporting tolerance annotations per mechanical feature) based on text/voice input.
I've ripped out chunks of KiCad to run as CI/CD on the basic PCBs I have. KiCad's data and code is really not geared up for this, so quite a bit had to be hacked up to make it idempotent and even just to bring it up to basic C++ coding standards.
I've been looking at upstreaming what I can and what would even make sense. Ultimately I've switched to mostly using non-KiCad python (dealing with the messy nature of the bundled python wasted 3 solid days, don't use it unless you must) to generate and manage a parts DB + vector drawings that are then processed into the KiCad formats.
It works, but a lot of KiCad internals were simply never designed to handle this scenario. Even multiple PCBs are a pain. It uses multiple proprietary vector representations, some for rendering and some for analysis, etc. The file formats themselves are ok to deal with but aren't well-specified so they will change on you.
Fortunately, the end Gerbers are well defined and it's often easier to simply generate those directly vs going through KiCad if the DRC are guaranteed by construction to never be violated
Great!!! A big part of the value here is the clear and complete explanation, with pointers to external references. May I ask you how do you perform the part:
“All these artifacts are commited back into the master and a version is applied. I also have a CHANGELOG.md which is automatically filled from commit messages (I used conventional commits to format my commit messages)”
I have done something similar, and have also successfully used the outputs with JLCPCB's assembly service, if you want something similar that's been tested and works:
Does anybody know something like a translator tool between all the different `yaml`s different CI/CD services use? Or maybe some metalanguage specifically made for that that can run instead of whatever hell dash/bash is.
I wish I could just jump ships altering a `script` tag in whatever `yaml` from whichever service.
Side note: where do people get their high-res, beautiful STEP models for renders? I use componentsearchengine but it's rare they have decent models for anything other than the primitive components.
I use what I can find on step files. Grabcad sometimes or directly from the component maker.
The render on my page is however a bit more work. I graft textures over the parts and set material properties such as reflections. I will do a write up on it when I get a chance.
This is very cool! As person doing small scale PCBs in a previous life, might just try to make things set up with my repo similarly (though have to find it first, might be in GitHub, so the idea would be the same but the tooling somewaht different).
One thing that makes me wonder all the time are CI/CD runs that commit back to the repository. That feels weird for some reason I cannot articulate very well yet, but makes me think there should be a better way. Especially if the results are artefacts like that. Any experience by others to weigh in?
I found KiBot configuration a bit overwhelming and with the addition of the ‘kicad-cli’ tool in KiCad 7 made a Makefile based runner: https://github.com/tuna-f1sh/kicad-makefile
It allows for a build that is closer to the vanilla KiCad GUI experience and can be built locally with the normal install using ‘make’ - something I wanted.
I'd also recommend submitting this as an example use of kibot to the kibot repo on GitHub.
Kibot is really long on functionality - the maintainer is someone in South America who does a pretty incredible job of maintaining it and integrating commonly used plug-ins.
The one thing it really lacks is a comprehensive starting example of how to use it and structure a YAML file.
I had it set up as a CI job for a while, but I ended up disabling it for a few reasons, the main one being that I just don't think it's a good idea to constantly create build artifacts for circuit board designs. It has created problems when people have circulated intermediate schematics generated by CI that don't match the hardware we built.
You really only need to archive fab packages (by which I mean schematic, gerbers, BOM, assembly drawing, fab notes, etc) at the points in time where you fab and assemble a board.
Creating more artifacts just creates the possibility for more noise. It's not like software CI as there's not really a way to automate hardware testing in a CI server. Very little incremental value in continuous artifact generation as a result.