I’m sure this has to have been asked before, but I can’t find it…
As a simple example; laying out a ųC, I want to hook an LED to one of the PWM pins — any PWM pin, it really doesn’t matter, it’s only a firmware constant. Selecting the wrong one makes routing hell, but I can’t really be sure which one would be best to choose until I’ve decided on the package, it’s orientation, and potentially where other parts get placed around it. And having to go back to the schematic and change it there — likely via a spreadsheet or something — is, painful.
Much the same with a simple Quad AND Gate package. I get that’s a more complicated task, because now you’re dealing with a set of pins and some even weirder constraints (not only do you now have four groups of three nets which each have to go to the same gate, but two nets in each group can be swapped as well), but it’s a similar issue — it’s hard to know how to assign them at schematic time.
So, is there any mechanism in KiCad to leave deciding WHICH pin to use, until board layout time?
I imagine something like naming the nets leading to those pins, and then tagging compatible pins on the part (eg. ųC) with those net names as a way of saying, “it can connect to any one of these”… (Or going the other way slightly, tagging pins with a set of capabilities, and the net with the set of capabilities it requires). And when one of those nets are selective, having all the compatible pins highlighted.
You are talking about two different (albeit similar) features
I’ve never seen “late binding” feature, but similar functionality is pin swapping. Here you make the schematics and then you swap two pins during layout and this information is back annotated to the schematics automaitcally. For 5.1.x this can be done via action plugin Swap pins. You place the label directly on the pin (no wire between the pin and the label). And when you swap, the schematics is annotated automatically (though the eeschema has to be closed at the time.
Look at Swap units action plugin. As before eeschema has to be closed when swapping.
I agree that the solution is a bit awkward (as eeschema has to be closed), but it is the best at the moment (for 5.1.x). The 5.99 branch has some backannotation support added in, but I doubt it could be used for pin/unit swapping.
I’m a simple guy and like simple solutions.
I can also afford those simple solutiond because I do not have to do this often, so a simple workflow for me is better than a more complicated workflow that could work better if you used it enough (which I don’t).
I generally make the initial schematic, and then if it does not work out on the PCB, I go back to Eeschema (Dual monitor setup), change the schematic a bit, and hit [F8] to put the changes into Pcbnew. With both programs open next to each other it’s quick, easy and simple to have a few iterations of this.
Maybe when eeschema acquires Python scripting in v6, the swapping can be done at the schematic and propagated to the PCB? That’s how I’ve been doing it manually anyway.