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:-

protected:
    PinName _pin;

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:-

• Add an additional parameter to my library function, eg foo(DigitalOut *p, PinName name); so that the caller has to pass the pinName along with the pointer to the object. But that's just "clumsie" and also results in my library repeatedly storing data that already exists in DigitalOut.
• Create my own class derived from DigitalOut that stores the pinName. But a) that again reproduces a copy of _pin that already exists and b) Joe User tends to get nervous when you say "you have to use my version of DigitalOut and not the official Mbed version".

When you create your own class derived from DigitalOut, you should be able to get the PinName (that's what 'protected' means). But I would also prefer to get such a member function since otherwise libraries would force the users to use classes other than e.g. DigitalOut.

Btw.: Currently I'm taking the PinName as parameter and create the DigitalOut object by myself. This means that when a pin is used for multiple purposes, there are multiple DigitalOut objects referring to the same pin. Can this cause problems?

That's what I meant when I said "Joe User tends to get nervous when you say 'you have to use my version of DigitalOut and not the official Mbed version'". Users like to use the Mbed library, they get nervous when you force them to use a "homebrew" class, even if that class is basically identical to the orginal except it exposes protected properties for reading. Although I would only use a "read property" method, users will be aware your class has write access too. Without vetting your code for your class, users tend to feel uneasy.

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

Regards "use case", I'm building a generic serial protocol that uses plugins. However, I found that using Base::name is a god workaround, allowing the "plugins" to connect to named objects instead. Probably not a workaround but a better/proper solution. I assume Base::name is used for RPC? My use case is similiar.

I'll publish the code when it's ready. The idea is to have libs at both ends. I have teh Mbed end done and am worling on some C#/C++ for the PC end. Want to get demos in place also that show it working.