pointhi / kicad-footprint-generator

creating kicad footprints using python scripts
GNU General Public License v3.0
186 stars 175 forks source link

Added Kionix_LGA-12_2x2x0.9mm_P0.35x0.375mm. #634

Closed cederom closed 3 years ago

cederom commented 3 years ago

Signed-off-by: Tomasz 'CeDeROM' CEDRO tomek@cedro.info

codeclimate[bot] commented 3 years ago

Code Climate has analyzed commit 5c0df1ea and detected 0 issues on this pull request.

View more on Code Climate.

evanshultz commented 3 years ago

https://github.com/KiCad/kicad-footprints/pull/2478

evanshultz commented 3 years ago

Thank you!

Unfortunately, our generator can't handle this package right now. You'll have to adjust the x and y size of some pads by hand. You can see in the datasheet that the 'A' is right-side up but that only applies to pins 5-6 and 11-12. The other pins are wider than they are tall.

Please add a comment about this in the YAML file and I'll update the script later.

In addition, please use the dimension format in the datasheet. So instead of nominal and max, use min and nominal and max. This makes things easier to review. Check out the available formats for the YAML file dimensions at https://github.com/pointhi/kicad-footprint-generator/tree/master/scripts/Packages/Package_Gullwing__QFP_SOIC_SO.

And please include the datasheet in the description as well.

cederom commented 3 years ago

Naah, the script handles it well - top and bottom pins are "higher" and side pins are "wider".

Specification [1] does not specify the exact footprint nowhere, it only specifies the dimensions of a chip casing. But when you look at TN008 (pcb design guideline document) [2] page 4 says:

Using a 0.0635 mm solder mask around each pad (pad dimension + 0.1270 mm), the minimum solder mask web is 0.1227mm between I/O pads.

Thus I have added a default pin sizes + 0.05 tolerance which gives a nice resulting footprint. When I used exact X+0.127 and Y+0.127 script seems to round the numbers to 0.4 which is invalid.

Current footprint matches both expectations and restrictions of [1] and [2]. Maybe it was easier if Kionix simply specified the expected footprint :-)

By the way - this exactly matches the existing LGA-12_2x2mm_P0.5mm footprint except it has the square pads which may be even better solution for this chip. Not sure if adding another footprint is feasible.

[1] http://kionixfs.kionix.com/en/datasheet/KXTJ3-1057-Specifications-Rev-5.0.pdf [2] http://kionixfs.kionix.com/en/document/TN008-PCB-Design-Guidelines-for-2x2-LGA-Sensors.pdf

evanshultz commented 3 years ago

Our generator builds the footprints according to IPC7351B fillet goals. It require package info, and disregards whatever the manufacturer footprint shows.

Ah yes. The pullback is the same and the pads are rotated. My mistake. I had forgotten all the details of this generator.

I looked at the resulting footprint and this PR. Unfortunately, I don't feel I can merge it. The link is to a doc which gives the exact footprint from Kionix, and the footprint name says it's specific to Kionix, but the generator isn't making a footprint exactly like in the Kionix document. This was my fault for not looking at the document earlier. Sorry that resulted in me not having a clear picture and giving you the best advice. There are two ways to proceed: (1) use a more generic footprint or (2) make this footprint look exactly like the Kionix document linked.

If option 1:

If option 2:

cederom commented 3 years ago

I have impression that we are overcomplicating things. The result now is the same as initially proposed LGA12 that exist in the release footprint library. Kionix does not provide a "footprint" reference, only a "component" reference. I am not sure if making a footprint that exactly matches the size of the component is a good way to go. Each component has a bit bigger pad than the component leg. Kionix suggests a dimenstions for pad mask and I have complied to those recommendations. Resulting footprint is almost the same as existing LGA12. Why don't we just use that LGA12?

If this is your final decision and consulted with other project members I will update the yaml here in footprint generator to match component dimensions no problem :-)

cederom commented 3 years ago
* Change the YAML definition to `Kionix_LGA-12_2x2mm_P0.5mm` since the pitch is 0.5mm and we don't capture height in the footprint name.

done

* Change the link to be the Kionix datasheet.

done

* Change all script inputs to use a dimension format like the datasheet. So for `body_size_x`, instead of nominal and tolerance use min, nominal, and max. This is easier to check and is the way we always requires scripts to be done.

If you look at above definition this it not true - all sizes use nominal and tolerance:

280 Broadcom_LGA-8_2.0x2.0mm:⏎
281   device_type: 'LGA'⏎
282   size_source: 'https://docs.broadcom.com/docs/AV02-4755EN'⏎
283   library: 'OptoDevice'⏎
284   manufacturer: 'Broadcom'⏎
285   ipc_class: 'qfn_pull_back'⏎
286   body_size_x:⏎
287     nominal: 2⏎
288     tolerance: 0.1⏎
289   body_size_y:⏎
290     nominal: 2⏎
291     tolerance: 0.1⏎
292   overall_height:⏎
293     nominal: 0.34⏎
294     tolerance: 0.1⏎
295   lead_width:⏎
296     nominal: 0.31⏎
297     tolerance: 0.1⏎
298   lead_len:⏎
299     nominal: 0.35⏎
300     tolerance: 0.1⏎
301   lead_to_edge:⏎
302     nominal: 0.05⏎
303   pitch: 0.53⏎
304   num_pins_x: 0⏎
305   num_pins_y: 4⏎
* The existing LGA-12 part may end up nearly the same. In fact, we can overwrite it if it's the same or very close. Sadly, there is no document linked so I wasn't able to check ahead-of-time from the footprint if it was for an equivalent package.

I would not delete existing components from the existing release libraries, someone may be using it.

I will push an update in a moment.

evanshultz commented 3 years ago

It's up to you. This generator makes pads based on the pin sizes using IPC 7351's fillet goals. This very rarely matches the datasheet recommendation, but it industry standard and is almost sure to give good results. We have been doing this successfully for many package types for quite a while now.

The other way is with a manufacturer prefix, in this case Kionix_, where the footprint exactly matches what the manufacturer says. This applies for non-SMT parts that IPC 7351 doesn't cover, and loads of other parts which are somehow unique.

Both approaches can be used, and are used in the library, so the choice is up to you.

Apologies again for not looking at the original LGA-12 more closely. It didn't have any datasheet attached so I didn't have any document to compare against the Kionix one. But I could have spent more time looking at it earlier. And I didn't. Sorry.

cederom commented 3 years ago

Either generator is buggy or I am doing something wrong - for specified lead width/height it takes some other values to create footprint pads:

307 Kionix_LGA-12_2x2mm_P0.5mm:⏎
308   device_type: 'LGA'⏎
309   size_source: 'http://kionixfs.kionix.com/en/datasheet/KXTJ3-1057-Specifications-Rev-5.0.pdf'⏎
310   library: 'Package_LGA'⏎
311   manufacturer: 'Kionix'⏎
312   use_name_format: 'LGA'⏎
313   #ipc_density: 'least'⏎
314   ipc_class: 'qfn_pull_back'⏎
315   body_size_x:⏎
316     minimal: 1.95⏎
317     nominal: 2.0⏎
318     maximum: 2.05⏎
319   body_size_y:⏎
320     minimal: 1.95⏎
321     nominal: 2.0⏎
322     maximum: 2.05⏎
323   overall_height: 0.9⏎
324   lead_width_min: 0.25⏎
325   lead_width: 0.25⏎
326   lead_width_max: 0.25⏎
327   lead_len_min: 0.275⏎
328   lead_len: 0.275⏎
329   lead_len_max: 0.275⏎
330   lead_to_edge: 0.1⏎
331   pitch: 0.5⏎
332   num_pins_x: 2⏎

image

cederom commented 3 years ago

This script cannot produce pads 0.25x0.275. No time to waste here. Will fix the footprint by hand. We could have used existing LGA-12 footprint from a release library.

I am however really discouraged by your support @evanshultz :-(

evanshultz commented 3 years ago

Not supporting pads that are rectangular is a limit of this script. Good point. I have used this generator extensively for other package types, but not LGA packages. I will take a look at updating the script when time allows. Thanks again and sorry this didn't work out smoothly.