Changed PCF8574 footprint filter, added a package variant

Changed the PCF8574 footprint filters to include package sizes. This symbol covers both the P and T types which only differ in their package, but not in their footprint.

Added PCF8574TS variant with SSOP-20 package as an additional symbol. I created it as an extra symbol because of the incompatible footprint to the existing PCF8574 (P/T) variants in the library.

I did not break up the original PCF8574 in the library into the PCF8574P (PDIP-16) and PCF8574T (SO-16) variants to avoid breaking existing projects which use these symbols. Of course I can do that if required.

PCF8574:

PCF8574TS:

Datasheet under http://www.nxp.com/documents/data_sheet/PCF8574_PCF8574A.pdf

---

All contributions to the kicad library must follow the KiCad library convention

Thanks for creating a pull request to contribute to the KiCad libraries! To speed up integration of your PR, please check the following items:

• Provide a URL to a datasheet for the symbol(s) you are contributing
• An example screenshot image is very helpful
• Ensure that the associated footprints match the official footprint library
  • A new fitting footprint must be submitted if the library does not yet contain one.
• If there are matching footprint PRs, provide link(s) as appropriate
• Check the output of the Travis automated check scripts - fix any errors as required
• Give a reason behind any intentional library convention rule violation.

Just a quick note, not a full review:

• The NC pins endpoints should be on the symbol outline (KLC S4.6)

Hello,

in my understanding, KLC S4.6 states that hidden pins "should lie within or on the symbols outline", so I thought placing them inside the symbol should be fine.

If I would have placed the pins onto the symbol outline, that would have resulted in violating KLC S4.1 since the symbol outline is not on the required 2,54mm grid. This could be solved by enlarging the symbol which I chose not to do to still keep the new PCF8574TS symbol exchangeable with the P and T variants.

Of course I could have redrawn both symbols to fit the 2,54mm grid and thus allow placing the NC pins onto the outline, but as stated in the pull request, I wanted to avoid to mess up existing projects which already use the old symbol.

in my understanding, KLC S4.6 states that hidden pins "should lie within or on the symbols outline", so I thought placing them inside the symbol should be fine.

We prefer 'on' over 'in'. But you are right, 'in' is allowed. And the preference is not codified in KLC.

If I would have placed the pins onto the symbol outline, that would have resulted in violating KLC S4.1 since the symbol outline is not on the required 2,54mm grid.

I was not aware of that. I just looked at the screenshot. Sorry about that.

A possible fix for that is reducing pin-length and enlarging the symbol body by 50mil: Actually the pin-length should be 100mil according to KLC (https://kicad-pcb.org/libraries/klc/S4.1/). This will keep the connection points on the same position thus its not a breaking change.

This is optional - you don't need to do this. Nevertheless, I would like to see that fixed.

Sou are right, I haven't thought about the fact that only the pin connections are relevant to keep compatibility. I now have enlarged symbol outline by 50mil and placed the NC pins onto the outline. I applied these changes to both symbols to keep them looking the same.

The Datasheet has /3as suffix for the SMD variants. Do you have any clue what those chars represent?

• Pinout, Names and Types
• The NC pins are still 150mil long. This is a non functional thing, but for aesthetics I would love to see it fixed.
• Footprint and Filter are good

Once we move towards v6.0 (and allow breaking changes) we should shrink those symbols again. They are way bigger than they need to be. This would also be a good time to split the DIP and SO version.

Yes, the symbol is indeed a bit large. How would a redesign for v6.0 happen? Should I just create a new pull request?

Yes, the symbol is indeed a bit large. How would a redesign for v6.0 happen? Should I just create a new pull request?

There has been some discussion in the librarians team, but no good conclusion. If you create that PR now it might have merge conflicts in the future.

Perhaps it is best to open a new issue which describes what needs to be done and link it to this PR. Once we open the window for breaking changes we can search for the 6.0 milestone and start to actually work on those issues.