Iot: 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: https://github.com/dotnet/iot/pull/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 :smile:

[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.

[joperezr]

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.

I see, I actually wasn't aware that there are some devices that have pins for this particular pourpose which then does mean that it would make sense to have this on the main library. In any case, as @krwq says, I think that because of what @shaggygi brings up it would be fine to put the implementation on the main library for now, and move it later if we don't think it should be there once shipping is close.

[Ellerbach]

That would be really good to have an IAdcController interface like the IGpioController one. I would be able to implement both on the GrovePi (see https://github.com/dotnet/iot/pull/246) to be used fully transparently as a both devices. that would simplify how to create some basic sensors like basic buttons, basic analogic sound sensors, etc.

[joshfree]

@joperezr my thinking is we could use https://docs.microsoft.com/en-us/uwp/api/windows.devices.adc.adccontroller as inspiration for an IAdcController

[krwq]

We are currently questioning if we should have these interface. For things which take ADC as an input we think the users should use Func<double> - ADC doesn't return data in any specific unit (relative voltage?) so the data is not really bound to ADC and could be anything.

We would need to see some specific examples to see what problems it would solve to have them. I haven't personally had much chance playing with ADC to think of any so would be useful for someone who has to provide something.

[Ellerbach]

We would need to see some specific examples to see what problems it would solve to have them. I haven't personally had much chance playing with ADC to think of any so would be useful for someone who has to provide something.

All ADC are measuring in byte, int, long or equivalent (some can be negative as well). They all have a reference ADC which can be as well one of those.
For specific calculations, you may need the both values and not just the result. Good to have the result as a float as well but that won't be enough in some of the cases.