Adding virtual GpioController and virtual GpioPin

[Ellerbach]

Adding virtual GpioController and virtual GpioPin. This allows to recreate a GpioController from different GpioPin created form potentially very different GpioController.

Microsoft Reviewers: Open in CodeFlow

[joperezr]

Not sure if this proposal was discussed in a meeting I wasn't part of, but I have some questions about the reason why this would be needed. I thought in general we agreed on two models:

• Cases were all of the pins for a specific device come from the same controller: These cases should just be solved by having the device take in a gpioController in one of its constructors, that has access to all of those pins.
• Cases were pins used by a device come from different controlelrs: These cases should just be sulved by having the device also have a constructor that takes in individual GpioPins.

The whole reason why we added GpioPin was so that we wouldn't need something like this (which seems to be an approach that uses an emmulation to mix the two scenarios above) since devices can just take individual pins, and we also agreed all devices would get constructors that took Gpio Pins in favor of this. Am I missing something here?

[Ellerbach]

@joperezr yes, we discussed in one of the call. As we have a lot of bindings to adjust, idea is to have a transparent way to use a virtual GPIO controller! So having a virtual controller will solve this issue of having to add all those new constructors and adjust all the internal codes to support GpioPin. Because, it's not just adding ability to have a GpioPin in the constructor, it's about adjusting all the logic in all the bondings to replace GpioController.Write, Read, etc by the GpioPin.Write, Read, etc.