It would be great to have the IGpioController to support analogic read and write. That would allow more scenarios. I would be able to implement the interface on GrovePi (see PR 246).
GrovePi offers functions like AnalogRead and AnalogWrite (same as on an Arduino) and allows to read and write analogic values.
Interface should also contains a MaxAdc value.
I believe the plan is propose and add IAdcController at some point. See #90
Yes, that would then make it. I'll comment on the other issue.
@krwq is this something you could help add this week before we ship the next update to nuget on Friday?
/cc @joperezr
@joshfree I can help with the abstraction but not sure if will have time for any implementation.
@shaggygi it seems we need two abstractions:
I haven't thought it through, but seems like it would be similar to Gpio classes including Linux and Windows10 classes along with the related pin classes. I don't think we need the dev board drivers (RaspberryPi3, etc.), but not completely sure.
| namespace System.Device.Gpio | namespace System.Device.Adc |
|------------------------------------|----------------------------------|
| GpioController (Linux/Windows) | AdcController (Linux/Windows) |
| IGpioController | IAdcController |
| GpioDriver (Linux/Windows) | AdcDriver (Linux/Windows) |
When adding these, I highly encourage an API review on the file names. By now, I'm sure I'm a thorn in @joperezr as I mentioned this a few times 馃槈 馃槈 . While I'm all for including the pin type within the names, I also agree with @joperezr as the namespace should be enough to separate what controllers/drivers/pins are of what type. Here are a few examples:
UnixDriverDevicePin.Linux.cs and Windows10DriverPin.Windows.cs where one includes "Device" and the other does not. IMHO, it should not be included.UnixPwmDriver.Linux.cs (and flavors) that include "PWM" and the GPIO UnixDriver.Linux.cs (and flavors) don't include "GPIO". If we go there route of basing off namespace, then remove "Pwm".I think this should be finalized soon as it makes it more difficult to change as we get closer to RTM. See #126 for more details.
@krwq @joshfree I vote to go ahead and close this issue as we already have #90, #125, #260 and #295 that are related.