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
        gpioSetMode(THERMO_BUTTON_PIN, PI_INPUT);
        gpioSetMode(AUDIO_BUTTON_PIN, PI_INPUT);
        if(gpioRead(THERMO_BUTTON_PIN) == HIGH){
            printf("Thermo-HAT registered. Starting thermo-branch.\n");
        if(gpioRead(AUDIO_BUTTON_PIN) == HIGH){
            printf("Audio-HAT registered. Starting audio-branch.\n");
        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.

  • 1
    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
    Commented Jun 16, 2021 at 9: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. Commented Jun 16, 2021 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
    Commented Jun 16, 2021 at 14:43

1 Answer 1


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?

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.