pcb-rnd knowledge pool

Abstract: Details on the plan for a pcb-rnd feature for semi-automatically upgrading footprints on a board based on versioning footprints.

  Imported from the mailing list archives.

Background: chapter 2 of the bedrock footprint design manual

The full mechanism consists of three levels.

1. footprint attribute

The first level is for handling forward annotation and is already fully implemented for many years.

There's a footprint= attribute which stores the footprint name or in case of parametric footprints the whole parameter line. This is saved in the board file in each subcircuit. When you change your footprint attribute on your schematics and do a new forward annotation, the annotation contains the whole design, so all components (and their fotprints). pcb-rnd on import compares the requested footprint strings with the subcircuit stored footprint attributes and updates the footprint automatically on mismatch. This handles the case of the user changing the footprint attribute.

2. footprint/generator versioning

The second level doesn't yet have any code but it's been on my TODO for a long time and in fact it's been requested on the geda-user mailing list since the mid 2000s. This is about footprint versioning. This is the case when your schematics doesn't change but the footprint file in your library changes. You may (or may not) want to upgrade your boards to the new footprint version.

In that case we could use the footprint attribute again to figure how to get the same thing (minus library search paths, see later at the third level), then we could load/generate the new footprint and compare versions to make sure we got a newer, not an older thing and optionally offer the user a list to verify and decide which ones to upgrade. The code for footpritn replace in-place is already there, you can do that with shift click over a subcircuit when you have a subcircuit in buffer.

It attempts to preserve orientation and attribute values (refdes, value, etc). So if the new version of the footprint is generally the same as the old verison, just fixed some mask pattern or tweaked pad geometry, it probably wouldn't need any manual edit after a version upgrade.

For this second level we need a version attribute and we need to control the syntax of its value, at least to the level that we can compare two versions (that's the "computer sortable" thing in the manual). For bedrock-rnd we should have unified version numbering format to make user's life easier (whendoing manual comparison).

For parametric/generated footprints the version field didn't _feel_ right, because footprint data changes much more often because you change parameters and from the workflow aspect that could be considered as "a new version of the (generated) data" too. The equivalent thing, getting an actual fix while keeping the same footprint conceptually could be implemented by a change in the script/program that generates the footprint. Which could be implemented by looking at the name and version of the _generator_. That's why the manual requires to store that in the output.

So at the end when we get to the footprint upgrade function, the code will need to look for both the version attribute (would be typical for static file footprints) and the generator attribute (for parametrics) and would need to handle the situation when neither or both are present.

3. UIDs

Finally the third level is UID.

The above footprint upgrade system depends on the assumption you have the same libraries and library search paths at footprint upgrade time that you had earlier, when you did the forward annotation. In practice: if you had 1206 from the stock pcb-rnd footprint lib in forward annotation then you change your library directories/files or your library search path config and you get your own 1206 footprint from your own lib earlier in the search, that's a problem: we can't say if the mismatching 1206 is "newer" or "older", that's not a versioning question, it would be loke comparing apples to pears.

It's not a new problem: we had this assumption for subsequent forward annotations already. For sch import as long as the footprint attribute didn't change, pcb-rnd doesn't even look in your lib, so the new 1206 footprint after the library search paths change wouldn't replace the original 1206 upon a forward annotation. In other words, we simply had the assumption you won't change your libraries (or search paths) for an existing board.

In a footprint version compare/check/upgrade we could however detect this by the uid of the subcircuit (this is not an attribute but a property). When you handle an existing subcircuit, e.g. load it, edit it, or place it on a board, the uid is preserved. When you create a new subcircuit from scratch, a new uid is generated.

The user designing a footprint needs to be aware of this: a new footrpint that's fundamentally different from another should be created in a way that it has a new uid, an existing footpritn that get's a fix or upgrade should be done in a way the uid does not change.

At the end a footprint upgrade feature in pcb-rnd would also compare subcircuit uids to figure if the candidate footprint "is the same" or a different one having the same footprint name. In the latter case comparing version comparison would be skipped.

Final thoguhts on the footprint upgrade feature

At the end I imagine this footprint upgrade feature would be a semi-manual process, with a dialog box: when pcb-rnd figures there's a new version or a totally different footprint with the same name, it would include it in a list, maybe with a preview and a way to visit existing instances on board, and the user would be able to decide if the upgrade for that specific footprint should be done or not.