Back-annotation to gschem

I've added the capability to back-annotate pin swaps to gschem, to my fork of the gEDA project. Notice the commit "Add scheme function to swap pins."

To implement this, I took heed of David Wheeler's advice: "All problems in computer science can be solved by another level of indirection ..." (I stopped reading right there). Applying this to the gEDA data structures, I've added some magic behaviours to some attributes:

• vpads - stores a map between a chip's functions and its pads. Think: "virtual pads". This is the one that pin swapping will affect.
• packagepins - stores a map between a chip's pads and the pins on the package it is in. We need this to deal sanely with the same chip in different packages: PLCC vs QFP.
• uuid - to uniquely identify a component. More unique than refdes! Uniqueness should survive the text editor, and it should survive having multiple sheets loaded with different "U101" in each.

That should give you an idea of how I implemented pin swapping. There's more though, and it relates to a slotting mechanism I've built earlier and that doesn't fail the "mental model = program model" test. In fact the pin swapping works only in the context of this alternate slotting mechanism.

• pinnumber - you don't actually write a pinnumber anywhere explicitly - the slotting mechanism will derive the right pin number for you from the other attributes.
• pinfunction - the symbol defines this. abstract/opamp.sym, for example, has "pinfunction=noninv" on the pin next to the "+" label.
• slotowner - in a symbol, it references (by uuid) a component that has slots, presumably slots that are "compatible" with the symbol.
• slotname - defines which slot to use. In linear/lm324-slots.sym, I've defined slots named "opamp1", "opamp1-powered", ... (copies for 2, 3, 4) ..., "power".
• slotrewrite - defines which attributes in the symbol should "inherit" their value from the component they're attached to. Useful for refdes and part.
• slotmap - a map from symbolic pin function to an entry in the vpads map.

(Some of the map-like attributes are inferred to be identity maps if they are missing, or are missing specific entries.)

Time for some screenshots. I'll do only one pin swap to illustrate what PCB might one day do as part of a sequence of swaps that, together, effect a gate swap. Let's supppose I have two opamps, and the PCB tracks want to route crazy, unless I can swap them. Before I touch anything, I have opamp1's pins as 1, 2 and 3, and opamp2's as 5, 6 and 7.

But I don't like that. I want them exactly the other way round. I'll start with the output pin:

(Notice the use of uuid - which PCB can certainly know via its own attributes.) Oh, did you see the pimped-up REPL I added?

Hey presto! opamp1's output pin is now 7, and opamp2's is 1!


I'll leave it as an exercise to the reader to do the other two pins. Bonus points for teaching PCB to understand DJ Delorie's syntax for specifying swappable groups of "THINGS". I'm not sure what the right specifier for a 324 should be. Maybe ([2,3,1],[6,5,7],[9,10,8],[13,12,14])? But I don't see the power pins - 4 and 11 - in there. Meh, that's for another day.