Iot: Separate System.Device.I2C from System.Device.Gpio

[deinok]

In some cases you don't need Gpio access. So splitting this in a more granular way can help reducing the size of the final application.
Also, as I2C dont have native code it could run in more runtimes.

[joperezr]

Hello @deinok. This library isn't very large to begin with so I think that it would be too much overhead if we wanted to split the library into 4 different ones by having one per protocol. And for your suggestion about making it run in more runtimes, the IL targets linux only, so this will be able to be restored and used on any runtime that is linux based. Today, it will only fail on non-arm32 runtimes if you try to use the GPIO native methods, but given that the concern here is I2C, that part should just work.

[shaggygi]

I always thought from the early days we should have split these into separate libraries... similar to how WinRT did. However, I wasn't sure how you could expose the internal Interop libraries as it appears to be common code between some of them. I could be overlooking something here, so it could be possible.

I'm not sure how to get around referencing when creating software implementations unless creating yet another library just for it. For example, #122 will eventually be a SPI device using GPIO pins. I'm assuming this would be a GpioSpiDevice.cs under the System.Device.Spi namespace and folder. IGpioController and IGpioPins would help make this work maybe if they were separate libraries? It would be the same for I2C, as well. In addition, many bindings use GPIO and I2C/SPI references together (but you could reference both packages if/when needed for those binding libraries).

While we never had a detailed discussion (to my knowledge) on future libraries/features under the System.Device.* and repo, I'm actually okay with having the 4 main I/O sections (GPIO, I2C, PWM & SPI) under the one System.Device.Gpio API. Separate would be nice, though. A tidbit on my stance for future thinking would be to have separate APIs/packages that make a little more sense like the following:

• System.Device.Bluetooth
• System.Device.Can
• System.Device.Hid
• System.Device.Serial (possibly, even though we already have the legacy Serial.IO.Port)
• System.Device.Usb
• Other?

[deinok]

@joperezr Let me explain it a bit more.
As dotnet can run in x64, arm, arm64 and its equivalent alpine versions, if we use native code we need to publish the .so for each of this combinations, that would be a lot of size for just using I2C.
In our case we use CoreRT for reducing the size of the final executable.

Also for me seems more natural that if somebody wants to access I2C to add a reference to System.Device.I2C insted of System.Device.Gpio

[joperezr]

The .so image we PInvoke into is very small in size as all we do is basically a shim to call into libgpiod library which is not part of our package and is something that should be installed on your system, so I don't think that you should be concerned on size of the executable. This is litterally all the code in our .so file: https://github.com/dotnet/iot/blob/master/src/Native/System.Device.Gpio.Native/libgpiod.c

We initially thought about separating the library into protocol-based libraries, but we decided not to do it at that point since we wanted to have only one library for all of the device protocols. Is there a specific reason why you would want them to be separated other than size?

[deinok]

Just because seems more intuitive for users to have it splitted. For example, a device with just I2C interfaces should not have GPIO, SPI, etc... code in it.

Also, I have found some problems with having precompiled native code in some embedded devices. For example MUSL based devices.

[joperezr]

Many .NET libraries are like this already, for example, System.Collections.Generic has pretty much all of our data structures, even though a specific app might just be using List and won't need Dictionary code in it. Honestly making the change now to have this be separate libraries would involve some rather large work items and we are aiming to be close to stabilizing soon, so I would rather not do this if there is no strong reason why we shouldn't keep it as is.

[deinok]

@joperezr Yes, but for example System.Collections.Generic don't have native code, and its mostly CPU actions insted of device specific IO.
Also, I would prefer spliting the libs before going stable releases than after.

[joperezr]

I agree that if we were to split the libs we should need to do it before we go stable, but I still don't seem to find enough of a reason for doing it. I guess it is not yet clear to me, but is your primary concern regarding app size? If not, is it just that the name of the library is System.Device.Gpio which for you that implies that you are using Gpio only and not I2C? If the latter, then we can probably think about renaming the library before going stable to something that encapsulates all protocols.

[deinok]

@joperezr yes, is a mix of size, naming and separation of protocols.

[shaggygi]

I originally wanted to see this separation, as well. At first, it seems logical to separate... if I'm using SPI, then that's the only library I want. But if you start getting into the code (and see some of the current issues/features that need to be added, you'll notice it creates a little more complexity to manage long term.

IMO, I don't believe we will be separating the 4 types at this point as they 1) are core use when working with pins and 2) somewhat utilize resources between whether it be code/internal memory/hardware/etc.

As a side note related to separation... I do believe we must separate the different dev board dependencies (RaspberryPi3Driver.cs, HummingBoardDriver.cs, etc.) as that doesn't make sense to include in core API. This is for another topic to discuss/determine/complete, though.

[deinok]

But if you start getting into the code (and see some of the current issues/features that need to be added, you'll notice it creates a little more complexity to manage long term.

Could you point me to some of this examples? It could help me understand better why is not splitted by default.

[shaggygi]

An area I would start with is the Interop folder.

[deinok]

@shaggygi All I can see is wrappers around system calls and wrappers around libgpiod. Something that doesn't look like a problem for splitting the libs and concepts

[joperezr]

It is probably hard to see the relation right now given that we don't yet have classes for software implementation of I2c and SPI, but eventually we will add them and that will make SPI and I2C tightly coupled with GPIO which is why we also envisioned them all in the same library. As for the board specific drivers (RaspberryPi and HummingBoard) I do agree that we can probably move those to their own assembly.

[shaggygi]

To add to @joperezr, see this proposal and it will make a little more sense on coupling.

[deinok]

Hmmm, I think I see the point now, for the moment the libraries seem pretty decoupled. But doing things like SPI over GPIO couples this two one. The same for I2C over GPIO, etc...

[shaggygi]

@joperezr Seems like we can close this now based on the last few comments?

[joperezr]

Agreed 👍 . Closing