Add SOT-23-6 and sot.yaml

[aris-kimi]

No description provided.

[codeclimate]

Code Climate has analyzed commit 9002d3c and detected 0 issues on this pull request.

View more on Code Climate.

[chschlue]

See line comment.
Also, would you be willing to add the original SOT-23 (TO-236AB), SOT-23-5/8 (MO-178 var AA/BA) and TSOT-23-6/5/8 (MO-193AA/AB/BA) as well?

[chschlue]

Please remove tolerances, these are given as basic dimensions.
aaa and bbb are surface tolerances, not length.

[cpresser]

I was actually looking at this myself this weekend. But did not finish it. So far I could not find an option in ipc_gullwing_generator.py to skip pins. I guess we need to add that as well.

[chschlue]

Oops.
Thought we had that.

[chschlue]

https://github.com/pointhi/kicad-footprint-generator/blob/master/scripts/Packages/Package_Gullwing__QFP_SOIC_SO/Readme.md#pad-count?

[aris-kimi]

@cpresser I am on it right now. Will create PRs when i am done, but first i am going to fix this one.

[aris-kimi]

How to change that 6pin stated in the description?

EDIT:
Did it manually...

[cpresser]

https://github.com/pointhi/kicad-footprint-generator/blob/master/scripts/Packages/Package_Gullwing__QFP_SOIC_SO/Readme.md#pad-count?

[aris-kimi]

This is the output:

of this:

FileHeader:
  library_Suffix: 'TO_SOT_SMD'
  device_type: 'SOT'

SOT-23-5:
  size_source: 'https://www.jedec.org/sites/default/files/docs/Mo-178c.PDF variant AA'
  custom_name_format: 'SOT-23-5'
  body_size_x: 1.6
  body_size_y: 2.9
  overall_size_x: 2.8
  lead_width: 0.3 .. 0.5
  lead_len: 0.3 .. 0.45 .. 0.6
  pitch: 0.95
  num_pins_x: 0
  num_pins_y: 3
  exclude_pin_list: [5]

Have i misunderstood something?

[chschlue]

No, it's fine.
That feature seems to be working amazingly well.
Just imagine the possibilities when it's finally implemented :)

[chschlue]

Wait.
No, it's not.
Pin 6 should be 5, as opposed to "normal" gullwing packages.

[aris-kimi]

How am i supposed to leave one pin position empty and next counting start from next position?

I cant figure this out, this troubles me also for SOT-23 (TO-236AB).

And i cannot also find out how to configure TSOT... I've created a file tsot.yaml

FileHeader:
  library_Suffix: 'TO_TSOT_SMD'
  device_type: 'TSOT'
  
TSOT-23-5:
  size_source: 'https://www.jedec.org/sites/default/files/docs/MO-193D.pdf variant AB'
  custom_name_format: 'TSOT-23-5'
  body_size_x: 1.6
  body_size_y: 2.9
  overall_size_x: 2.8
  lead_width: 0.3 .. 0.5
  lead_len: 0.3 .. 0.45 .. 0.6
  pitch: 0.95
  num_pins_x: 0
  num_pins_y: 3
  exclude_pin_list: [5]

But output is the same as SOT variants... I need help with this..

[chschlue]

That's expected, TSOT-23 is basically SOT-23, but thinner.
The point is, we need different footprints to have different 3D models.

Also, exclude_pins needs a switch for skipping pin numbers.
I wasn't aware this feature is incomplete, sry.

[aris-kimi]

np, but how should this proceed now?

My footprints created are identical.. Oh.. thinner from height... got it!! So this seems ok, i'll create a new PR for TSOT, but still this issue with counting mising pin is there. Please guide me through this.

[chschlue]

This can't really proceed now.
I recommend leaving it until somebody gets around to complete exclude_pins ;)

[aris-kimi]

I can manually change pin number, in order to have a correct footprint, and when this feature gets completed in the script we can have it rebuild. I can leave a note at the description, even at the *.yaml file. How does that sound?

[chschlue]

Alright.

[evanshultz]

I can update the script, but I find the terminology a bit misleading. We want two conditions:

1. Pins are not present/removed/missing in a footprint and that pin number is not used.
2. Pins are not present/removed/missing in a footprint and the next pin uses the next pin number (no pin numbers missing).

Which one is most clear for the term exclude_pins? Only the first item is implemented now, as we can see above. And I'm not sure the best term was chosen for that behavior. In fact, I think the second item above is most common. So what are the two terms/phrases we should use to capture the two behaviors above? Then I can make it happen. Maybe skipped_pins and skipped_positions? Is that better?

Also, are there any other related behaviors the script needs to learn while I'm in there?

[aris-kimi]

I like that. Without much info i can understand that skipped_pins are for continuing numbering and skipped_positions are for missing pins that kept their number missing too. If my conclusion is correct i think this is great. :)

I want one more question about SOT-23 package. 3pin footprint. Can those two suggeted variables combined somehow?
I am unable to figure a way to configure *.yaml for this..

[chschlue]

skipped_pins and skipped_positions looks good to me.

I'm not aware of anything else the script is direly in need of learning.

[chschlue]

Size def inheritance would be great. I think @calebreister is working on that (#397)

[evanshultz]

I think I was imagining them the other way. So maybe my choice of terms wasn't so good. I was thinking skipped_positions would continue numbering. So in the image at #586 (comment) the upper right pin would be number 5 and not 6. Is that backwards from what you were thinking?

Maybe more explicit terms are needed with more than two words. Like exclude_pins (same behavior as now) and exclude_pins_continue_numbering? That's ugly, but more clear about what is happening. I want to find a term that's obvious for all English speakers and users, not just something that only makes sense if this discussion is read.

[evanshultz]

Of course, just after submitting the comment I recalled that IPC 7351 footprint naming has these conventions already. Maybe we adopt their terms since the generator is already based around IPC 7351. You can see this in the middle of page 2 at http://ohm.bu.edu/~pbohn/__Engineering_Reference/pcb_layout/pcbmatrix/IPC-7x51%20&%20PCBM%20Land%20Pattern%20Naming%20Convention.pdf. Then hidden_pins and deleted_pins would be the terms, with the current behavior matching hidden_pins and the behavior we are missing being deleted_pins. It may not be any more clear just looking at the terms, but I think the IPC definitions make it the way to go and I'm happy with this. Anyone object?

[calebreister]

Size def inheritance would be great. I think @calebreister is working on that (#397)

I do have an inheritance system working. Right now, I'm using it with JSON, but it should work fine with YAML (or for that matter pretty much anything that can be represented in a python dict). It doesn't support multiple inheritance, but it does have recursive dependency resolution, meaning that "A" can inherit "B", which itself inherits from "C". It also detects interdependence ("A" inherits "B", which inherits "A").

[evanshultz]

@cpresser @aris-kimi
I just submitted #604 which generates the SOT-23-5 and SOT-23 footprints as mentioned above. The code could change, of course, and the footprint descriptions might need some tweaking. If you care to give it a spin, check out that branch and see if the footprint itself is good for you and if any metadata should be adjusted even if you aren't going to dig into the code.

[aris-kimi]

Thank you @evanshultz .
I liked it, but i feel that i should wait for generator's PR #604 to merged first in case something needs to change, i will generate current footprints needed, but i will commit after confirmation.. I hope that is ok..

[evanshultz]

@aris-kimi
Oh yes. You should wait for that PR to be merged. But, I was asking above to look at the footprint itself and the metadata (description, keywords). If you have comments there I can incorporate that into the generator script update.

[aris-kimi]

I think you have done more than just great job!!
All important metadata are presented, JEDEC's name is shown at the URL + variant, also aditional custom description can be added i saw in case footprint requires something extra, i will spend some time with it and leave feedback here if needed.
Thanks again.

[cpresser]

@aris-kimi PR #604 is now merged. You can start using it.

[aris-kimi]

@chschlue i think we are ready here.

[chschlue]

Thanks.