Iot: Remove dev board GPIO drivers within System.Device.Gpio API

[shaggygi]

The core API includes code specific to dev boards (System.Device.Gpio.Drivers.RaspberryPi3Driver/HummingBoard.cs) and should not. They should be removed and used as a separate package if/when they are needed.

The reasoning is it will cause dependency issues in the long-term when boards become outdated and new ones become popular. By making them a separate package, it would also allow users to understand /reference how to create their own GPIO board package for other processors that become supported.

[shaggygi]

This is essentially the same related to PWM, as well. For example, in the Windows10PwmDriver constructor this is references to the HummingBoard. It seems like this is an unnecessary hard-dependency that should be decoupled.

[joperezr]

The idea here with GPIO, was to have at least the most common and used boards supported as first-party and that they would ship within the library itself. That was the case for the Raspberry pi, and also the Hummingboard (since that one is heavily used on Azure IoT scenarios). For the rest of the boards, we were thinking on having extension libraries (similar to what we have today with the device bindings package) that would provide support for additional boards, since as you point out, having them on the main library would simply not scale. That said, we are currently investigating on how complete is the support with libgpiod library, since if that has all the features and it performs well, then it wouldn't be very useful to have board-specific drivers, as a libpiod driver would suffice. In that case, then I would agree with removing the board specific ones (RPi and HB) to a different library.

For PWM (I2c and Spi) we only really have two drivers (a Unix generic one and a Windows generic one). I don't expect many more of these to come since they are enough to support a wide range of devices, so I wouldn't really treat those the same as GPIO's case.

[joperezr]

@shaggygi given that this was just a question, would you be ok if we close it? Or do you think we should try to move the board specific drivers out of the library and use this issue to track that?

[shaggygi]

Yeah, I think it would be better to rename this and keep if the longer term plan is to remove the board specific code out.

[krwq]

@shaggygi could you also update the first post so it's easy to read the request after reading 1-2 sentences?

[shaggygi]

Sure. My wording can get a little long sometimes.

[joshfree]

Thanks @shaggygi 😄

Closing the issue as part of general issue cleanup in the repro