Iot: GpioDriver for pigpiod socket interface

[ibebbs]

Hi,

I was wondering whether there was any availability of/interest in a GpioDriver implementation which used the pigpiod socket interface for controlling the Gpio on a remote Pi?

Seems to me this would be excellent for rapid prototyping using dotnet-iot from a PC.

A C# wrapper for the pigpiod C interface already exists so it doesn't seem like it'd be too tricky to get a basic implementation of this up and running pretty quickly.

If this GpioDriver implementation already exists and I've just missed it, could someone point me to it? Otherwise, if there's interest, I might take a stab at implementing one.

[krwq]

We currently support only libgpiod and couple others, I haven't heard of this one before. What's the benefit of this implementation over libgpiod?

[ibebbs]

Correct me if I'm wrong here but it looks to me like "libgpiod" provides interop for controlling an on-board GPIO interface. "pigpio" provides interop to a remote GPIO interface by acting as a proxy, relaying commands and state changes to/from a "pigpio" daemon running on a remote device (ostensibly a Raspberry Pi).

The pigpio daemon is supported extremely well on the Pi, even making an appearance in raspi-config as can here seen here

My thoughts here were that you could write _and run_ System.Device.Gpio code on a PC (controlling a remote GPIO header) without having to jump through the build/deploy/copy/permission loop currently required to run the code on a remote device. This should allow for much quicker iteration.

[ibebbs]

Ok, got a very rough first implementation up and running. Here's the code:

using (var driver = new System.Device.Gpio.Drivers.Pigpio.Driver(new IPEndPoint(IPAddress.Parse("192.168.2.108"), 8888)))
{
    await driver.ConnectAsync();

    // Line above doesn't yet wait for connection so
    // delay here to give the socket time to get connected
    await Task.Delay(TimeSpan.FromSeconds(2));

    using (GpioController controller = new GpioController(PinNumberingScheme.Logical, driver))
    {
        controller.OpenPin(4);
        controller.SetPinMode(4, PinMode.Output);

        var value = 0;
        while (true)
        {
            value = (value + 1) % 2;

            PinValue pinValue = (PinValue)value;

            Console.WriteLine($"Writing PinValue of '{pinValue}' to pin '4'");

            controller.Write(4, pinValue);

            await Task.Delay(TimeSpan.FromSeconds(1));
        }
    }
}

And here's a video of the code running on my PC but controlling the GPIO on a Raspberry Pi Zero running pigpiod:

If there's interest in this being formalised and integrated into System.Devices.Gpio I'll neaten up the implementation and prepare a PR.

[joperezr]

This looks very interesting! I do think this will be very useful. Before you submit a PR though, could we use this issue as an API proposal first in order to finalize into how will the API shape would look like? Once we have that decided, then we will be ready to take in a PR in order to add this to the library.

[krwq]

@joperezr I think this will just implement GpioDriver

[joperezr]

Oh I see, I missed that in the example above, yeah that seems reasonable

[ibebbs]

Hi, yes my implementation so far does indeed implement GpioDriver. It's
actually a very nice fit with almost one-to-one calls between the libraries.

The pigpio library/daemon also has SPI & I2C capabilities. Would be great
to be able to use a similar pattern with the other interface types.

Want me to prep a minimal working example (as shown above) as a PR so you
can see the approach I am taking?

On Tue, 8 Oct 2019, 17:08 Jose Perez Rodriguez, [e-mail]
wrote:

Oh I see, I missed that in the example above, yeah that seems reasonable

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/dotnet/iot/issues/771?email_source=notifications&email_token=AALI4RIAUHVWWAZM2CCEYWLQNSWAFA5CNFSM4I55JZLKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEAUW7MI#issuecomment-539586481,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AALI4RPYVX4A24VJOAD2MP3QNSWAFANCNFSM4I55JZLA
.

[krwq]

Long term I have mixed feelings if this should be a separate nuget package or if it should be included in Iot.Device.Bindings but I think we can put it here for now.

Also we will need to make sure we have a good instructions in the README how to use it since it requires external components.

Yes, please add a sample, for now you can add only GpioDriver and in subsequent PRs you can add SPI/I2C.

cc: @shaggygi I think you've also explored similar subject in the past so this might be interesting addition for you

[shaggygi]

yes, this is very nifty @ibebbs 👍. I did something similar with new gRPC.

[ibebbs]

You know what, I hadn't even thought about putting this in a separate Nuget package (would probably simplify development and deployment TBH). Are there any strong feelings about this? I'm happy to do it either way.

Yes, I'll provide a good ReadMe on the process, although it's documented very thoroughly elsewhere.

[shaggygi]

Since the overall structure for bindings is not thought through completely, I'd recommend going ahead and storing with the other bindings or it might actually be worth storing under tools similar to the DeviceApiTester.

[ibebbs]

This seems odd to me. The pigpiod interface is implemented as a GpioDriver so - IMO - should go in either:

1. The System.Device.Gpio project (where I have currently implemented it)
2. A separate Nuget package.

Doesn't feel like it should be part of the bindings structure as it's not really a binding.

Thoughts?

[joperezr]

I think the best plan would be to have it initially in the Iot.Device.Bindings package, and once we have support for adding tests for this we can move it down to System.Device.Gpio with the rest of the drivers. I would rather not add something to System.Device.Gpio that we don't have a good way of testing for now, since we are still trying to catch up adding coverage for the things that are in there. It wouldn't be the first example of something that should go in the main library and it is currently living on the bindings, since we have the software implementation of PWM and SPI in the bindings package and we will eventually move them down as well.

[krwq]

@ibebbs I think one detail you're missing is that System.Device.Gpio is stuff we officially support where Iot.Device.Bindings has much less support promises (some things might be tested only by contributor). The implication of that is that we don't want to put anything in System.Device.Gpio that we haven't tested ourselves or we're not sure if we want to have there long-term. Putting things to Iot.Device.Bindings gives us more flexibility with any kind of breaking changes we might want to do and gives the APIs a chance to become more stable before we commit to having it long term (people try it out and fix as they hit any issues, over time perhaps some lab setup which allows us to test this scenario etc).

I.e. we have put SoftwareSpi and SoftwarePwm implementation to Iot.Device.Bindings because it wasn't super tested but we know it works correct for some of the devices we have tried it with. Once people start using it more and we don't see any reports of issues we will eventually move it to System.Device.Gpio.

[ibebbs]

@joperezr / @krwq , thanks for the clarification. I understand why you might not want the pigpio driver in the System.Device.Gpio assembly now despite it seeming to be the natural place for it.

Seems to me the best course of action for now (at least until some of the uncertainty is resolved) would be to provide the driver in a separate nuget package. That way there is no responsibility around testing for yourselves and no "bloat" of the core package of functionality that might not be wanted by the majority of users who use the package.

I'll do this for now and provide a link to the package and source repository here once they're ready. Ok?

[joperezr]

Our Iot.Device.Bindings nuget package is already designed for this exact purpose. It doesn't carry the same level of support as our main NuGet Package since for most bindings we haven't really tested against the real hardware, but we already have the packaging and publishing part figured out, plus there are a lot of devs already taking daily builds of that package who might benefit from getting this new driver and might want to contribute to it as well, so instead of you creating that package from scratch, I think everybody might benefit of just adding it directly into our Bindings package. That is my opinion though, ultimately if you want to build a nuget package separately that's fine too 😄

[mguinness]

@ibebbs This is a great idea, but the PR seems to have stalled. I've included the code from the PR into ConsoleApp9.zip so that others can try it out. Thanks to the OP for putting in the time to get the read/write of GPIO pins working.