Add SIP Generator with Yaml config files

[Werni2A]

This wraps the makeSIPVertical such that it can be used with Yaml files.

In the beginning of the script I defined 2 functions to calculate the drill diameter and pad sizes according to IPC. I wonder if these functions are already implemented somewhere in the repo? I haven't found any, yet. If there is no existing implementation maybe you can take a look at these functions and How to calculate PTH hole and pad diameter sizes according to IPC-7251, IPC-2222 and IPC-2221 standards? which I used as a reference.

Any suggestions are appreciated :)

Todo:

• [ ] Move IPC drill and pad size calculations out of the script or replace by existing function calls
• [ ] Complete Todos in the code
• [ ] Add generator for horizontal parts
• [x] Rename "missing_pins" to "hidden_pins" (missing pins are counted) in generator script
• [ ] Rename "missing_pins" to "hidden_pins" (missing pins are counted) in makeSIPVertical/makeSIPHorizontal
• [ ] Add feature to specify "deleted_pins" (deleted pins are not counted)
• [ ] Take care of huge package size tolerances - requires modifications in makeSIPVertical

Required for https://github.com/pointhi/kicad-footprint-generator/pull/579

[codeclimate[bot]]

Code Climate has analyzed commit 1b4e6357 and detected 0 issues on this pull request.

View more on Code Climate.

[evanshultz]

Thanks for this contribution!

This is mostly just looking at the YAML file and not a real review:

1. Leave the YAML file uncommented and start it with test_ if it's just an example file.
2. Please align YAML terms with our other generators, at least where possible, such as https://github.com/pointhi/kicad-footprint-generator/tree/master/scripts/Packages/Package_NoLead__DFN_QFN_LGA_SON.
3. Why are pin length/width and diameter given? Only one should be required and both constituting an error.
4. I guess you don't have a copy of IPC-2221? To calculate pad size you need to know the Performance Class (1, 2, or 3) and the Producibility Level (A, B, or C). It is different than the IPC 7351 densities used in our other generators.
5. In addition, there needs to be a drill and pad size overwrite feature since some parts will need them. For example, parts that see great mechanical force, like connectors, may need bigger drills/pads that IPC-2221 would request.
6. Neither ddril or pad size should exist in the YAML file since it should be calculated. I guess this is why it's commented out twice? Perhaps add a comment explaining this or else good a give and one or more bad examples to test the code.
7. Where is the revision YAML key being used?
8. Use hidden_pins and deleted_pins as YAML keys according to the definition on page 2 of http://ohm.bu.edu/~pbohn/__Engineering_Reference/pcb_layout/pcbmatrix/IPC-7x51%20&%20PCBM%20Land%20Pattern%20Naming%20Convention.pdf. You can see this implemented at https://github.com/pointhi/kicad-footprint-generator/blob/master/scripts/Packages/Package_Gullwing__QFP_SOIC_SO/ipc_gullwing_generator.py. And PadArray supports it.
9. I would like to see the IPC calculators split out. The other ones need this done as well since they carry around the same (or almost the same) code. I think placing it at kicad-footprint-generator/scripts/tools/ipc_pad_size_calculators.py or a similar file in that folder would work, if it doesn't belong in that file.

Again, this is just from a quick look at the YAML file. It's a discussion so free feel to comment whatever you're thinking and we'll find a solution together!

[Werni2A]

@evanshultz thank you for taking a look.

3. "Why are pin length/width and diameter given?" The first case is a rectangular pin shape. The website where I got the formulas from calculated the "diameter" of rectangular pins as the diagonal distance through the pin therefore, I require length and width. The other case is that the pin shape is circular. As the pin is only rectangular or circular it only makes sense to specify length/width or diameter.
4. / 9. No I don't have access to the standard and to be honest I don't know much about. If you can provide me with the formulas or the related pages I can implemented it but I think that's problematic from a copyright point of view. It might be best if someone else could refactor/modify the two IPC functions and move them into the ipc_pad_size_calculators.py.
5. / 6. My idea behind ddrill and the pad sizes was to use them to overwrite the IPC calculated ones. That's also the reason why they are commented out twice. It should just show that there is the possibility to use these but in the typical case only the pin size should be defined and therefore IPC used. But the examples and comments are a good point, I will add a few.
6. What do you mean with "revision YAML key"? Is it a KiCad specific version or a version from the Yaml standard? I skimmed the QFN generator and its Yaml file but don't see something like this. Could you please clarify this point.

Notes for myself:

• [x] Add a few example scripts that show different functionalities of the script.
• [x] Add comments to the example in the Yaml file.
• [x] Implement 1. from above.
• [ ] Implement 2. from above.

[Werni2A]

Now I get what you meant with "revision key". It is only used in the description of the footprint. I used it to specify the datasheet revision the footprint is based on.

[Werni2A]

@evanshultz should I change the "level" of Yaml keys such that it looks like the qfn.yml version?

And what about the part with nominal/tolerance I think the TolerancedSize function is really convenient to parse them. Changing them to pkg_length_min, pkg_length_max... would be much more effort.

Excerpt qfn.yml:

  pkg_width: 6.0
  pkg_height: 6.0

Excerpt Package_SIP_Vertical_THT.yaml:

  pkg:
    length:
      nominal: 19.5
      tolerance: 0.35
    width:
      nominal: 6
      tolerance: 0.35
    height:
      nominal: 9.5
      tolerance: 0.35

[Werni2A]

I refactored the generator and added a few examples, no pressure on you @cpresser @chschlue but maybe one of you finds time to review the script. I have a few ideas for adding a THT DIP generator and replacing some handmade footprints with script generated ones but all this stuff depends on this PR in one or another way.

[evanshultz]

@Werni2A We are wrapping up as many footprints and symbols as we can before moving to GitLab. This repo, I don't think, will move right away so I'd rather come back to this in a few days once there's less pressure. I can see you've been thinking about this and pouring in more good ideas which is great!

The DIP package generator is at https://github.com/pointhi/kicad-footprint-generator/tree/master/scripts/Packages/Package_DIP. It's an older script style like this one and it would probably be best to re-write them all using a more modern style and defaulting to IPC-2221 compliant pads. Which makes sense for that piece of the generator to be abstracted.