Chiming in here as I’m working with dans on this particular project.
It might be useful to provide a little extra context on what we’re trying to accomplish and the reason for the multiple aliasing we’re doing.
We are working on building a modular configuration that allows users to share a common set of includable cfgs regardless of the underlying controller.
To that end, we have been building a set of pin maps for different controllers that are essentially made up of the two parts dans posted above.
The first part contains pin mappings that are aligned with the physical silkscreen/manufacturer’s labeling on the board. We are then taking these aliases and remapping them to a second set of standardized aliases that we’re using across all controllers.
We can then split up components like motion configuration, probes, temperature sensors, extruders, etc into discrete selectable cfg files using these standardized pin names to allow users to quickly and easily build a configuration simply by choosing the parts that are in their printer.
We currently have a rough proof of concept built and working with a couple of BTT boards with UART stepper drivers. It’s largely undocumented at this point but can be found here:
As dans mentioned, where we’re having this fall apart is with Duet 2 boards with SPI based 2660 drivers. The Duets tie enable for all drivers to a single pin. If a pin can only ever be referenced in the configuration by a single alias, this more or less breaks our abstraction model for Duet boards since other controllers use multiple pins for this function and thus need separate mappings.
X_EN and Y_EN are separate pins on most boards and need to be treated that way in the config, for example, but are the same pin on a duet. The current aliasing requirements as we’re understanding them mean that we can build a config that’s easily dropped in for most boards or one that works on the Duet, but not one that works on both. Being unable to map a single pin to multiple aliases is really the only thing that’s stopping it from working across the board.
From my perspective, this seems like worthwhile functionality. Helping people sort out pin mapping has generally been one of the biggest hurdles for getting them on to Klipper in my experience. We seem to have most of the pieces for a working abstraction layer to simplify this in place, but this particular quirk of Duet boards has been a roadblock for us.