Corrected footprint for Atmega-48-MHN and Atiny-48-MHN

[poeschlr]

Edit: i originally looked at the wrong page of the datasheet. This is now corrected.

The original footprint had the wrong EP size (taken from an unrelated application note)

Datasheets:

• http://ww1.microchip.com/downloads/en/DeviceDoc/ATmega48A_88A_168A-Data-Sheet-40002007A.pdf page 477
• http://ww1.microchip.com/downloads/en/DeviceDoc/8008S.pdf page 16

Symbol PR: KiCad/kicad-symbols#769

---

Script PR: pointhi/kicad-footprint-generator#149
Responsible file for the dimension is qfn-2x.yaml

Script params for reference:

QFN-28-1EP_4x4mm_P0.45mm_EP2.4x2.4mm:
  device_type: 'QFN'
  size_source: 'http://ww1.microchip.com/downloads/en/PackagingSpec/00000049BQ.pdf (Page 280)'
  ipc_class: 'qfn' # 'qfn_pull_back'
  body_size_x:
    nominal: 4
    tolerance: 0.05
  body_size_y:
    nominal: 4
    tolerance: 0.05
  lead_width:
    minimum: 0.17
    maximum: 0.27
  lead_len:
    minimum: 0.35
    maximum: 0.45

  EP_size_x:
    nominal: 2.4
    tolerance: 0.05
  EP_size_y:
    nominal: 2.4
    tolerance: 0.05
  EP_num_paste_pads: [2, 2]

  thermal_vias:
    count: [3, 3]
    drill: 0.2
    paste_via_clearance: 0.1
    EP_paste_coverage: 0.75
    paste_avoid_via: False

  pitch: 0.45
  num_pins_x: 7
  num_pins_y: 7
  chamfer_edge_pins: 0.1

---

Screenshot of the thermal vias version

---

---

32 pin version should have 3.1x3.1mm ep instead of 3.8x3.8mm
Example datasheet:

• http://ww1.microchip.com/downloads/en/DeviceDoc/8008S.pdf (Page 20)

Parameters:

QFN-32-1EP_5x5mm_P0.5mm_EP3.1x3.1mm:
  device_type: 'QFN'
  size_source: 'http://ww1.microchip.com/downloads/en/DeviceDoc/8008S.pdf (Page 20)'
  ipc_class: 'qfn' # 'qfn_pull_back'
  body_size_x:
    nominal: 5
    tolerance: 0.1
  body_size_y:
    nominal: 5
    tolerance: 0.1
  lead_width:
    minimum: 0.18
    maximum: 0.3
  lead_len:
    minimum: 0.3
    maximum: 0.5

  EP_size_x:
    minimum: 2.95
    nominal: 3.1
    maximum: 3.25
  EP_size_y:
    minimum: 2.95
    nominal: 3.1
    maximum: 3.25
  EP_num_paste_pads: [3, 3]

  thermal_vias:
    count: [3, 3]
    drill: 0.2
    paste_via_clearance: 0.1
    paste_between_vias: 1
    paste_rings_outside: 1
    grid: [1, 1]

  pitch: 0.5
  num_pins_x: 8
  num_pins_y: 8

---

The AVR MCU uses an already existing footprint (3.6x3.6mm EP) it is not added here for this reason.

[evanshultz]

For the 28 pin, I guess you mean page 479 (not 477) of http://ww1.microchip.com/downloads/en/DeviceDoc/ATmega48A_88A_168A-Data-Sheet-40002007A.pdf? That is wrong in the footprint.

For the 32 pin, change the link to http://ww1.microchip.com/downloads/en/DeviceDoc/ATmega48A_88A_168A-Data-Sheet-40002007A.pdf page 477. The link you used is the same package drawing but this one is rev F (instead of rev E).

[evanshultz]

Also, since these are footprints built for a specific pad size, should the footprint name indicate that? Perhaps add Pad0.40x0.23mm for the nominal size of pad 1. While there may be only one footprint with this pad size now, since this is a generic footprint it may save a lot of time later to go ahead and put all details that define the footprint into the footprint name.

[poeschlr]

I am a bit on the fence with this one to be honest. On the one hand having the pad size in the footprint name gives more information to the user. On the other it will confuse users if the default generic footprint has it. (I would have only used it where there is a consious decision to change the pad size. An example would be handsolder versions)
And it makes maintenance significantly harder. (See the problem with the accidentally deleted reverse mounted LED footprints. This happened because the pad size changed and i therefore needed to delete all handsolder versions.)

---

Edit: My main argument against adding pad sizes is that i do not want to have another massive naming convention change so shortly after having updated the names for these parts. (Only doing it for some footprints would really be wrong.) I would really like to see the lib stable in this regard for at least a year or so.

[poeschlr]

I used a different datasheet in the footprint then here in the description of the bugreport. (I used a shorter datasheet as it downloads faster and users will find the drawing faster. Did forget to update the description here. Sorry about that.)

• The 28 pin uses: http://ww1.microchip.com/downloads/en/DeviceDoc/8008S.pdf (Page 16)
• The 32 pin uses: http://ww1.microchip.com/downloads/en/DeviceDoc/8008S.pdf (Page 20)

---

Edit: oops that was meant for the other pull request. (removed that part from here.)

[evanshultz]

I'm not sure how this confuses users. If the user picks a part with a default footprint, then they're good. If they deviate, it's up to them. If the part they choose doesn't have a default footprint, and it's a part in a QFN package, they will need to figure out the package. Let's say there are only two footprint options in CvPcb and it's not too hard to figure out which footprint is correct (and both are likely to work, anyway, so it's not as if there is one horrendously bad choice). I think the potential burden on users to drive KiCad properly is higher than, say, Excel, and this is a case where making available the correct footprint for a package is a higher priority than pandering to some ideal of simplicity in a PCB design tool.

I agree only adding pad size for some footprints would be poor form, but having the correct footprint for a package seems like a more important goal.

I didn't extensively try to find two package drawings showing the same size package and EP and pin count and pin pitch but different lead sizes, so if that exists in the future we can cross that bridge.

Since you're good with this and I've made my concerns noted, I'll merge now.