A completely automated part replace is tricky. Even with the same number of connectors, sometimes the connector coordinates are slightly different, which means that the wires/traces need to move slightly to align again. That “could” cause issues with keepout distances.
A worse case though, is a part that is a “correction”. Maybe a couple of pins were reversed.
Requiring an explicit reconnect means the user has to actually “look” at what is being done, in case it is not as simple as directly attaching to a connector in the same location as the previous part.
Yes, that makes sense. But what does the (grayed out) menu entry “update selected components” do? Update a part in my project by a newer version of exactly the same part in the library (if one exists)?
Yes. If a part is added to a sketch, the specific version information is remembered. If the referenced part is later updated (in the library), the original version continues to be used in the sketch. Unless/until it is explicitly updated with that option. And again, each view needs to be revisited after updating, to make sure the new version did not break something. That does try to reconnect everything, but sometime it fails. Even a few pixel move to make the connector properly line up with .1 inch grid can break the reconnect.
They also look to have released a Fritzing part for it (although I haven’t looked that over at all) for at least the pico w. A pointer to the part is here:
Pico H submission doesn’t seem right in Schematic view: grey background and pins don’t sit on grid and connectors go to middle of pins, not ends. Also checked Raspberry Pi website and this is the “official” download from their website. Is there an update due? who drives this - Raspberry Pi foundation or Fritzing? (so I know who to ask).
For the pico I did the update and gave it to the RPI folks (they wanted no restrictions on redistribution) so I should probably do this one too to make sure the part meets Fritzing standards.
Sorry, forgot about this. The Pico H has more problems than just schematic. PCB is pretty much useless as it stands. It doesn’t create holes for THT (because the pads aren’t correctly defined) and there likely isn’t enough pad space to solder the pads SMD. Here are a pair of parts that correct the problems. The RPI folks likely want the THT version (they only want one part) but if you want to put parts on both sides of the board you likely need the SMD version (which doesn’t have holes though.) I’ll look at the w tomorrow.
I took out a bunch of stuff that isn’t needed by Fritzing, so it may not work for the RPI folks any more if they are using the switch statements in the svgs.
Thanks for this; the Pico H looks OK for me and I guess is what a lot will use going forward. I haven’t got an opinion on the PCB detail, but my other observations are:
The original Pico fritzing part had only one error: you had “VSS” instead of “VSYS” at pin 39. Visually, the SWD pins at the top on the schematic view wasn’t ideal (the Pico H THT version is better in this respect, where they are at the bottom now). But if someone wants to put an original Pico on a PCB using headers and use SWD, there is no corrected part for this (because of VSS). The original Pico was both SMD and header capable: I suggest people will still use these a lot. So it would be good to correct it for VSS and SWD location on schematic (if you have the time, sorry).
Your attached “PicoH-Fritzing-SMD” version isn’t correct because (a) there isn’t such a part and (b) the breadboard view shows a JST connector for the SWD pins, but it should be like the “original” Pico, with castellated pads like the other pins.
When you look at the Pico W, note that this is currently SMD, see page 10 of [https://datasheets.raspberrypi.com/picow/pico-w-datasheet.pdf] where the pads for the SWD are in a different position to the original. I understand that an H version of this is on its way (Pimoroni says PicoW H is “coming soon”). I guess they will fit a vertical JST as there is no room for the one they use on the PicoH.
Hope that makes sense
thanks
Andy
So the original Pico might get left behind with a small error as item 1.
The label makes no practical difference and isn’t worth fixing (it may have been called VSS in whatever pin out diagram I was using.)
The original Pico is technically correct. Schematic is an abstract view and isn’t necessarily supposed to match real life (although I prefer that it does, others disagree.) This format (power pins on the top, ground on the bottom and some more changes) are the preferred layout in KiCad and have been suggested as what Fritzing should use.
The Fritzing parts must be different, thus the different names it doesn’t indicate there is a different version of the actual part. SMD doesn’t work in breadboards so breadboad view for SMD usually does not match the part (typically shown as an adapter plate.) PCB view is correct for the SMD version and thus no change is needed. There is a typo on GP28 in the PicoH part that I will correct though.
I tried adding those and didn’t get anywhere because I have never worked with the parts editor before, could someone please add these, I feel like this isn’t as difficult for someone who knows how to do it lol
You haven’t removed the px from the font size in the pcb svg which causes the font size to be set very large. Either running the part through FritzingCheckPart.py or using a text editor to remove the px from the font sizes in the pcb svg will fix it (here I used FritzingCheckPart.py here)
