← Back to team overview

kicad-developers team mailing list archive

Re: Henner's component chooser for CvPcb...

 

On Mon, Feb 24, 2014 at 10:35:57PM +0200, Vesa Solonen wrote:
> I'd say this is the worst of the bad choices. Packages are standardised
> as are pin numbers so there is no question of mangling the footprints.

Not always... while for example (these days at least :D) mosfets always
follow the GDSD mapping for SMD packages (there are technical reason:
the drain is thermally bonded), and usually SOT-23 diodes are standard
too (singles and doubles, like the BAT54 variants) other components
don't always follow the same conventions, or there isn't a standard way
of numbering pins. In the past all the 6 permutation of SOT-92
transistors were in use :D Even today there are discretes available in
a 'reversed' pinout for layout purposes so you wouldn't bet on a mosfet
being always GDSD :P

Other example: relays always have A1/A2 as coil contacts but the same
package has the contact pins named 11/12 for the B-form (NC) or 13/14
for the A-form (NO). Now look, for example, at set of safety relays, all
with the same package and various contact configuration with 4/6
contacts :P the Schrack SR6 are four kind of relays with the same exact
package but different pin numbers...

Other components with numbering often quite evil are board-mounter
transformers; the common one are usually 1-7 and 8-13 but when you have
taps or multiple windings, good luck. These things have pin selectively
populated and the pin positions gives polarization, too.

On the converse often ICs have different pinout for different packages.
Like SOIC 14 and SSOP 16. Signal and pin numbers don't match in this
case :D in some case there are even signals omitted (like RS232
transceivers which omit the charge pump ready signal on the smaller
packages).

>From a strict data modeling standpoint then you should have:
- The part, in general, with pin names and 'part-pin's
- The package with the real 'pin-number's
- The variant (part many-to-many package) containing the pin mapping
  (part-pin zero-or-one-to-one pin-number)

(sorry if it's not neither exactly E-R or collection based:P)
This doesn't model the signal omitted case because it's too dangerous
and it's often a slightly different part number anyway (the last
relationship would be zero-or-one-to-zero-or-one; good luck with the
DRC).

Is this overkill? IMHO yes. I currently work without too many issues
duplicating the few packages needing it (mostly SOTs and TOs), with the
infamous SOT23-123/SOT23-GSD/... technique (about 6 for that particular
package) and naming conventions on the eeschema side, like LTCxxx_SO14
and LTCxxx_SOP16.

A good compromise would be having different sets of pin names for
a package: the base is the SOT23 and the pins get named 123 or GSD or
whatever depending on a variant code or something. For something which
usually is generated *once* and never touched after that is a lot of
implementation work to do. Of course volunteer work is always accepted:D

-- 
Lorenzo Marcantonio
Logos Srl


References