Add UFQFPN-28

[Antichees]

datasheet

Package details (added by @cpresser)

[CLAassistant]

All committers have signed the CLA.

[cpresser]

Hi and thanks for you contribution.
This is a footprint that should be generated by the Package_NoLead__DFN_QFN_LGA_SON generator.

It can already do the chamfered pads, but so far there is no support to make the chamfered pads slightly smaller as required here.

@Antichees Is you python-foo good enough for that? If not, I will try to find time to improve the generator so this footprint can be easily generatre.

[Antichees]

Hi and thanks for you contribution.
This is a footprint that should be generated by the Package_NoLead__DFN_QFN_LGA_SON generator.

It can already do the chamfered pads, but so far there is no support to make the chamfered pads slightly smaller as required here.

@Antichees Is you python-foo good enough for that? If not, I will try to find time to improve the generator so this footprint can be easily generatre.

Hi
I will try, but it will hardly work.

[cpresser]

I was just looking into the source so I can give you some hints.
Turns out, the feature is already there. I just was not aware of it. So no coding required. You just need to punch the correct numbers into the .yaml file.

 edge_heel_reduction: 0.05

[Antichees]

I was just looking into the source so I can give you some hints.
Turns out, the feature is already there. I just was not aware of it. So no coding required. You just need to punch the correct numbers into the .yaml file.

 edge_heel_reduction: 0.05

[Antichees]

I was just looking into the source so I can give you some hints.
Turns out, the feature is already there. I just was not aware of it. So no coding required. You just need to punch the correct numbers into the .yaml file.

 edge_heel_reduction: 0.05

Hi, i entered dimensions from the datasheet. but the footprint is different from the recommended one.

ST_UFQFPN-28_4x4mm_P0.5mm:
 device_type: 'UFQFPN'
 manufacturer: 'ST'
 #part_number: 'mpn'
 size_source: 'https://www.st.com/resource/en/datasheet/stm8l101k3.pdf#page=71'
 ipc_class: 'qfn' # 'qfn_pull_back'
 #ipc_density: 'least' #overwrite global value for this device.
 # custom_name_format:
 body_size_x:
   nominal: 4
 body_size_y:
   nominal: 4
 overall_height:
   minimum: 0.5
   nominal: 0.55
   maximum: 0.6

 lead_width:
   minimum: 0.18
   nominal: 0.25
   maximum: 0.30
 lead_len:
   minimum: 0.3
   nominal: 0.4
   maximum: 0.5

 pitch: 0.5
 num_pins_x: 7
 num_pins_y: 7
 edge_heel_reduction: 0.05
 chamfer_edge_pins: 0.2
 #pin_count_grid:
 #pad_length_addition: 0.5
 #suffix: '_Pad{pad_x:.2f}x{pad_y:.2f}mm_HandSolder'
 #include_suffix_in_3dpath: 'False'

Here's what I got.

[cpresser]

You are correct, the footprint is not the same as the recommended one.
That is because the generator builds them with IPC compliant values. Most of them are from ipc_definitions.yaml

# Flat No Lead (DFN/QFN) with toe fillet
#           | Minimum | Median    | Maximum |
#           | (Least) | (Nominal) | (Most)  |
#           | Density | Density   | Density | round
# Lead Part | Level C | Level B   | Level A |  to
# ----------+---------+-----------+---------+-
# Toe       | 0.2     | 0.3       | 0.4     | 0.05
# Heel      | 0.0     | 0.0       | 0.0     | 0.05
# Side      | -0.04   | -0.04     | -0.04   | 0.05
# Courtyard | 0.1     | 0.25      | 0.5     |

ipc_spec_flat_no_lead:
    least:
        toe: 0.2
        heel: 0.0
        side: -0.04
        courtyard: 0.1
    nominal:
        toe: 0.3
        heel: 0.0
        side: -0.04
        courtyard: 0.25
    most:
        toe: 0.4
        heel: 0.0
        side: -0.04
        courtyard: 0.5
    round_base:
        toe: 0.05
        heel: 0.05
        side: 0.05

The values in your .yaml file look correct. And since we trust the generator we also assume the footprint is correct.

There is also this KLC rule: https://kicad-pcb.org/libraries/klc/F2.3/ It allows to use a manufacturer specific footprint.
In this case I think we are better of with the generic footprint. This is a standard housing. Nothing special about it. So a IPC compliant footprint should be good.
However, since I am not an expert on that topic perhaps some other @KiCad/librarians can also add to this discussion.

---

In any case, please head over to the footprints-generator repo and open a PR for your .yaml file changes.The idea is that we want to be able to re-create all footprints should the IPC recommendations change. Link that new PR to this one.

[Antichees]

Thanks for the answer.
I originally made a footprint by editing a component from the library.
Package_DFN_QFN\ST_UFQFPN-20_3x3mm_0.5mm

I was recommended to transfer the component using the script Package_NoLead__DFN_QFN_LGA_SON.
But in the repository, I did not find .yml file for ST_UFQFPN-20.
Does it mean that this footprint was not created by a script?

[cpresser]

Oh FFS. I did edit your comment instead of quoting it. My bad. I will try to undo that.

I was recommended to transfer the component using the script Package_NoLead__DFN_QFN_LGA_SON.
But in the repository, I did not find .yml file for ST_UFQFPN-20.
Does it mean that this footprint was not created by a script?

Yes. It is an older, legacy part, copied over from the old v4 library.
I did verify that by looking at the git history of that file.
Also the description of the footprint does not mention the generator.

[Antichees]

Oh FFS. I did edit your comment instead of quoting it. My bad. I will try to undo that.

I was recommended to transfer the component using the script Package_NoLead__DFN_QFN_LGA_SON.
But in the repository, I did not find .yml file for ST_UFQFPN-20.
Does it mean that this footprint was not created by a script?

Yes. It is an older, legacy part, copied over from the old v4 library.
I did verify that by looking at the git history of that file.
Also the description of the footprint does not mention the generator.

And as i understand it, in this case, binding to the manufacturer is not needed?
do i need to update an old component?

[cpresser]

And as i understand it, in this case, binding to the manufacturer is not needed?

I agree.

do i need to update an old component?

No. Not at all.
But if you like, you can open another PR to add a generated UFQFPN-20.
That might also have some complicated side effects, since the vendor-specific ufqfpn is used by some symbols.

So its best to not touch it as part of this pull request. Lets keep it simple and do one thing at a time.

[Antichees]

added PR