PinInfo conflicts in BoardPinInfo can cause much confusion

[EAGrahamJr]

While implementing a new expansion board, I noted that addGpioPinInfo also manages the internal gpios map. However, there doesn't seem to be any defined scheme or means to prevent over-riding this pin information. Moreover, the AbstractDeviceFactory automatically registers itself with the native device factory, thus making it even more likely that gpio pin numbers can collide when multiple extenders are used.

While the "single pin numbering" works great for things like prototyping straight off of the device, in a more practical sense this seems like won't work for a more complex system with more than one expansion board (e.g. OneWire, I2C, SPI, etc.) - although if you're using an expansion board, you would think you'd want to specify the factory anyway, or even get it from the factory :smiley: .

No ideas/solutions pending.

[mattjlewis]

Yes - all that code evolved a bit too much without much of a design and a bit unloved as I've treated it largely as internal as not part of "API", although very much part of the service provider interface.

[EAGrahamJr]

I've actually made it work pretty well by making sure the expander DeviceFactory has special "helper" functions to create said devices (here). Since I'm using an internal function to generate the PinInfo, that pretty much assures that I can't get internal port conflicts (e.g. port 1 for both analog input and digital output), but that's relying on the "key name" (and I just found a minor formatting bug in an error message :smirk: ).

It's workable as-is, you just have to be careful with what you're doing.

[EAGrahamJr]

Closing - moving to a discussion.