kicad-developers team mailing list archive

[Carl Poirier <carl.poirier.2@xxxxxxxxx>]

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 <jp.charras@xxxxxxxxxx> 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 <louijp@xxxxxxxxx
> > <mailto:louijp@xxxxxxxxx>> 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 <carl.poirier.2@xxxxxxxxx
> >     <mailto:carl.poirier.2@xxxxxxxxx>> 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     : kicad-developers@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>