Drivers should be outside of System.Device.Gpio

[krwq]

It seems to me we're going in the direction of putting all drivers into System.Device.Gpio. This has a long term pitfall: the library will grow in size indefinitely which is not desired - also all of the boards are useful having drivers public (i.e. for scenarios where driver is missing and user want to extend existing) which further pollutes the low level library with stuff most users won't need. When you use a specific board you really only need driver for this specific board.

I feel like we should have some mechanism of only using what you actually need. Simplest and straightforward example could be having a board specific nuget package with only driver for the specific board you're deploying to. For users wanting to have a generic version we could possibly have a way of detection and pulling it all but it should be pay for play and not obligatory (so i.e. System.Device.AutoDetectBoard package or something along the lines).

cc: @Ellerbach @joperezr @pgrawehr

[Ellerbach]

I agree, System.Device.Gpio should stay reasonably small. I agree as well that for a non advanced user, something simple and automatic should be available. What about getting inspiration from Hardware Abstraction Layer (HAL) and Platform Abstraction Layers (PAL)? We may have to build a bit more packages per platform (so 1 HAL per specific board/dongle) and find a way during compilating to bring the right package. Something similar to pulling the right System.Ports.IO when using a serial port. OK, for this one it's OS related, so everything under is already build. In our case, that would require a specific setting. And for non expert users, yes, an autodetect package that may just contain all the packages and test the various platform maybe a right approach. If you are more hobbyist, you just want things to work, no matter what, size of packages won't care much.

[krwq]

Also for drivers I think the same story goes for I2cDevice/SpiDevice/PwmChannel. They should all be in board specific stuff

[krwq]

Here are my thoughts on the System.Device.Gpio: https://github.com/dotnet/iot/issues/1176#issuecomment-692593719 - what I think is that System.Device.Gpio should be just core abstraction with maybe most generic implementations (but ideally move it all out and just leave abstraction)

[pgrawehr]

This could benefit from the board approach, too: You have one instance that knows all the hardware you are using and returns the correct implementation (gpio, spi, I2c...)

[krwq]

Yes, I'm gathering my thoughts on that. I think the Board approach would be related to auto-detection logic and perhaps grouping of features so it's related but not exactly this issue.

[Ellerbach]

Having this level of abstraction would allow most likely to address as well a scenario like described in #8.

[joperezr]

I suppose you are talking about new drivers right? We wouldn't want to move up drivers that already live in S.D.G as that would be breaking, plus we wouldn't want to be in a place where S.D.G requires the bindings package in order to work even in most basic scenarios. We would have to keep at least the default drivers on the main library. All that said, I agree we need to make adding drivers easier to plug in via an external dll, we have discussed in the past and perhaps un-sealing GpioController class would make this much easier.

[Ellerbach]

We wouldn't want to move up drivers that already live in S.D.G as that would be breaking

Some basic Windows and Linux drivers can always be present, that's clear. Now, there is a need because we have quite a lot of examples coming to get more board supports with specific drivers. When you look at the embedded market, it's clear that the notion of boards is present everywhere. You select a board and then boom, you get the drivers and build on top. Look at Arduino as an example. without having to go for always selecting a board before using .NET IoT, as yes, some basic scenarios are covered with basic Windows and Linux support, for specific hats, specific boards, you need more. And for those, we have to provide an easy way to do.

I agree we need to make adding drivers easier to plug in via an external dll,

To make things easy, we can as well have simple executable you can run and which will try to detect all what is supported on your board. In short, testing if you have support for what, including drivers which will seat outside of the normal System.Device namespace. That should be some program that will have all the drivers inside and basically test to load every single one, check if it is supported on the hardware and give you what is supported. Yes, that will require to put in place interface/abstract for specific driver calls, yes, see next point it can be with the existing abstracts. But they'll need to be identifiable as well.

in the past and perhaps un-sealing GpioController class would make this much easier.

Gpiocontroller is one, bu we have I2C, SPI, ADC, PWM and more like this! And yes, we may reuse the abstract class. Worked perfectly for the FT4222 and seems to work for others. But we would have to create specific packages, by board/doungle/whateverakesense and have this easy to plug.

The good news is that because of its success, .NET IoT found usage on multiple platforms/hats/boards and we need to facilitate the usage of those in the most transparent way.

[Ellerbach]

Related to this older one as well: #637

[Ellerbach]

[Triage] We will close this issue based on the discussion. This won't be implemented, size is not the main issue for the CPU world.