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.
Now add an indexer that will automatically harvest libraries from GitHub and Google searches.
Commits welcome :)
not finding any results for “lm317” and “bc237” kinda makes me wonder, though…
Because both are chips and not packages? SOT-223 or TO-220 are the packages for the LM317.
examples: WS2812b
reading isn’t that hard, is it?
led packages aren’t standard like other chip packages.
oh but the 7805 is?
you’re losing this argument.
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.
Add part creation wizards ala kicad librarian (and maybe schematic library mode as well) and you’ve got the perfect tool. I’ll take a look at this later as I’m in the process or sorting out my library.
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…
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.
Yeah, Ive been having some difficulty mapping part co-ordinate space to screen co-ordinates :/ If you have any idea where this is in the codebase, please let me know or submit code.
I dont support trapezoidal pads yet, but they can be trivially added to https://github.com/twitchyliquid64/kcdb/blob/master/static/js/view.js#L111
This is me from future (2021), it worked for me with KiCad 5. Also… ehm… something terrible is going to happen around 2020.
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.
If you mean this, where’s the “significant” change?
https://hackaday.com/2018/02/10/whats-coming-in-kicad-version-5/
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 :-)