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
Linx is going to do some initialization when it's started.
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
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.
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.
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