Hobbyist Toolkit

Showing results for 
Search instead for 
Did you mean: 

Digital Input on Raspberry Pi

Go to solution

Shell command now works OK natively on the RPi terminal but I might not try SSH trick and system exec command for LabVIEW (yet) as I no longer have a need for this given I now rely on the default pullup/pulldown settings, BUT I do note that when using the raspi-gpio command and SETting up any GPIO pin as input and programming the pullup or pulldown resistor, I confirm level as expected with raspi-gpio, yet when I then try to read the same level back via LabVIEW , it does NOT read back the correct level.   It is possibly because I am freshly opening a ref to the RPi, and LabVIEW resets the pin config back to default per the following snippet

DI on RPi.png

0 Kudos
Message 11 of 17

Linx is going to do some initialization when it's started.

~ The wizard formerly known as DerrickB ~
Gradatim Ferociter
0 Kudos
Message 12 of 17

OK yes I thought so.  So referring to the snippet above, I paused execution with a breakpoint after Open.vi, I then directly typed the following into the RPi's shell terminal 


pi@raspberrypi:~ $ raspi-gpio set 7 ip pu
pi@raspberrypi:~ $ raspi-gpio get 7
GPIO 7: level=1 fsel=0 func=INPUT


to set a pullup and confim level=1.  I then continued the vi's execution to run the digital read.vi but it still returned level=0 instead of 1 🤔


My fall back option if I decide I need this functionality will be to try out setting the pullup/down states at bootup via the config_txt file per here



0 Kudos
Message 13 of 17

Unfortunately there are several different ways to handle GPIO on Linux. The original way as was recommended/working around 2013 (when the Linx Toolkit was developed) was eventually depreciated by the Linux folks and replaced by a different one that provided more control over the various features such as open collector, pullup resistors and direction control of GPIO pins, including better support for frequency generation directly inside the kernel module, to achieve a better latency and accuracy.


The Linx Toolkit still uses the old variant that simply does not provide all the control that you would like to have. Additional complication here is that the Linx Toolkit environment to deploy VIs to Raspberry Pi and Beaglebone Black executes not directly inside the host OS but in a chroot jail with its own NI Linux RT based kernel (with RT capabilities disabled). That means that not everything a kernel driver tries to do can be really done inside this chroot environment. Every resource needs to be specifically enabled in a configuration file during initialization of the chroot, to be even visible to any software running in the chroot, and some things simply can't be enabled, as direct hardware access is pretty much impossible.

Rolf Kalbermatter
DEMO, TU Delft
My Blog
0 Kudos
Message 14 of 17

Thanks Rolf.    If NI are serious about continuing support for RPi then they will look at making it compatible with RPi Zero and RPi 5 that just came out, and hopeuflly that will cause them to shift to the latest  methods "to handle GPIO on Linux."


Do you think if I employed the "Chtoot SSH Trick " to perform a sys exec call to the raspi-gpio command , would there be any chance of it working ? (e.g. so I can toggle pull-up/down resistors etc.

0 Kudos
Message 15 of 17

Hi Peter,

raspi-gpio uses the GPIO number for a channel.  LINX uses the connector pin number for a channel.


LINX channel 7 is GPIO 4.

(See https://pinout.xyz/ for more information)


 I was able to set the pull up with 

raspi-gpio set 20 pu


and then run a VI reading channel 38


The digital I/O channels for LINX on the Raspberry PI are

7, 11, 12, 13, 15, 16, 18, 22, 29, 31, 32, 33, 35, 36, 37, 38, 40




Message 16 of 17

Nice, thank you for pointing out my problem and testing a solution Andy !

0 Kudos
Message 17 of 17