Input_pullup behaving differently between WebIDE and DEV

Troubleshooting
1

Hey folks.

I have an issue. I have a program that is using INPUT_PULLUP and it is monitoring a switch to ground. When I flash the code using the WebIDE evening behaves as expected. When I flash the code via the CLI dev environment the digital read flipflops between low and high when the switch is closed. In other words if the switch is closed and the input pin should see ground. It behaves as though it sees high and low. It’s like the pull-up resistor is not connected. If I use a physical resistor pulling the pin up everything works as expected in both environments. The CLI is a fresh install done last week and the firmware on the Photon is 1.1.0

Is there a different version of INPUT_PULLUP for the CLI dev environment I should be using?

Thanks for any help folks.

Cheers.

2

Are you sure you are compiling exactly the same code and targeting the same device OS?
There is no difference in the build environment irrespective of the online-build tool used.

Can you show the code you are building via CLI?

BTW, your topic title mentions DEV but in your post you talk CLI - which is it?
If CLI, what exact command(s) are you using to build and flash?

3

@bhboyle, the CLI uses the same compile server farm as the WebIDE does so there is no difference. How are you compiling with the CLI (the command you type)? Can you post your code?

1 Like
4

I will upload the code when I get back home.

Sorry about the confusion. It is the CLI I am using and the command I am using is.

Particle compile photon.

Executed from within the project folder.

The code was copied and pasted out of the WebIDE so I am sure it is the same code.

Cheers.

5

Sorry for the trouble folks. It has to be a problem with my code. The code is fairly large and so uploading it would have made problem solving troublesome. So I created a new project and tested the basics of this part of the project with the following code and it worked as expected in both the webIDE and the CLI so it has to be a bug in my code.

Thanks for helping me troubleshoot.

#define leftDoorMonitorPin 2  // this is the pin that will determin if the Left door is open or closed
#define leftDoorRelay 0 // Left door relay port
#define leftDoorLED 4  // this is the pin that will drive an LED if the left door is open

void setup() {

    pinMode(leftDoorMonitorPin, INPUT_PULLUP);  // this is the pin that will determine if the left door is open or closed. 
    pinMode(leftDoorLED, OUTPUT);  
    
}

void loop() {
    
    if(digitalRead(leftDoorMonitorPin)) {
        digitalWrite(leftDoorLED, HIGH);
        
    }   else {
        digitalWrite(leftDoorLED, LOW);
    }

}
2 Likes
6

I know this is just a test code, but your loop() code would be much simpler like this

void loop() {
  digitalWrite(leftDoorLED, digitalRead(leftDoorMonitorPin));
}

the input parameter of digitalWrite() is exactly what digitalRead() hands you as return value :wink:

7

Thank you very much for that. I have used that tactic in the past for other types of indicator displays. In fact in my real code I did use it for something else. In this case however there is other things happening in the if statement so I just did it that way in the test code.

In case anyone happens to come across this in the future looking to solve the same problem, my problem was that in the class I had coded for the door I am trying to monitor instead of using pinMode to set the mode of the monitor pin to INPUT_PULLUP, I accidently used digitalWrite(monitorpin, INPUT_PULLUP). This to my suprise compiled fine and not suprisingly does not behave as expected.

To your point ScruffR, so much for being sure I was compiling exactly the same code. Clearly I was wrong again. I sure felt like a dolt when I found the digitalWrite instead of pinMode in the class setup.

Thanks for your help and I hope this helps someone else in the future.

Cheers.

1 Like
8

No real surprise there as these pin mode "macros" are just fancy names for integer values and since you can pass any integer as desired state - anything non-zero will be taken as HIGH (which in turn is also just an integer value).

1 Like