Hi Andy, Hendrik,
Interesting suggestion, and potentially good timing. As a background, some of the libraries don't actually store internally their assigned pin numbers; it is often simply used in the setup and never used again (sand not stored, you couldn't necessarily add this member function even if you wanted to without adding pin state).
However, my current sketches look to potentially have objects always knowing their pin assignment; a small memory cost for those that don't currently, but with the main goal being the ability to "reset" an interface without passing it any parameters, including rerouting the muxes etc. This would (among some other things) enable use of multiple interfaces on the same pins, using reset to reload the configuration as you switch between them. Not totally convinced it is common enough, but there are some other uses for a reset which makes it seem more attractive in general.
Do you have some actual use cases for the situations that you are describing that you could share? It would be good to see what design patterns should be supported/improved.
Simon
Hi Mbedders,
I'd like to make a feature request/suggestion. In some of the Mbed libraries thare exist protected properties that it would sometimes be useful to get at. For example, from DigitalOut.h:-
Now, I know under normal circulstances if you have defined a pin then you'll know where it is. However, if you are writing a library function and your library is passed a pointer to an already defined DigitalOut then there's no way to know what pin it's assigned to and I've found that in some cases it would have been useful if public: PinName pinName(void); existed to get at that info (note, that's just a member function to read it, not write it obviously).
The only two workarounds I have for this is:-