kicad-developers team mailing list archive

[Werner Almesberger <werner@...>]

We're getting a bit off-topic and I don't want to hijack the PCB units
thread, so I broke the thread and started a new one.

I think the question of how we really make our footprints has
implications on a number of area that are currently being worked on,
and I think it would be good to have at least a rough idea in which
direction we want things to evolve.

vladimir_uryvaev wrote:
> Analytics brings cad more close to geometric software than to electronic. :)

Very true :-) Just a few days ago, I ended up giving up on QCad and
using fped for a technical drawing that was based on a lot of
measurements that had to be redone/refined several times.

> But I agree that some sort of them may be usable. For example is would
> be handy to store footprint generayion algorithms in library instead of
> tons of drawings of all these SOICs, SSOPs, MSOPs, QSOPs, MLFs and BGAs.

Yes, exactly. I'm also a bit concerned that the current efforts at
revamping the library handling may center around a format that
doesn't really represent the true source of a design.

Let me explain. There at least the following methods how people make
their new modules today:

- with KiCad's module editor

- with some homebrewn scripts, in a number of different languages
(I've seen Perl and Python mentioned, there may be more)

- with a specialized tool external to the KiCad project, e.g., fped
or http://kicad.rohrbacher.net/quicklib.php

I could imagine that some may also do it

- in some other EDA system, then convert to KiCad

Did I miss any other methods ?

Now, while it's good to be able to choose the best tool for a job,
this can become a problem if a lot of information gets stripped in
the conversion to the common format. (Be this KiCad's current
module format or Specctra DSN.)

E.g., imagine you pick some BGA from the module library just to
find that one of its dimensions is slightly off. Let's say the BGA
was originally made with quicklib.php

Your choices would then be to 1) try to live with the mistake, 2)
make the correction in the common format, or 3) try to identify the
original source and re-generate the footprint with corrected
parameters.

If choosing 2), any limitation of the common format the original
author avoided by using a different tool then comes back to haunt
you.

If choosing 3), you depend on having the origin properly documented
(what tool was used, with which input files, etc.) and having the
ability to use the respective tool. The latter can get tricky, e.g.,
if it's a script written in a language you don't know (yet) or that
doesn't even exist on your system, or it's a tool that's complex to
use and that you're not familiar with (yet).


To sum this up, if the format we use for sharing footprints is less
expressive than the preferred format for defining them, this can
easily create a major and possibly surprising burden for end-users
wishing to make even small changes.


This mail is already quite long, so before talking about possible
solutions and such, perhaps we should first see if we agree that
there is indeed a problem that we should try to solve ?

- Werner