I want to assign nets to pads during the layout process
I need to wire up many interchangable GPIOs.
Rather than arbitrarily assign pins on the schematic in advance, I figured I’d route tracks over to my part and then assign them to the nearest available pads.
Here’s an example, so far so good:
However, when I went to actually make the assignments in the schematic, I noticed that pad 6 is a “no connect” pad, not a GPIO.
But I couldn’t find any way to have this visually indicated in Pcbnew.
(My searching only found this 2015 this bug report from someone in a similar situation)
Does anyone have a good solution for this workflow?
The best I can think of is to connect all of the “no connect” pins in my schematic to a false net (so the net name appears in Pcbnew), but it feels like asking for trouble to actively misrepresent the intended design in the schematic just to help with layout.
I think the proper way to do this would be to have pin swapping implemented. You would assign your nets in eeschema with your best first guess and then swap pins in pcbnew to fit your layout needs. I am not sure if this will come in v6 or if it was moved to a later release. I would however guess that wireit could be of help here (it has a swap tool, i doubt it pushes the change back to eeschema so you will still need to do that part manually).
Thanks for the replies! @paulvdh if I’m reading your response in the linked thread correctly, you are saying that checking the “delete single-pad nets” option when updating the PCB from schematic will make connected and unconnected pads visually distinct.
However, this doesn’t resolve my core problem, which is that Pcbnew does not distinguish between an unconnected pin and a pin marked as “no connect”:
@Rene_Poschl , I don’t see pin swapping as a solution to the problem of choosing pins during layout: If I have a 100 pin package and need to connect 5 GPIO nets, arbitrarily assigning them to 5 pins will only show me 5 GPIO pins during layout — that doesn’t help me know which of the 95 remaining pads are usable alternatives.
A general way to frame my problem is needing to see during layout which “class” a pin belongs to — “no connect” is a specific example of a class, but I could imagine it being very useful to see other fungible classes of pins like “GPIO”, “analog input”, etc. at layout time.
The problem is rather more complex however especially for microcontrollers as pin selections determine the availability of other peripherals. Sure you can have your GPIO on pin 15 or 16 but the former means you can’t have SPI and the latter is needed for I2C or whatever. How you model that is complex - look at STM32 Cube. I am not sure how you could model a generic solution.
I just went through this exercise with an ARM chip from TI. Adding on to the complexity is the fact that pins need to get a meaningful name in the firmware also. Swapping pins on the board would mean also to rename these in the firmware at the same time or else you end up in a big old mess.
I did this just iteratively; making a best guess at first and then during the layout some choices become clear as unideal and then do the swap. It was not the funnest thing to do and i still made lots of mistakes and had to check the results many times but it is possible.
I had a group of 30 odd pins to assign, 100 as the OP mentiones is a whole different ball game.
Totally agree! I am unfortunately very well acquainted with the stm32g4 datasheet’s “alternate function table” = )
I don’t expect KiCad or its libraries to have everything categorized exactly how I need it out of the box, I just wanted to point out that a mechanism which allowed people to categorize/tag pins in a way that’s visible on the layout (but that doesn’t imply electrical connection between pins of the same category) could be helpful for these kinds of layout problems.
For the record, in case anyone else has the same need, what I ended up doing was:
Assign pins into fake nets so their assignments would be visible during layout (“X” for deliberately unconnected, “X_GPIO” for open gpios, “X_AIN” for open analog inputs, etc.)
I made a note in the schematic that the “X” nets are a layout hack and should be removed before fabrication.
I just ignored the (massive) rats nest between the pins and laid out tracks to nearby pins of the right category.
Then went back and updated the schematic with the correct assignments and removed the “X” nets.