I'm fine with having extra symbols for exposed pads, as long as we are consistent in the libraries. :-P I do think it's a safer option, too.
Anyone, feel free to chime in before I add this to the library convention. On Sat, Jul 19, 2014 at 2:37 AM, jp charras <[email protected]> wrote: > Le 19/07/2014 04:53, Carl Poirier a écrit : > > Why wouldn't KiCad be able to deal with that? As an example, I modified > > a QFN48 having a thermal pad to include thermal vias directly in the > > footprint. In the schematic, I have chosen a 48pin MSP430. I assigned > > all of the thermal stuff (pin number 49, not present in schematic) to > > ground statically. Alternatively, a via can be placed manually under the > > thermal pad, as shown in the middle. They can then be connected and DRC > > passes fine. Unless I am missing something, I tend to think the only > > thing we need is that the static assignments must not go away if you > > read the netlist again. > > > > > > > > Regards, > > > > Carl > > > > > > On Fri, Jul 18, 2014 at 9:01 PM, Jean-Paul Louis <[email protected] > > <mailto:[email protected]>> wrote: > > > > Carl, > > > > This is opening a whole new can of worms. First the request is for a > > justified thermal pad that is becoming more frequent. But after > > that, I have seen request for via patterns on thermal pads. So, now > > an SMT part can be a mix of pads and through holes that can even be > > blind in some cases. > > No sure about kicad ability to deal with that. > > > > Jean-Paul > > AC9GH > > > > > > On Jul 18, 2014, at 7:52 PM, Carl Poirier <[email protected] > > <mailto:[email protected]>> wrote: > > > > > Hi folks, > > > > > > I would like to discuss this here. Very recently, a contributor > > has opened a pull request for a symbol to add an extra pin for an > > exposed pad. Kerusey then suggested to statically assign the pad to > > a net instead of having an extra symbol. This does indeed work, but > > the contributor has raised the point that every time the netlist is > > read, the static assignments have to be set again. > > > > > > First of all, is static assignment the way we should go to deal > > with extra pads? If so, how about making the static assignments > > stick through a netlist read, as long as that pin is not tied to > > another net in the schematic? > > > > > > Regards, > > > > > > Carl > > > > I fully agree with Jean-Paul Louis. > > Generally speaking, This is a very bad idea to allow a board to have > connections which differ from the schematic. > > If you want to use a QFN48 with exposed pad (your example): > > 1 - this is no more a QFN48, and you have to select something like a > QFN48+EP in your schematic. If the pad 49 does not appear in schematic, > and if you select a QFN48, you'll have no warning when reading the > netlist (minor issue, I know, but an issue). > > 2 - If the pad 49 (and its connection) does not appear in schematic, > you can easily have a bad connection, if the net name changes (for > instance using DGND for pad 37 instead of GND) you'll have a broken board. > This is a major issue. > For large boards (with hundred of footprints), it is very difficult to > see this kind of error. > > > For me, the fact a schematic component which needs a "QFN48+EP footprint > with pin 49 connected" and does not have the pin 49 shown and connected > in the schematic is just a broken schematic component. > > Therefore the request for a symbol to add an extra pin for an exposed > pad is a very good request. > > -- > Jean-Pierre CHARRAS > > _______________________________________________ > Mailing list: https://launchpad.net/~kicad-developers > Post to : [email protected] > Unsubscribe : https://launchpad.net/~kicad-developers > More help : https://help.launchpad.net/ListHelp >
_______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : [email protected] Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
