Closed cederom closed 3 years ago
Code Climate has analyzed commit 5c0df1ea and detected 0 issues on this pull request.
View more on Code Climate.
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.
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
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:
Kionix_LGA-12_2x2mm_P0.5mm
since the pitch is 0.5mm and we don't capture height in the footprint name.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 option 2:
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 :-)
* 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.
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.
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⏎
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 :-(
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.
Signed-off-by: Tomasz 'CeDeROM' CEDRO tomek@cedro.info