[Proposal] Add ConnectionType enum to System.Devices.* API

[shaggygi]

Would it be worth adding a new ConnectionType enum (or similar) as a way to determine how devices are connected & communicate. This is mainly a helper for bindings as it will most likely be redundant code in each project.

When a binding is instantiated, we will usually have multiple options (SPI, I2C, GPIO) depending on device capabilities. For example the MCP23XXX has both I2C and SPI interface options and because we can bit-bang those protocols... this makes 4 options. As shown in early MCP3008 binding, we currently have a private CommunicationProtocol enum that is set based on the constructor called. This is used to determine what internal method to call during reads/writes.

namespace System.Device
{
    public enum ConnectionType
    {
        I2c,  // Represents anything that inherits from I2cDevice
        Spi,  // Represents anything that inherits from SpiDevice
    }
}

There could be other choices, but have not reviewed enough to know what makes sense. What about Pwm, PwmGpio, Serial, etc.?

I used ConnectionType as it seemed to fit better with the ConnectionSettings scheme.

[joperezr]

Personally I don't think this would be super useful as public API since it is only really used by device bindings. Instead I think it might be useful to add it to the IoT.Device namespace and only as a common file that bindings can import if they need this functionality.

[shaggygi]

Yeah and it's mainly needed when there is a component that includes both interfaces (although there are many devices in the wild that do). I had to use it while working on the Ssd1306. In addition, the code didn't seem as bad when not having to check between I2C, SPI and GPIO for both. Assuming we will eventually have a GpioSpiDriver and I2cGpioDriver, the check isn't so bad.

I'll go ahead and close this issue for now. Thx