Skip to content

Add Raspberry Pi Pico and Pico W

Add Raspberry Pi Pico and Pico W from Ki-Lime Pi Pico 2.0.0

Datasheets:
https://datasheets.raspberrypi.com/pico/pico-datasheet.pdf
https://datasheets.raspberrypi.com/picow/pico-w-datasheet.pdf

Source repository: https://gitlab.com/recursivenomad/ki-lime-pi-pico

Image of Ki-Lime Pi Pico footprints

These are some of the footprints being added, but there are more worth interrogating in this submission that are not imaged here.

  • Related symbol merge request: !4586 (kicad-symbols)
  • Related model merge request: !1047 (kicad-packages3D)

Responses to errors produced by the KLC checker scripts:

F5.1 - Intentional on optional graphic/virtual footprints
F5.2 - Intentional on optional graphic/virtual footprints
F5.3 - Intentional on optional graphic/virtual footprints
F6.1 - As this is a hybrid footprint without paste, leaving it as THT
F6.2 - False flagging due to USB drill hole placement / SWD pins.
F6.3 - Intentional
F7.2 - For drop-in parity with all other RaspberryPi_Pico footprints added here, I opted to leave all origins in the centre. Thoughts?
F7.3 - False flagging; Pad 1 is a rounded rectangle, following Raspberry Pi's datasheet
F9.1 - Exempt due to generic component
F9.3 - No models is intentional for optional graphic footprints
F9.3 - Directory name mismatch is expected for generic socket models
F9.3 - Models have a lot of options and a lot of names, depending on the footprint. Is this OK?
F9.3 - Intentionally used offset model for virtual Picos, to align to KiCad's generated socket models without adding yet another duplicate file

Any additional deviations from the KLC were mostly conscious decisions to follow the existing norms within the Module library.

Okay, so...

I have spent an unreasonable amount of time developing a library for the Raspberry Pi Pico recently, and it covers a lot of fringe edge cases that I assume would be unnecessarily specific to include in a core library. That said, I wanted to first open this merge request with all the offerings on the table, to then work with the KiCad library team to trim it down once you've had a chance to review what's available.

Some of the most stand-out oddities of this footprint library are:

  • Multi-part assembly. A user of my repository requested a symbol which produces 2 distinct socket footprints so that 2 position file entries are produced for pick n' place. So I made a virtual Pico drawing as a guide for placing custom-silkscreened sockets, successfully producing individual line items in the position file for each socket, and individual BOM entries for the sockets and the Pico.
  • I experimented with adding small castellation islands to enable hand-solderers and opportunity to solder to the test points beneath the Pico without reflow hardware.
  • I added some optional graphic elements for pin labelling and RF keepouts which are to be overlaid atop existing footprints
  • And generally speaking there's just lots of variations (Original Pico vs. Pico W vs. common footprints; SMD vs. THT vs. combo footprints; MountingHoles variants, HandSolder variants, etc...) It all adds up to a lot for 2 devices! (4 if you count the Pico H and Pico WH)

I have a hunch that much of what I list above may not belong in core KiCad; but that would still leave some very nicely detailed conventional footprints 🙂

I respect that this is a dense library with a lot to take in (and a lot to filter out). Please take your time, and I look forward to your feedback and refining this contribution together!

Edited by recursivenomad

Merge request reports