Open bootchk opened 8 years ago
Seems overly complicated. Why not just do:
thermalPad = new Smd thermalPad.dx = .7 thermalPad.dy = 1.6 thermalPad.name = 4 combine [name, value, l, thermalPad, silk, c]
you can make a 5-pin sot23-5 by using remove, something like this:
l = dual [pad,d], 6, e, between l = remove l, 5
Re: thermal pad. You're right, that works.
Re: sot23-5. Yes, but sot23-5 doesn't have staggered pins on the right, just a missing pin. I was thinking that sot23-3 might be the inductive base case for n=3. For n = 9 you might get a very old connector called DB-9 (used for serial ports, 5 pins on left, 4 staggered pins on the right), although I don't know whether the solderable pins of the connector are in that same pattern. So maybe not useful, just generic.
Re thermal pad again. What I think the beauty of mad parts is: its almost declarative, instead of procedural. You call it functional, I'm not sure if you mean 'procedural' or the sense of 'functional programming' that is, stateless. When you call remove(), it is operating on the state of the footprint. Anyway, remove() is convenient, but I think you could try and hide it. And define more functions like dualStaggered() or dualWithThermal() so that a user is declaring the pattern of the footprint without knowing how it is implemented (by append or remove.)
Again, many thanks, I think KiCad should adopt mad parts.
Hey,
while I understand your sentiment, having created 100s of parts with madparts now, I just find that going beyond the basic single/dual/quad etc is just not very practically as modern footprints are almost all custom. That being sad, I'm happy to add more functions to the build-in functions of madparts if they are named nicely and don't sit in the way. Even between different chips the footprint requirement for SOT23-5 might be different... And when you move into more advanced footprints you even have custom paste layers for the thermal pad that are chip dependant etc etc. "remove" is functional because it returns a new list that has the item removed isof modifying the list in place. Finally about kicad adopting madparts... I don't know. Keep in mind that for many people madparts is wierd/niche. Most people don't think so well in code and prefer using a mouse to make footprints. I do think kicad is improving their plugin system so a madparts plugin might be possible one day :)
Returning to pragmatic question: how to do a thermal pad. My attempt does not generate paste:
# Thermal pad
# drill > 13 mil OSHPark minimum
drill = .33
thermalPad = new SquarePad 2, drill
thermalPad.dx = .9
thermalPad.dy = 1.6
thermalPad.name = 4 # same net as ground pin
thermalPad.paste = true
The point is, the pad should be drilled, and have unmasked copper on both sides, and solder pasted on the front. I worked around by editing the footprint in KiCad and choosing 'F.Paste' layer checkbox. So this is a request for an enhancement: to let through hole pads be pasted on one side in mad parts, or to let SMD pads be drilled. I could be wrong, maybe there is already a way to do this. (Or since I need it, I should contribute it.)
Background: it seems like packages are trending smaller. For example WSON and CSON package families (wafer scale and chip scale small outline no lead) the parts have a thermal pad that should be soldered to a ground plane on the front or enclose vias to an exposed copper layer on the back, whose purpose is to transfer heat from power transistors. (As always, there are many variations. Some packages may be similar to BGA and have solder balls not needing paste. Some may be logic parts and the thermal pad need grounding but not really need a heat transfer via. Some packages suggest multiple drills in the thermal pad.) Typically, the thermal pad is not numbered or defined in the pin function table, but almost always grounded.
.paste = true is not implemented for non-SMD parts. It was added to allow non-paste SMD pads like programming and test pads. I'd be happy to accept an enhancement that fixes this and allows paste=true for non-SMD parts. It seems useful indeed. So far I've always just added vias in the pad directly in kicad.
Is there an existing example of generating a thermal pad?
For example, Texas Instrument package named DSG, also called WSON-8. It has 8 pads plus a thermal pad usually grounded. I know that if you give a pad the same number as another pad, KiCad treats them as two portions of the same electrical node. In this case the thermal pad could be numbered 4 (which is a regular pin that is Vss ground). Or you could number it 9 and treat it as a additional pin.
I have an idea that I could write a coffee func that generates a centered thermal pad, where the dimensions of the thermal pad, and the number (ordinal) for the pad, would be parameters to the func. For example: dualPlusThermal( [pad], 8, pitch, betweenPinCenters, thermalPad, 4)
(I already wrote a function dualOffset() that generates two rows of pins, with the right row offset vertically, and an odd number of total pins. Useful for generating SOT-23-3, the standard transistor package, which is a left row of 2 and an offset or staggered right row of 1. I can contribute it if you think it useful.)
Thanks. madparts has some great ideas: To use the 'prototype inheritance' of JS . To make the language declarative (you describe a package, not write a procedural program, except internally).
Follows is my existing code for thermal pad (seems to work.) I guess I answered my own question, but I think that it should be a coffee func, to hide the procedural aspect: you must rename the thermal pad AFTER you put it in a group?
...
group of regular pins
l = dual [pad], 8, pitch, betweenPinCenters
Thermal pad
thermalPad = new Smd thermalPad.dx = .7 thermalPad.dy = 1.6
Group for thermal pad has one pad
thermalPadGroup = single thermalPad, 1, 1
Rename thermal pad same as ground pin named 4
thermalPadGroup[0].name = 4 .... combine [name, value, l, thermalPadGroup, silk, c]
(But next I need to add vias to the thermal pad.)