Clarify board support
See original GitHub issueDescribe the bug
At the moment, it isnt clear from the README what versions of Raspberry PI are supported. The driver files indicate Pi3 and above but it isn’t clear.
It looks like on PI2, it should be able to use libgpiod or sysfs but that isn’t clear.
If that’s indeed the case, then maybe clarify the build process (for ex. right now, I’m compiling on my desktop for linux-arm
. If I have to rely on libgpiod-dev
, then does that mean that cross compiling is ruled out and I have to build on the RPi?
For context: I’m trying to connect to a NRF24L01 on a Rpi2 B+. As of now, my code compiles and seems to be failing silently (no errors, but no pin ops are working)
Expected behavior
- README or Docs clearly list out supported boards.
- Should native libraries be required, then clarify if cross compiling is still an option.
- A sample project would be terrific.
Describe what did you expect to happen
Actual behavior
Unable to find if a Rpi2 is actually supported or not. Linux drivers folder only says Rpi3 and above in code comments.
Detection behavior in GpioController.cs
seems to only checks for BCM2385 in /proc/cpuinfo
which from this page https://www.raspberrypi.org/documentation/hardware/raspberrypi/revision-codes/README.md says that all PIs will report BCM2385
Versions used
Add following information:
dotnet --info
on the machine being used to build
.NET Core SDK (reflecting any global.json):
Version: 3.1.401
Commit: 39d17847db
Runtime Environment:
OS Name: neon
OS Version: 20.04
OS Platform: Linux
RID: linux-x64
Base Path: /usr/share/dotnet/sdk/3.1.401/
-
dotnet --info
on the machine where app is being run (not applicable for self-contained apps) using self-contained apps -
Version of
System.Device.Gpio
packagenuget System.Device.Gpio 1.1.0-prerelease.20276.1 prerelease
Issue Analytics
- State:
- Created 3 years ago
- Comments:6 (4 by maintainers)
Top GitHub Comments
I think what should come out of this issue is some kind of doc explaining on what’s supported and that’s not a simple answer of “we support it” or “not supported”.
But to give some answer here. There are couple of levels of what’s supported and what’s not: Iot.Device.Bindings to the most part (with exception of few bindings) is not depending on any OS or board. As long as you pass in I2cDevice/SpiDevice/GpioController/PwmChannel the device should just work. I.e. if you use Ft4222 almost whole Iot.Device.Bindings will work on any Linux/Windows/OSX (minus PWM channel which you can get by connecting a specific I2C device which exposes PwmChannels so technically you can get anything to work with that one dongle)
There are two pieces of System.Device.Gpio which are unfortunately put in one place (see: https://github.com/dotnet/iot/issues/1182):
Now let’s expand on the implementations in System.Device.Gpio or GPIO specifically (I2C/SPI are relatively painless):
By default you will get auto-detection logic which will pick the best driver implementation for your board - the problem is this logic hard to get right so we’ve had many issues with that and still have some and the most reliable way is to actually use driver directly (but then you might be limited to building for a specific board)
The problem I mention above is not directly a HW issue, but one about how the SPI driver is being used. But since switching to a PI4 works fine, this looks really more like a problem of the implementation. I don’t know why the SPI access should be different between an PI2 and a PI4. Maybe this requires a different driver usage or something.