Add System.Device.Adc.{AdcChannel, AdcChannelMode, AdcController} and port Mcp3008 device binding to new surface area

[joshfree]

We need to standardize ADC device binding APIs, using Windows.Devices.Adc as a starting point, and update the 10-bit ADC Mcp3008 device binding accordingly.

https://docs.microsoft.com/en-us/uwp/api/windows.devices.adc.adccontroller

https://github.com/dotnet/iot/tree/master/src/devices/Mcp3008

[joshfree]

@joperezr would you be interested in picking this one up next?

[joperezr]

I was planning on working on testing infrastructure next, but I can also do this one instead.

[shaggygi]

Referencing https://www.linux.com/learn/how-get-analog-input-beaglebone-black

[shaggygi]

This might help... [Proposal] Provide interfaces for different controllers

[krwq]

ADS1115 is also in progress: #191 Might be worth taking a closer look soon and convert stuff like FSR to use generic ADC

[joperezr]

The thing about this is that technically ADC is not really a communication protocol, so I'm not so sure if the right place for this would be the main library with a namespace like System.Device.Adc. IMO, this is something that should probably live on the device bidnings package instead, perhaps some sort of interface that all ADCs need to implement.

[krwq]

@joperezr ADC is a device so System.Device sounds like a good place 😄

[joperezr]

For the namespace we’ve been using System.Device.{CommunicationProtocol} Where Communication protocol is a Device protocol. We currently have Gpio, Pwm, I2c, and Spi. That means that this would be the first namespace where the third part of it is not a protocol. For device bindings. We have been using Iot.Device instead, so this would probably be something like Iot.Device.Adc

[shaggygi]

@joperezr so are you suggesting not having System.Device.Adc in core API similar to System.Device.Gpio/I2c/Spi/Pwm?

If so, I disagree as there are dev boards that have true ADC pins (like BeagleBoard Black). We should have similar classes/interfaces for controllers/drivers as we're doing with Gpio/Pwm. Therefore, dev boards and bindings could implement them. For example, the Mcp3008 could also implement IAdcController like Mcp23xxx implements IGpioController.

If I misunderstood you.... then disregard 😕

[krwq]

I think we should not think that much about how to package this yet and rather what abstraction is useful right now. Once we are closer to shipping then we have more conversations of what to put where (and it makes sense to put pure abstraction in different place than implementation) but I think we still got some time until then and as long APIs are experimental it is easier to put them in one bag for now.