iot: Error while trying to initialize pin interrupts.
I am using the GpioController on a Raspberry Pi 3B+ with an interrupt routine. The code is relatively simple, I initialize the GpioController on program start and register an interrupt for a single pin for a rising event:
_pinController = new GpioController(PinNumberingScheme.Logical); _pinController.OpenPin(Settings.TransferReadyPin); _pinController.SetPinMode(Settings.TransferReadyPin, PinMode.InputPullDown); _pinController.RegisterCallbackForPinValueChangedEvent(Settings.TransferReadyPin, PinEventTypes.Rising, OnTransferReady); if (_pinController.Read(Settings.TransferReadyPin) == PinValue.High) { _transferReadyEvent.Set(); }
…
private static void OnTransferReady(object sender, PinValueChangedEventArgs pinValueChangedEventArgs) { _transferReadyEvent.Set(); }
After a while my program crashes randomly with this stack trace:
Unhandled Exception: System.IO.IOException: Error while trying to initialize pin interrupts. at System.Device.Gpio.Drivers.SysFsDriver.WasEventDetected(Int32 pollFileDescriptor, Int32 valueFileDescriptor, Int32& pinNumber, CancellationToken cancellationToken) at System.Device.Gpio.Drivers.SysFsDriver.DetectEvents() at System.Threading.Thread.ThreadMain_ThreadStart() at System.Threading.ThreadHelper.ThreadStart_Context(Object state) at System.Threading.ExecutionContext.RunInternal(ExecutionContext executionContext, ContextCallback callback, Object state) --- End of stack trace from previous location where exception was thrown --- at System.Threading.ExecutionContext.RunInternal(ExecutionContext executionContext, ContextCallback callback, Object state) at System.Threading.ThreadHelper.ThreadStart()
I am using System.Device.Gpio 0.1.0-prerelease.19176.1 and IoT.Device.Bindings 0.1.0-prerelease.19176.1 on a recent Raspbian installation. Any idea why this problem occurs?
About this issue
- Original URL
- State: closed
- Created 5 years ago
- Comments: 34 (19 by maintainers)
Yes, I hope I can move over to your library again when .NET Core 3 is out 😃
Have a look at this crate, its license seems to be fully compatible with the MIT license: https://docs.rs/crate/gpiochip/0.1.1/source/src/lib.rs Essentially, the gpiochip dev node seems to be controllable entirely via ioctl calls so it would be nice if you came up with a new GPIO controller implementation.
Just be aware that pins allocated via SysFS cannot be controlled via the gpiochip<n> dev node (at least not on my RaspPi 3B+).
@joperezr Have a look at https://github.com/chrishamm/DuetSoftwareFramework/blob/master/src/DuetControlServer/SPI/DataTransfer.cs. This program establishes an SPI connection to a Duet 3 (a 3D printer board in development/beta testing) and whenever the Duet 3 is ready to exchange data, a GPIO pin is toggled. This happens several times per second.
Because of the exception from the GpioController I copied most of your UNIX SPI implementation to my own library and implemented my own event-based input GPIO class that works via the Linux GPIO chip device. I licensed this particular class under MIT license so you can adopt it if you like. See https://github.com/Duet3D/DuetSoftwareFramework/blob/master/src/LinuxApi/InputGpioPin.cs and https://github.com/Duet3D/DuetSoftwareFramework/blob/master/src/LinuxApi/Interop/Libc/Interop.ioctl.cs
Hey @chrishamm thanks for reporting this. We actually started seeing this as well in some of our tests so we are currently investigating the issue. Once we have a fix, I’ll update this issue with a package version of System.Device.Gpio that doesn’t have the problem any longer.