Multiple controllers, same pin inconsistency

This might not actually be a bug but it’s something that we might need to discuss.

I was testing the framework, and created the following scenario:

• Have an app that deals with turning a light on and off
• Have another app that checks if a led is on, and if so do something else.

Essentially, we will have 2 controllers that will use the same pin.

From my understanding, 1 controller should only work with a set of pins, and it should not “play around” with pins used by another controller.

Steps to reproduce

using System;
using System.Device.Gpio;
using System.Threading;

namespace temp
{
    class Program
    {
        static void Main(string[] args)
        {
			GpioController controller1 = new GpioController();
			controller1.OpenPin(10, PinMode.Output);
			controller1.Write(10, PinValue.High);
			Thread.Sleep(5000);
			GpioController controller2 = new GpioController();
			controller2.OpenPin(10, PinMode.Input);
			controller2.Read(10);

			controller1.ClosePin(10);
			controller2.ClosePin(10);
        }
    }
}

Expected behavior I would expect to be able to read the value and the pin keep the same state (High - meaning the led is on).

Actual behavior The LED turns on, but when I read the value from it, it reports as LOW and the LED turns off, although it was expected to be HIGH.

If I try to simplify (this might actually be another issue, let me know if I should create another) and do:

• First app turns ON the LED and exits (closes the pin and ends)
• As soon as I close the Pin, the LED turns off because the state is set to LOW. (why does this even happen?)
• Second app will always read low, since the first app set it to LOW when closed the pin

Versions used

Add following information:

• dotnet --info on the machine being used to build

.NET Core SDK (reflecting any global.json):
 Version:   2.2.402
 Commit:    c7f2f96116

Runtime Environment:
 OS Name:     Windows
 OS Version:  10.0.18363
 OS Platform: Windows
 RID:         win10-x64
 Base Path:   C:\Program Files\dotnet\sdk\2.2.402\

Host (useful for support):
  Version: 2.2.7
  Commit:  b1e29ae826

.NET Core SDKs installed:
  2.2.402 [C:\Program Files\dotnet\sdk]

.NET Core runtimes installed:
  Microsoft.AspNetCore.All 2.2.7 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All]
  Microsoft.AspNetCore.App 2.2.7 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.NETCore.App 2.2.7 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]```

- `dotnet --info` on the machine where app is being run (not applicable for self-contained apps)

It was not possible to find any installed .NET Core SDKs Did you mean to run .NET Core SDK commands? Install a .NET Core SDK from: https://aka.ms/dotnet-download

Host (useful for support): Version: 3.0.0 Commit: 7d57652f33

.NET Core SDKs installed: No SDKs were found.

.NET Core runtimes installed: Microsoft.AspNetCore.App 3.0.0 [/home/pi/dotnet/shared/Microsoft.AspNetCore.App] Microsoft.NETCore.App 3.0.0 [/home/pi/dotnet/shared/Microsoft.NETCore.App]

To install additional .NET Core runtimes or SDKs: https://aka.ms/dotnet-download```

• Version of System.Device.Gpio package: Version=“1.0.0”

[microhobby]

@joperezr ok, make sense. I fully agree to communicate and encourage the use of libgpiod. In the future I see no way out, these interfaces will be disabled in the distros. Fedora has started shipping without /sys/class/gpio for example: https://fedoraproject.org/wiki/Architectures/ARM/gpio

And I think other distros will follow this move soon.

[joperezr]

TBH I don’t think it isn’t a very good idea to package a third party library and distribute it through our NuGet packages since that would mean that everytime that libgpiod has a fix, update or new feature we would have to react by shipping a new package again. We have cases in dotnet core where we depend on native libraries that are not preinstalled on all distros (like icu library for all of our globalization and localization libraries) which we don’t package with our product, but instead just call out that if consumers want to use that feature they will have to preinstall some libs. I’m totally fine with communicating that installing libgpiod is the recommended way, or even condition some future new features only if you have libgpiod if not possible to do them with sysfs, but having the ability to fallback in case you really don’t want to install the native library is still valuable I believe.