Searchable KiCad Component Database Makes Finding Parts A Breeze

KiCad, the open source EDA software, is popular with Hackaday readers and the hardware community as a whole. But it is not immune from the most common bane of EDA tools. Managing your library of symbols and footprints, and finding new ones for components you’re using in your latest design is rarely a pleasant experience. Swooping in to help alleviate your pain, [twitchyliquid64] has created KiCad Database (KCDB). a beautifully simple web-app for searching component footprints.

The database lets you easily search by footprint name with optional parameters like number of pins. Of course it can also search by tag for a bit of flexibility (searching Neopixel returned the footprint shown above). There’s also an indicator for Kicad-official parts which is a nice touch. One of our favourite features is the part viewer, which renders the footprint in your browser, making it easy to instantly see if the part is suitable. AngularJS and material design are at work here, and the main app is written in Go — very trendy.

The database is kindly publicly hosted by [twitchyliquid64] but can easily be run locally on your machine where you can add your own libraries. It takes only one command to add a GitHub repo as a component source, which then gets regularly “ingested”. It’s great how easy it is to add a neat library of footprints you found once, then forget about them, safe in the knowledge that they can easily be found in future in the same place as everything else.

If you can’t find the schematic symbols for the part you’re using, we recently covered a service which uses OCR and computer vision to automatically generate symbols from a datasheet; pretty cool stuff.

15 thoughts on “Searchable KiCad Component Database Makes Finding Parts A Breeze

      1. Generic footprints for generic packages are fine but it is nicer to have a specific footprint for a specific part. These can include not just numeric pin labels but functional ones too as well as default labels that actually name the part.

  1. How will this break when 5.0 launches proper? It seems sad timing to introduce this tool now, when library and part management will see significant changes very soon…

    1. KiCad 5 doesn’t introduce that much new stuff to the library formats: symbols can have longer pin numbers, and there are a couple footprint pad types added. And it’s in feature freeze already, so there shouldn’t be any breakage to the file format at this point.

      It doesn’t look like this renders things very accurately yet though (check out SOT-89-3: pads 1-3 are shorted on the left-hand side, and the trapezoidal pads aren’t drawn at all), so I’m not worried about 5.0 possibly confusing it.

    2. I’m already ingesting kicad-library parts, which are version 5.

      There are a very small number of parts which dont ingest correctly, but thats mostly due to obscure directions in the footprint (ie: zone_connect). These can be fixed as I find out about them.

    3. If you mean this, where’s the “significant” change?

      All that is saying is a few more features (pad shapes, Eagle import). It’s not even breaking, old libraries should still work. I wouldn’t say it’s “sad timing” either to release an open source tool that will only need small tweaks to support the newer stuff fully (visual glitches may be seen in the interim on any new pad shapes) while readily working on the old stuff. GitHub makes pull requests and forking dead easy, making an update won’t be hard even if the dev abandons it.

      Unless you know something I don’t. If you do, please share! Here to learn :-)

Leave a Reply

Please be kind and respectful to help make the comments section excellent. (Comment Policy)

This site uses Akismet to reduce spam. Learn how your comment data is processed.