pigpio INPUT-mode configures GPIOs to INPUT unreliably

Question

This is a follow-up question to another post of mine which I thought was answered but isn't really:

WiringPi INPUT causes voltage below nominal 3.3v on pin with pull-up

Since then I migrated to pigpio but that doesn't change a strange encounter I'm having:

#include <pigpio.h>
#include <stdio.h>
int main(void){
    //depending on the HAT (different hardware), either GPIO23 or GPIO4 is pulled up and the other left floating
    #define THERMO_BUTTON_PIN 23
    #define AUDIO_BUTTON_PIN  4
    #define HIGH 1
    #define LOW 0
    //based on this, i can auto-detect the attached hardware
    //hardware pull-up is 5kohm

    gpioInitialise();

    gpioSetMode(THERMO_BUTTON_PIN, PI_INPUT);
    gpioSetMode(AUDIO_BUTTON_PIN, PI_INPUT);


    if(gpioRead(THERMO_BUTTON_PIN) == HIGH){
        printf(&quot;Thermo-HAT registered. Starting thermo-branch.\n&quot;);

    }

    if(gpioRead(AUDIO_BUTTON_PIN) == HIGH){
        printf(&quot;Audio-HAT registered. Starting audio-branch.\n&quot;);

    }
    return 0;
}

Executing this sometimes results in the right HAT being selected, but more often it results in both HATs being selected. And I really mean "sometimes". It shows no meaningful pattern. Checking with a MM the pins then show around 2.1 to 2.7 V, as if they were never initialized as INPUT (it's the same after sudo poweroff and measuring again). Measuring the working case results in expected 3.3 and 0V. This tells me that sometimes the pins are not marked as INPUT, yet I can still measure them with gpioRead(). I've read something about a pigpio daemon which should be killed, is that connected to this problem? Is my Pi dying? I've treated it rough many times, not knowing what I was doing.

The shown code runs at the head of my program, so no multi-threading is involved just yet. If you need more code/logs to answer this please ASK because I don't know what to supply, otherwise I wouldn't have to ask this question.

In this post and your other you show incomplete code which no one can duplicate. You also make claims without providing any evidence. Any question about GPIO without connection details just adds another level of ambiguity. — Milliways, Jun 16 '21 at 09:35
edited. However it's going to be hard to supply you with the hardware, but that is not the point. Above is a simple GPIO-input example and I'm asking if there are known problems with this library. The custom hardware works definetly and the measured values are also what appears on my pi. — jake_asks_short_questions, Jun 16 '21 at 10:01
I agree with Milliways. You should ALWAYS provide a working code example. That would allow us to replicate the problem without ambiguity. — joan, Jun 16 '21 at 14:43

score 0 · Answer 1 · answered Jun 16 '21 at 11:50

Attempting to compile this produces the expected string of errors

ttt.c: In function ‘main’:
ttt.c:13:21: error: ‘THERMO_BUTTON_PIN’ undeclared (first use in this function)
         gpioSetMode(THERMO_BUTTON_PIN, PI_INPUT);
                     ^~~~~~~~~~~~~~~~~
ttt.c:13:21: note: each undeclared identifier is reported only once for each function it appears in
ttt.c:14:21: error: ‘AUDIO_BUTTON_PIN’ undeclared (first use in this function)
         gpioSetMode(AUDIO_BUTTON_PIN, PI_INPUT);
                     ^~~~~~~~~~~~~~~~
ttt.c:17:43: error: ‘HIGH’ undeclared (first use in this function)
         if(gpioRead(THERMO_BUTTON_PIN) == HIGH){
                                           ^~~~

If your code won't even compile how do you expect it to do ANYTHING?

pigpio INPUT-mode configures GPIOs to INPUT unreliably

1 Answers1