Arduino/Firmata device support

[pgrawehr]

Fixes #262

This adds support for controlling an Arduino board directly from a PC. The arduino board will run a special firmware called "Firmata", that interprets the commands from the PC and set it to hardware. See Readme for details.

This also includeds an ArduinoBoard class, which is a prototype for #878. I'll later push more commits that will show how that would look like with the existing Windows/Linux drivers (but that's somehow also dependent on #1038, because things get complicated otherwise, see #1037 for one of the issues)

@Ellerbach Can you check whether that interface would fit your FT4222 as well?

The first implementation for the firmata driver was from https://github.com/ms-iot/remote-wiring. MIT license.

[joperezr]

NIT: I believe Arduino is kind of a very Generic Name to have this be the Arduino.csproj. Might get confusing people thinking that this is a full Arduino binding which is not really the case. Can we instead name it as Arduino.Firmata or something like that?

[joperezr]

I’ll continue reviewing this weekend but since you wanted to know I definitely think we are on the right track here. I love how the API surface is minimal and very easy to use, and won’t require new knowledge as in the end you are really just exposing spi, i2c and gpio devices.

[pgrawehr]

NIT: I believe Arduino is kind of a very Generic Name to have this be the Arduino.csproj. Might get confusing people thinking that this is a full Arduino binding which is not really the case. Can we instead name it as Arduino.Firmata or something like that?

Maybe use "Firmata" as namespace and ArduinoXyz for the concrete class names?

[Ellerbach]

Can you check whether that interface would fit your FT4222 as well?

@pgrawehr, it's a very complementary approach. Same philosophy: give something easy on a "normal" Windows or Mac or Linux an access to GPIO, SPI and I2C with the PWM flavor and more.

You went for a similar approach with a specific core communication element (your ArduinoBoard and the specific Firma classes). And for specific GPIO, I2C and PWM, for the driver which is the approach I took as well for the FT4222. I'm just surprised that there is no SPI support in Firma. Is there a way to get it somehow? That would be super nice as well.

[Ellerbach]

All up, same comment at @joperezr, I really like the project, the fact that like for the FT4222 we have simple drivers and something very easy to use. That gives more way to enjoy .NET Core and IoT on various hardware! Even if the cost of performance can be a blocker for some of the devices. So would be good to explain in the Readme some of the limitations.

[krwq]

@pgrawehr what's the remaining work here aside from the merge conflicts?

[pgrawehr]

@pgrawehr what's the remaining work here aside from the merge conflicts?

I don't remember in detail, but one of the open points is how we go further with the board PR. This basically bases on that one (or actually, a slightly older proposal of it). So it needs to be clarified whether the concept matches our future strategy.

[krwq]

@pgrawehr what specific pieces of board abstraction is must have for this PR to move forward?

[pgrawehr]

@krwq : it's been a while now, so I'm not 100% sure and will need to check again.
What's certainly needed is the unsealing of the GpioController, ideally also the abstract board class, but that could likely also be put in later (eventually with breaking changes though, when different method names will be used)

[joperezr]

[Triage] We would like to go forward with this PR but it seems like it is not clear which are the blockers here. @pgrawehr when you have some time do you mind checking what you need from us in order to move this forward?

[pgrawehr]

Discussed via Teams: I'll need to update the PR with my latest Arduino branch. The PR depends on the GpioController unsealing, so I'll probably copy that change here, so it can be done without the full impact of #1128.
The proposed AnalogController can stay in Iot.Devices for now.

Some breaking changes are expected when any of the following is finally decided on:

• The board base class is defined
• AnalogController is moved to System.Devices namespace

[Ellerbach]

The proposed AnalogController can stay in Iot.Devices for now.

For the ADC we can as well get inspiration an try to align with the nanoFramework one: https://github.com/nanoframework/lib-Windows.Devices.Adc. There are good elements that we already discussed in the related issues #878 and #90.

[Ellerbach]

AnalogController is moved to System.Devices namespace

And that does remind me as well that there are quite some Analog sensors in GrovePi. Clearly soem real work on that would allow to reuse some of the sensors but as well having GrovePi being a proper GpioController and AnalogController at the same time in a more reusable way.

[pgrawehr]

The proposed AnalogController can stay in Iot.Devices for now.

For the ADC we can as well get inspiration an try to align with the nanoFramework one: nanoframework/lib-Windows.Devices.Adc. There are good elements that we already discussed in the related issues #878 and #90.

Not sure I can fullfull all of those requirements just yet, but I'll try. The Nanoframwork API is conceptually a bit different than the approach here, but it is also pretty small.

[krwq]

see comment above, consider moving this logic into Initialize (currently it's there inside of the lock, but consider doing this check before and inside of the lock)

[krwq]

@pgrawehr looks good to me with some comments

[krwq]

@pgrawehr I think #1039 (review) got missed other than that LGTM

[krwq]

I'd recommend to fix the missed comment but nothing blocking to merge this from my perspective. Thanks for this great contribution!

[krwq]