Library suggestions - to be published later (semi-KiCad)

[c4757p]

I haven't posted this in the KiCad section because my specific question here doesn't directly relate to it, it's more of a general library design question.

I've generally been very unhappy with the libraries available for KiCad (including their own sucky one), so I've spent quite a bit of work putting together my own. I'm getting around to the final stages of cleaning it up properly, and I'd like to publish it online (both to my own website and to kicadlib.org). While I'm working on polishing it, does anybody have any suggestions? Here's what I've done so far (at least, what I thought to list):

- For a consistent look, text size, line width, etc. are standardized throughout both the schematic and PCB libraries, enforced by a test script run by the Makefile.
- Derivative components (e.g. PN2222 derived from NPN) are created from a list by a script run by the Makefile, to ensure both consistent symbols and easy changes across the entire library.
- Includes a script to download the free IPC land patterns from FreePCB and convert them to KiCad format, adapting the style and linking to 3D models when available.
- PTH footprints are validated for a set of drill sizes and a minimum annular ring.
- Schematic/PCB association is more like professional EDA packages: unless you use a template part like "NPN", footprints are always associated properly with the schematic parts and can be quickly linked with the auto-assign feature, skipping the footprint selection stage. If you really like doing things the "KiCad way", you can always use the template parts directly.

Anything else to ensure a good, high-quality and consistent library? (Oh, and apologies for overusing the word "consistent" like it's a marketing buzzword...)

[McMonster]

I've been looking for a decent complete replacement for KiCAD's standard libraries for ages. It's great you bothered to make one.

You didn't actually say anything about the contents of the library, I'm curious what is included beyond the most standard and common stuff. Particularly the connectors always annoyed me, they're a pain in the ass to draw.

Did you create any documentation or at least the basic PDF with all footprints in 1:1 scale? This is useful for confirming you have the right footprint for a part. About the footprints, what do they default to, SMD or THT? Did you include proper footpint filters in the parts too? And lastly, do you have a consistent naming schemes for both footprints and parts?

[c4757p]

I don't have a very large collection of connectors, because I don't really use too many different ones myself and wouldn't know where to start. I'm happy to take requests, though. In the beginning while the library is still somewhat small, I'd like to put a "request box" on the web site, and just sort components by popularity and add them. This is meant to replace KiCad's standard library, so in terms of "completeness", it's supposed to have a usefully complete selection of a broad variety of components. I'm not too interested, for instance, in collecting the entire Atmel repertoire, but I've got pretty much every basic part, from resistor networks to P-channel JFETs to the 7400 series.

On the to-do list is a program to render schematic symbols and footprints to PNG (for browsing the library online) and the PDF, as you mention. One of the places where I'm putting the most emphasis is on scripting everything that I can, to ensure consistency, because consistency is one thing that is horribly lacking in KiCad. I'm not just going to throw the footprints onto a PDF myself, that leads to the PDF becoming outdated. That'll probably take a few days to do correctly.

All parts do have proper footprint filters. Like I said, I'd like to eliminate the CvPcb step to the point where you can just click "Perform automatic footprint association". This means using separate schematic parts for different footprints, so each part has exactly one footprint listed, more like every other EDA package out there rather than like "the KiCad way". These are all generated automatically from a template part, so if you like the KiCad way you can just use the template parts. Template parts also have filters, I haven't neglected that. There's no SMD/PTH "default", you can either place SMD or PTH parts. I'm trying to include as much as possible, but there's definitely a bias towards SMD because that's what I use almost exclusively.

I am trying to keep naming schemes as consistent as possible. I haven't actually written rules for this yet, but I plan to.

[Bored@Work]

From what I read, it sounds like a reasonable plan and a reasonable way to do it.

Will the plan work out? Well, your target group is a bit unpredictable, so IMHO the only way to find out is to do it and start offering the library. Folks have to see it and work with it in order to judge if it is better to use than KiCad's default library.

[ElektroQuark]

Do you need some betatesters?

[c4757p]

I'm currently implementing some sweeping structural changes from the way I had the library set up before, so I'd say it'll be a bit pre-beta for a couple more days. Once I get the file/naming structure reasonably stabilized, I'll upload the git repository and anyone can use it and bitch about it at their own risk. (Which is riskier is for you to find out  )

[McMonster]

Loosing my hair trying to use standard library is much riskier.

More questions, you mentioned you aren't trying for example to provide a complete list of Atmel micros. Are you providing only generic parts? I'm asking because what KiCad provides for transistors and AVRs recently is actually pretty useful in my opinion. Does your library cooperate with those, like in pin spacing? I've seen libraries that use some odd values for pin spacing and mixing them into anything looked really bad. Being able to reuse what was already created, to a reasonable extent, is important too.

[c4757p]

More questions, you mentioned you aren't trying for example to provide a complete list of Atmel micros. Are you providing only generic parts? I'm asking because what KiCad provides for transistors and AVRs recently is actually pretty useful in my opinion.

I'm placing an emphasis on generics and common parts. I've tried to include lots of "standard" part numbers (1N4148, 1N5819, 2N3904, etc. + SMD equivalents). I can't really say "only", since I use this as my personal library, so it includes nearly every part I've used in the past. I don't want to be sparse compared to KiCad's default, so I'll probably at least try to match what they have.

Atmel was probably a bad example - PIC and AVR are both so popular with hobbyists that I am considering them. Still, don't expect every EEPROM Atmel's ever made and every op amp Microchip's ever made.

Does your library cooperate with those, like in pin spacing? I've seen libraries that use some odd values for pin spacing and mixing them into anything looked really bad. Being able to reuse what was already created, to a reasonable extent, is important too.

Hard to say what exactly you're asking. I've actually seen a handful of KiCad libraries that went off the standard 50 mil grid! Hell no, I won't do that. But when I started building the library, one of my big gripes with the KiCad parts was that they were all so large that I could hardly fit anything on a page, so most things are smaller (or at least have shorter pins).

[c4757p]

One point I want to make, since I don't think it was clear: this is still a good way off. Probably a month or so. I've got a lot more parts to compile, some more code to write, still haven't put the web site together, and I have a couple more projects ongoing as well. I just wanted to get any big "applies to the whole library" suggestions in before I accumulated a lot of work that had to be undone to implement them.

[c4757p]

Update: Anyone who thinks KiCad is well designed internally, try writing a program to render libraries to images. Looks like they had a different six-year-old write the syntax for each drawing command... How many different ways can you spec an arc segment??