kicad-developers team mailing list archive

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

--- In kicad-devel@xxxxxxxxxxxxxxx, Vesa Solonen <vsolonen@...> wrote:
>
> I didn't choke on black powder smoke and still have most of my hearing 
> left (cheated a bit by using half plugs...) so back to business. 
> Also congratulations for the release, everyone!
> 
> On Tue, 23 Mar 2010, viking632 wrote:
[]
> > I've renamed the resistors yet again, now they're called R-{IM}<pitch>,with an optional 'V' on the end
> > (Vertical mount).
> > This groups all the resistors nicely together in cvpcb :-)
> 
> Very nice. I'm not too concerned about the changes yet, as I have not 
> started the automatic symbol-footprint bridge. Feel free to change as 
> much as you like ;) I'll ask before doing a pull to KiCad official 
> distribution anyway and this may be somewhat further away than next month. 
> I'll have to finalize some pending problems on symbol side too.

I think I've gotten the resistor names correct this time - they're clustered nicely together in cvpcb, and they're easily identifiable as resistors :-)

There are many many more packages to add, so yes, it'll take a wee bit before the libs are ready for release ...

> > > That pin mapping functionality is not yet there, but if those with greater
> > > coding skills agree with my proposal it will be some day. Along with pin
> > > swapping, etc. That's my long term goal anyway. Footprint library should
> > > just stick to the standard numbering and nothing else. Otherwise the
> > > system is a mess after a while. Anyway it's few clicks of work to change
> > > schematic symbols pin numbering, so that should be the way.
> > 
> > Off hand, I can only think of transistors that needs pin mapping,
> > but yes, it would be very nice to have (any volunteers ?-)
> 
> Blue sky ideas here:
> http://tech.groups.yahoo.com/group/kicad-devel/message/4421
> 
> I'm aiming a bit further than just discrete transistors pin mapping, but I 
> already know I'm not capable of pulling it myself. Other commitments, 
> etc... So I can not take enough time to learn everything needed. But I'm 
> willing to put my effort where my skillset applies better as is.
> 
> Some more examples would be freely selected resistors grouping to resistor 
> array and two terminal unpolarsed components that would convey the pin 
> freedom to layout side too. Say, single inductor is most of the time 
> unpolarised, but may have unsymmetrical pinout or pads that will make 
> better layout if swapping is allowed (currently rigid connections).

Ah, yes, great ideas.

I need to use some Vishay Si4850 MOSFETs, which are in a SO8 house.
It uses four pins for Drain, three for Source and one pin for the Gate.
Is there a way to map such a thing (one pin == multiple pads), or do I need to define an 8-pin part in eeschema ?

> > Done :-)
> 
> Way too fast :D

It only took two extra attributes (package orientation, and a common mounting height), 5 more lines of code for the silkscreen, 4 lines for the pads (thermal and mounting hole), 3 lines to move/rotate the body into place, and9 lines extra to define the extra bend on the pins, so only 21 lines more - piece of cake :-)

> > I've added three variants: Heatsink up, heatsink
> > down w/o pad and heatsink down with (SMD) pad.
> > In all three cases, there's also a mounting hole on the PCB.
> > I've added all three variants for all the TO-PPs (Plastic
> > Packages), even the fully isolated ones, but I'm thinking
> > that maybe we could skip the padded variant for those ?
> 
> IMO the padded version is useful there too. If someone wants to use 
> internal (gnd/power) layers as a heatsink, but needs the isolation. Maybe 
> you agree?

I was thinking that, for isolated packages, the padded version isn't of much use, as any copper plane (top layer) below the part doesn't _have_ to be connected to the middle pin net.
If you already have a copper plane there, you don't really need the thermalpad, in fact, it will usually be in the way, because it's connected to thewrong net.
For internal layers, the thermal pad doesn't make any difference, as the pad is on the top layer only (SMD pad).

Another thing: Right now, the mounting hole pad is connected to the middle pin on all packages, but I think I'll change that to '' on the isolated packages, as the mounting screw doesn't have any electrical contact with the part.

If we need to keep the padded version of the isolated packages, I think I'll do the same with the thermal pad, if a pad w/o name can be connected to anything (incl. being made part of any copper area) ?

> > I haven't added horiz versions of the TO220-5R (PentawattV)
> > and TO220-11R, as these have already had their pins bent.
> > I can add them if you like ?
> 
> Like very much. Also the housing TDA1562Q comes in, DBS17P or SOT243-1 
> would be nice. The package may also be fitted horizontally by some 
> bending, but I have no dimensions to give yet. Maybe they are deduceable 
> from the data sheet. Reverse horizontal would be very usable layoutwise. 
> The chip is EOL, but very handy for ultra simple USB subwoofers for in car 
> use (or under the working desk, just pull 12V from the desktop). An old 
> USB VoIP handset (8ksps) with PulseAudio+LADSPA Linkwitz-Rileys @60Hz 
> feeding TDA1562Q ;) To be designed with KiCad, naturally... Even crappy 
> strereo pair and amp sounds good when the bass induced intermodulation 
> distortion is gone. This surprised me very much some years ago when the 
> whole setup was an analogue dead bug construction. Even the boss came 
> looking after the good sound and not to demand the volume down :D
> 
> > I've also added a horiz version of the SIP3 and 4, but I'm not
> > sure if they're useful. Let me know if I should keep them ...
> 
> Keep. They may be sandwiched between the PCB and heatsink (or housing?) if 
> needed. I'm quite sure someone will find some use for them some day in 
> some project... Hobbyists can do all kinds of unconventional stuff that no 
> one can imagine beforehand. Old weird components no one would use 
> commercially, etc. If supporting such will take almost no additional 
> resources, let's support it.

I'll add those to a powermodules library, and I think that I'll move the TO220-5* and TO220-11* to that lib as well - they don't really belong in the discrete/transistors section, although they do look like multipin transistors.

I'll add horiz versions of the TO220-5* and TO220-11* as well, after I've taken a look at the pin geometry (bends) - it's best to reduce the number of(re)bends as much as possible ...

I'll also add horiz versions of the TO92, and maybe some/all of the metalcan packages as well (but not the TO3s :-).

> Thank you again for your work.
> 
> -Vesa

Øyvind.