RPi4B pigpio-GPIO gpioInitialise fails. Why?

Targets Raspberry Pi
1

Hi,
The pigpio-GPIO official code below fails at
System.DebugLog “pigpio initialisation failed. Did you start the pigpio daemon? E.g. sudo pigpiod”
Please help.

RPi 4B.
pigpio is of 24 june 2020
‘Everything else’ is also of latest version.
Yes, i ran sudo pigpiod.

Tried the Debugger as well as directly with the following result:
2020-08-15 11:26:55 initCheckPermitted:
±--------------------------------------------------------+
|Sorry, you don’t have permission to run this program. |
|Try running as root, e.g. precede the command with sudo. |
±--------------------------------------------------------+
(twice, once per gpioInitialise() )

Permissions set liberal.

A minimal Desktop project with the code:
Window1.Open:
pi = New pigpio
Call pi.gpioInitialise()

and pigpio gpioInitialise is as downloaded:
#If TargetARM And TargetLinux Then
soft Declare Function gpioInitialise Lib “pigpio.so” () as Integer
Var RetVal as Integer
Var s as shell
s = New Shell
s.Execute(“sudo killall pigpiod”)
RetVal = gpioInitialise()
If (RetVal = PI_INIT_FAILED) Then
// pigpio initialisation failed.
//Kill all pigpiod and try to reinitialize
s = New Shell
s.Execute(“sudo killall pigpiod”)
RetVal = gpioInitialise()
If (RetVal < 0) Then
System.DebugLog “pigpio initialisation failed. Did you start the pigpio daemon? E.g. sudo pigpiod”
Else
System.DebugLog “pigpio initialised okay”
End If
Else
// pigpio initialised okay.
System.DebugLog "pigpio initialised okay. Version: " + RetVal.ToString
End If
Return RetVal
#Endif

2 
sudo killall pigpiod

Then restart your application. On closing you app you should cleanup, call terminate? Not sure of the method name.

If you close a xojo application by CTRL+C on the terminal it’s killed not closed so your app can’t do cleanup then.

Note you MUST be root or be in the correct group “gpio” depends on you linux setup.

1 Like
3

As Derk mentioned, use the sudo killall pigpiod command and it usually works.

Another thing to try is a good old-fashioned reboot of the Raspberry Pi.

The reason for the problem is that pigpiod will only run one program at once, which makes sense as problems can happen when two different programs are trying to control the same GPIO pin on the Raspberry Pi.

Also, as Derk mentioned, gpioTerminate() can be called. This command is automatically called in the destructor of the pigpio Xojo Class.

4

Maybe check to see if libunwind8 is installed. The following command will install the library or see if it is already installed:

sudo apt-get install libunwind8

5

The trick was to run as root (or a suitable group). My various attempts with sudo was apparently not enough.
Thanks Derk and Eugene.
/Lennart

1 Like
6

I’m not familiar with pigpiod but your statement “pigpiod will only run one program at once” is troubling. The bank of GPIO pins on the Raspberry Pi shouldn’t be treated as the property of a single program. It should be considered a shared resource. If a program needs to control one or more GPIO pins that shouldn’t preclude other programs from accessing the unused GPIO pins.

I can also envision a scenario where one or more programs might want to control the same GPIO pin as a semaphore to signal the other program(s) of an event or state change (similar to using shared memory).

I hope I’m misunderstanding your statement.

7

It looks like I didn’t answer your question properly. Here is a picture that will help me explain it a little more.

https://www.mediafire.com/convkey/7015/2fbfn4cdrhsdtyz6g.jpg

Pigpio sends and receives data from the GPIO pin, and multiple programs could work with a simple LED program, and having more complicated data being sent and received often requires a known data speed, such as I2C. Having multiple microcontrollers attempting to access the same GPIO pins can cause circuits to short (chuckle, and I have had this happen to me).

Industrial electronics divide up these into different sections, the GPIO-Microcontroller, Data calculations, and then the data is sent to another device, such as a screen, to the internet to another computer, or saved in a database.

Xojo and the Raspberry Pi can perform all of these tasks at once, which can cause timing issues with the GPIO, data calculations, and communication. For hobby programming all three (microcontroller, data calculations, and GUI screen data) tasks can be performed on the same Raspberry Pi. Locking the GPIO pins to one microcontroller is really important and prevents data loss and short-circuits.

The way to have many computers control the same GPIO pin would be to have a single Xojo program that controls the GPIO pins and then sends/receives data to other computer(s). These other computers might be in another country and can send data back to the one Raspberry Pi that is controlling the GPIO pins to change something, such as data speed, calibration curves, self-check circuits, and other possible things.

It is a best-practice to have one program control the GPIO pins and then have the program share the data with other programs/computers.

Are there exceptions to the rule? Yes, of course. Most systems that run for years at a time follow this scenario. For short hobby projects, the GPIO pins can be shared, but there is a chance that something will go wrong - such as accidentally changing an output pin to an input pin and shorting out the microchip on the Raspberry Pi. Chuckle, I made this mistake :slight_smile:

8

I think we are talking past one another.

I understand that having more than one external device talking to a single GPIO pin can be problematic.

But I was referring to multiple programs running on the Raspberry Pi that each need to use some of the GPIO pins (possibly the same pins or possibly different pins.) The need for a middle layer to arbitrate access to the GPIO pins seems unnecessary. WiringPi didn’t impose such restrictions and it was quite adequate for most purposes.

Again, I may be misunderstanding the benefit of pigpio. Although I’m also not convinced that access to the GPIO system needs to be conducted through a Xojo class rather than a module. What is the need to wrap the code in a class?

9

Hi Wes,

This is the reason why I made it a Xojo class instead of a module.

If you would like, you can create a version of pigpio in a module by copying and pasting all of the methods from the class into a module.

Just for my curiosity (thats all it is), what benefit could you see pigpio as a module? I am always interested in learning new perspectives.

10

@Eugene_Dakin is probably talking about:

pigpiod is the master process, all sub processes (using the pigpiod library) should not be able to access the same gpio pins/ports. This is the same for SerialConnection, i2c gpio etc.

When the process doesn’t call .Terminate() for pigpio it will simply not release the usage of these pins/ports.

1 Like
11

I spent some time last night reading up on pigpio and pigpiod. The pigpiod daemon does offer some interesting capabilities such as remote GPIO control. The pigpio portion seems to be similar to the Wiring-Pi library.

So, it appears (from my current understanding) that you can discard the pigpiod daemon if you want to have unfettered access to individual GPIO pins. But if you want or need exclusive control of one or more GPIO pins, the pigpiod daemon will provide that to you (assuming that other processes also agree to use the pigpiod daemon and not the pigpio library directly. Which isn’t guaranteed).

I’m still of the opinion that a daemon governing access to GPIO is an additional layer of complexity that isn’t needed 99% of the time. A Raspberry Pi is usually deployed by a single individual who knows what processes are running and what their individual GPIO needs are. This could change in a multi-user environment where individual users may lay claim to the same GPIO resource but that isn’t typically a scenario that will occur when deploying a Raspberry Pi.

1 Like