kicad-developers team mailing list archive

["viking632" <oyvind.aabling@...>]

--- In kicad-devel@xxxxxxxxxxxxxxx, Werner Almesberger <werner@...> wrote:
>
> 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

I'm working on a new set of part libs for kicad, generated by perl
code, which IMHO is _much_ more versatile than any shell language.

See http://tech.groups.yahoo.com/group/kicad-devel/message/3358
and followups.

Why perl ? Well, perl has everything you need: Object Oriented
programming, anon arrays and hashes to stash stuff into, very
powerful regexps, automatic housekeeping for vars and values, etc.

Also, I've been writing tons of perl code over the last 13+ years,
so this was a natural choice (just ask anyone who knows me ;-)

If it can't be done in perl, use C. If it can't be done in C,
use assembler, and if it can't be done in assembler,
it obviously isn't worth doing :-)

As to the presense of a recent perl interpreter, all
the systems I know of has one included by default these
days (*), and my PCB parts code doesn't make use of anything
special, so any perl 5 installation should do just fine.

(*) And if not, perl is available for all major platforms,
although Windooze does require cygwin, I think (but then I
generally try to stay as long away from M$ as possible ...).

To define a part, my approach uses only the class and physical
dimensions of the part (including the land pattern) as input.

Obviously, there's also some perl code for each type of silkscreen,
footprint layout and 3D body and pin shape to define the parts.

Along with the parts, each part class generates a dimension table
(with a nice legend for each value), for checking of values.
So, if a dimension is wrong, simply correct it and do a remake :-)

There are probably mistakes in my libraries, as they are
mainly based on datasheets found on the internet, and some
of them don't quite agree on the exact sizes of components,
or the recommended land patterns, but any inacurracies
(or wrong choices on my part) should be pretty easy to fix.

I've also considered a GUI interface to allow building your own
parts - the name pcbbyol (Build Your Own Lib :-) springs to mind.

The toplevel code will need a little restructuring, but the
bulk of the code, i.e. the part classes and general code for
silkscreen, footprint and 3D shape generation can be left untouched.

If a particular part is missing from a class (or slightly wrong),
only its class and (correct) physical dimensions needs
to be entered, but new part types/classes will generally
require some code as well, especially for the 3D stuff.

Øyvind.