In the desktop 3D printing world, we’re fortunate to have multiple online repositories of models that anyone can load up on their machine. Looking to create a similar experience but for electronic projects, [Mike Ayles] created CircuitSnips — a searchable database of ready-to-use KiCad schematics available under open source licenses.

Looking for reference designs for LiPo chargers? CircuitSnips has you covered. Want to upload your own design so others can utilize it? Even better. Currently, there are over four thousand circuits on CircuitSnips, although not all have been put there purposely. To get the project off the ground, [Mike] scrapped GitHub for open source KiCad projects. While this doesn’t run afoul of the licensing, there’s a mechanism in place for anyone who wants to have their project removed from  the repository.

To scrape the depths of GitHub, [Mike] had to simplify the text expression for the KiCad projects using a tool he’s since released. For anyone so inclined, he’s even put the entire site on GitHub for anyone who wants to try their hand at running it locally.

CircuitSnaps fills a very specific space to post your circuit diagrams, but if you’re looking for somewhere to host your complete designs, we can’t fail to mention Hackaday’s own repository for hardware projects and hacks!

As the saying goes: if it has a processor and a display, it can run DOOM. The corollary here is that if some software displays things, someone will figure out a way to make it render the iconic shooter. Case in point KiDoom by [Mike Ayles], which happily renders DOOM in KiCad at a sedate 10 to 25 frames per second as you blast away at your PCB routing demons.

Obviously, the game isn’t running directly in KiCad, but it does use the doomgeneric DOOM engine in a separate process, with KiCad’s PCB editor handling the rendering. As noted by [Mike], he could have used a Python version of DOOM to target KiCad’s Python API, but that’s left as an exercise for the reader.

Rather than having the engine render directly to a display, [Mike] wrote code to extract the position of sprites and wall segments, which is then sent to KiCad via its Python interface, updating the view and refreshing the ‘PCB’. Controls are as usual, though you’ll be looking at QFP-64 package footprints for enemies, SOIC-8 for decorations and SOT-23-3 packages for health, ammo and keys.

If you’re itching to give it a try, the GitHub project can be found right here. Maybe it’ll bring some relief after a particularly frustrating PCB routing session.

[Andrew Greenberg] has some specific ideas for how open-source hardware hackers could do a better job with their KiCad schematics.

In his work with students at Portland State University, [Andrew] finds his students both reading and creating KiCad schematics, and often these schematics leave a little to be desired.

To help improve the situation he’s compiling a checklist of things to be cognisant of when developing schematics in KiCad, particularly if those schematics are going to be read by others, as is the hope with open-source hardware projects.

In the video and in his checklist he runs us through some of the considerations, covering: visual design best practices; using schematic symbols rather than packages; nominating part values; specific types of circuit gotchas; Design for Test; Design for Fail; electric rule checks (ERC); manufacturer (MFR), part number (MPN), and datasheet annotations for Bill of Materials (BOM); and things to check at the end of a design iteration, including updating the date and version number.

(Side note: in the video he refers to the book The Visual Display of Quantitative Information which we have definitely added to our reading list.)

Have some best practices of your own you would like to see on the checklist? Feel free to add your suggestions!

If you’re interested in KiCad you might like to read about what’s new in version 9 and how to customize your KiCad shortcut keys for productivity.

I was looking over the week’s posts on Hackaday – it’s part of my job after all – and this gem caught my eye: a post about how to make your own RP2040 development board from scratch. And I’ll admit that my first thought was “why would you ever want to do that?” (Not a very Hackaday-appropriate question, honestly.) The end result will certainly cost more than just buying a Pi Pico off the shelf!

Then it hit me: this isn’t a project per se, but rather [Kai] was using it as an test run to learn the PCB-production toolchain. And for that, replicating a Pico board is perfect, because the schematics are easily available. While I definitely think that a project like this is a bit complicated for a first PCB project – I’d recommend making something fun like an SAO – the advantage of making something slightly more involved is that you run into all of the accompanying problems learning experiences. What a marvelous post-complete-beginner finger exercise!

And then it hit me again. [Kai]’s documentation of everything learned during the project was absolutely brilliant. It’s part KiCAD tutorial, part journal about all the hurdles of getting a PCB made, and just chock-full of helpful tips along the way. The quality of the write-up turns it from being just a personal project into something that can help other people who are in exactly the same boat, and I’m guessing that’s a number of you out there.

In the end, this was a perfect Hackaday project. Yes, it was “too simple” for those who have made their 30th PCB design. (Although I’d bet you could still pick up a KiCAD tip or two.) And yes, it doesn’t make economic sense to replicate mass-market devices in one-off. And of course, it doesn’t need that fun art on the board either. But wrap all these up together, and you get a superbly documented guide to a useful project that would walk you through 95% of what you’ll need to make more elaborate projects later on. Superb!

Surely you do “finger exercises” too. Why not write them up, and share the learning? And send them our way – we know just the audience who will want to read it.