kicad-developers team mailing list archive
-
kicad-developers team
-
Mailing list archive
-
Message #03278
Kicad libraries for pcbnew
-
To:
kicad-devel@xxxxxxxxxxxxxxx
-
From:
"viking632" <univind-kicad@...>
-
Date:
Thu, 08 Oct 2009 20:16:24 -0000
-
User-agent:
eGroups-EW/0.82
I've been working on some pcbnew (physical package) libraries for kicad.
It started with me needing some package shapes that are missing
in the kicad libraries, but it quicky turned into an ambition to
create a complete and consistent set of package shapes for the
various component classes (DIP, pinarray, SOIC, QFP, QFN, PLCC,
BGP, chip, ...).
The parts are defined 100% using scripts (perl :-), based
solely on component dimensions and recommended land patters,
gathered from datasheets from various sorces on the web.
This approach greatly reduces the workload when defining hundreds
of parts, and also reduces the efford of changing something - just
change the code and/or the package dimensions and rerun "make" :-)
Each component consists of four shapes:
The (pads or pins) land pattern (DIL/QUAD/... pattern),
the package outline for the silkscreen, and for the 3D view, there's
a package 3D shape and the (SMD or throughhole) 3D pin shape(s).
The exact size, etc. of these shapes is controlled by the
component class, the package name (in some cases) and size
(# of pins), and of course, all the other package dimensions.
The code to define these four shapes (land pattern, silkscreen
outline, package 3D shape and pin 3D shapes) is pretty simple,
and can in many cases be shared between several package classes.
Also, adding an extra component to a class is pretty simple
- the component only needs a package name and its dimensions,
usually only a single line of text (or in some cases, even less :-)
Oddly or irregularly defined classes, such as TO and SMT will need
a little more code and/or specs per package, but it's still doable.
Dimensions are hierarchically defined, so dimensions that are
identical to all components in a class needs to be defined only once.
The code isn't quite ready for publication yet, but as an example,
here's perl module DIP.pm, that defines the DIP and SDIP packages:
DIP.pm:
# DIP/SDIP packages
package PCB::DIP; use Carp; @ISA = qw(PCB::Class);
sub setup { my($this,$name) = @_; my($N,$e,$Z) = $this->get(qw(N e Z));
$this->set(A => $e*$N/2, B => ($Z == 300) ? 260 : $Z-$e);
my $ty = ($Z == 300) ? 500 : 750;
$this->inlib(1,$name,'VAL**'); $this->onboard(1,$name,'VAL**');
$this->attr(Po => "0 0 0 15 00000000 00000000 ~~", Li => $name,
Cd => "$name $N $e", Kw => $name, Sc => '00000000',
Ar => "/00000000", Op => 'A A 0'); }
%PART = ('' =>
'unit=mil silk=DIL($A,$Z-$e) pins=DIL body=DIL($A,$B,$H,$h,7,20)'.
'pin3d=DIL(($Z-$B)/2,$H/2+$h,130,$d,$w1,$w2) lw=120',
DIP => 'e=100 Z=300 Pad=630 Dr=203 H=130 h=40 d=20 w1=40 w2=60',
SDIP => 'e= 70 Z=600 Pad=440 Dr=236 H=130 h=40 d=20 w1=30 w2=40');
@PART = qw(DIP4 DIP6 DIP8 DIP14 DIP16 DIP18 DIP20 DIP22 DIP24 DIP28
DIP6M4::Z=400 DIP22M4:Z=400 DIP24M6:::Z=600 DIP28M6:Z=600
DIP32M6:Z=600 DIP36M6:Z=600 DIP40M6:::Z=600 DIP42M6:Z=600
DIP48M6:Z=600 DIP52M6:Z=600 DIP64M7.5:Z=750 DIP64M9:Z=900
SDIP30:Z=400 SDIP42 SDIP52 SDIP56 SDIP64:Z=750);
---
Originally, I hadn't included the 3D shapes, but the VRML files
used by kicad needs only a very small subset of the VRML
language (only "IndexedFaceSet"s are used :-), so adding
scripted definitions of the 3D shapes was actually pretty easy.
I've "uploaded" my progress so far to
http://www.uni-c.dtu.dk/~univind/kicad/
For easy download, the file kicadlibs.tgz
contains a tar archive with all the files.
For each library, there's a pcbnew library (the .mdc and .mod
files) and a sample board (.brd) containing all the components.
For each class, the .dim file contains a table of the dimensions
of all the parts, useful for double-checking, especially of
dimensions that have been calculated (based on other
dimensions, and in some cases, the package name).
The .wrl files with the package 3D shapes are in packages3d/oaa/.
Note: As I said, this is work in progress, so there's lots
of stuff missing, especially in the 3D shapes department,
as the 3D stuff got added recently (about a week ago).
Also, a few of the components aren't quite right, but that'll be
corrected as soon as I get around to double-checking the package
dimensions - this is one of the reasons why I added the .dim files :-)
Some of the 3D shapes are also currently based on incomplete data,
instead using hardcoded "constants", as some of the 3D shape
dimensions haven't been entered yet - I've "cut a few corners"
there (4 now :-), to have something to present to y'all ...
Øyvind.
******************************************
Quidquid latine dictum sit, altum viditur.
Follow ups