Conversion between InputPin and OutputPin

[peckpeck]

We should be able ton convert InputPin to OutputPin and vice versa.
This should be done by consuming the xxPin object and creating a new one.

This would make the compiler automatically detect error based on the pin type while still allowing pin mode change. And it would remove the need for an IoPin that is a cause of bugs that can only be detected at runtime.

[peckpeck]

Note that removing IoPin would help removing some duplicate code and many macros in the gpio code.

[golemparts]

IoPin was added to reduce overhead when pins constantly switch between input and output, such as charlieplexing and bitbanging I2C, where every bit of performance increase counts. I do like your suggestion of being able to convert between the various pin types, which should help to remove some implementation clutter.

[peckpeck]

Another usage of IoPin is putting a ping into alt mode. You either need to implement that within Pin or have an AltPin type (that would have no specific method i think).

[peckpeck]

I could try to implement this, but would you accept a PR that would remove IoPin ?

[golemparts]

I appreciate the offer, but I would hold off on submitting a PR, as I would like to keep IoPin as is (for now) since it serves a purpose, and many of the existing structs might change based on the article you shared about zero sized pins. Once 0.12.0 is out the door and I've thought a bit more about any sweeping changes, I'll definitely let you know where I could use some help.

[peckpeck]

One thing that is not present in the zero sized pin article, is that it is impossible to give those pin a generic type, so you cannot put them as is in an array or a vec.
The solution is either to create an enum with all those pin, or to create a Pin trait and store boxed traits.

[peckpeck]

I've got a question on this subject, what is the usage of does reset on drop ?

• is it to leave the pin on the same state after the program ends
• or is it to use a pin, dropping it (without reset) let a subfunction acquire a pin, drop it (with reset) and reuse the pin ?
• something else ?

[golemparts]

I've got a question on this subject, what is the usage of does reset on drop ?

• is it to leave the pin on the same state after the program ends

Correct. By default, GPIO pins (and other peripherals where applicable) are reset to their previous state when they're dropped (although this won't work if a program is terminated abnormally). To prevent this behavior in specific cases, reset_on_drop was added. For instance, a program could be used to switch a connected device on or off, where the state of the pin needs to be preserved after the program exits.

[peckpeck]

I understand, in this case,wouldn't it be better to implement it once in the Pin structure instead of in each pin type

[golemparts]

wouldn't it be better to implement it once in the Pin structure instead of in each pin type

I agree that's something to consider, however I could argue for both implementations. On the one hand it's a good idea to keep the code in one place, even though it technically already is, and just copied using a macro. On the other hand, the mode isn't changed until a Pin is consumed, and it makes sense to balance the mode change in the constructor of InputPin/OutputPin/IoPin with a reset in the destructor.

[peckpeck]

Indeed

[peckpeck]

but it prevents me from implementing into_output in InputPin.

By the way, I would ague that it should be implemented in the Gpio struct 😁 since it is the struct that starts with the program and goes out of scope when it finishes, ie when the reset should happen