Raspberry Pi Pico inputs floating

[clickonben]

I am working my way through the Get Started With Micropython on Raspberry Pi Pico book and I am currently on the section dealing with inputs. It says that each of the GPIO pins has a resistor that by default is in pull-down mode. However, when I run the below code with nothing connected to any pins, it flips between printing 1 and 0, suggesting that the input is floating. It does not seem to matter which pin I try they all appear to be floating.

Code: Select all

import machine
button = machine.Pin(0, machine.Pin.IN)
while True:
    print(button.value())

Does anyone know what I am missing? Do I need to enable the pull-down resistors somehow?

[hippy]

From Page 13 of the "Pico Python SDK" -

p2 = Pin(2, Pin.IN, Pin.PULL_UP)

There's also a Pin.PULL_DOWN constant as well.

There is no Pin.PULL_NONE so I'm not sure if there's a default and/or permanent pull which can't be disabled. Couldn't find any info on that when skimming through the datasheets.

My pins don't seem to float; consistently read 0 with no pull specified or Pin.PULL_DOWN, 1 when Pin.PULL_UP.

Are you sitting under a florescent light or other EMI source ?

[clickonben]

Thanks, that works.

The official getting started book published by Raspberry Pi Press says that the default is pull down and the code examples are all of the form:

Code: Select all

Pin(2, Pin.IN)

Which simply omits the parameter to specify whether it is pull down or pull up. The net result is that it seems to float so I think the book must be wrong.

[artag]

I understood the manual to say that the processor resets with all pulldowns active. However, when the code related to pin configuration runs, it will set a new state on the pin. The pin mode is the list of all the things you want to do to it, so if you don't set pull up or pull down then it changes to floating.at that time.

This is also the answer to the question of PULL_NONE : it's just the absence of the other things. If you want to make it explicit, define it to zero.

To put it another way, the values you put into pin mode REPLACE rather than supplement the previous values.

You might think this is silly as the pulldown is irrelevant if it isn't a default in the code. But it's important if you're connecting hardware - it tells you what the pin will do in the time between power coming on and your code running. It's not very long but if it turns on the laser in your engraver for a moment every time you power the system up, it's important.

I would hope that the micro also pulls down the pins while reset is being asserted, not just when it's released. Otherwise it's still necessary to fit an external pulldown resistor in order to be sure it's safe for that period, too. Most devices tend to float their outputs at power up.

[Hashdef]

I too found that the default behaviour does not seem to be as described in "Get Started With Micropython on Raspberry Pi Pico" book. When continuously reading an input pin the value randomly fluctuated between 1 and 0. It was fixed by explicitly specifying PULL_DOWN.

Code: Select all

button = machine.Pin(16, machine.Pin.IN, machine.Pin.PULL_DOWN)

[Superkris]

I think i have the same problem. As i have no experience with Phyton i thought i'd just buy the book and work trough it for a basic understanding of how to program with MicroPhyton. I guess its a book that's mostly for children so it does make me feel a little bit stupid but i guess its fine to learn the basics.

So once you get to page 54 they explain that when you use the argument "machine.Pin.In" it defaults to a input with a pull down resistor. I got very random readings and feared i might have damaged the input with 5V logic. Other pins gave the same problem, and replacing the switch didnt either. Adding a pulldown however fixed it.

Luckily i have some Arduino experience so i understood what was happening. I was also lucky enough to find this topic because a quick google search did not help me in finding the right arguments. Hashdef's code works fine. Thank you dude!

I'm wondering what caused this. Obviously there was some time between the writing of the book, and the first Pico to be sold. Maybe the machine library changed, or something else was changed in code. In the book however its stated that for all experiments its not needed to activate a pull down resistor, and this seems to be very wrong!

[jamesh]

I think i have the same problem. As i have no experience with Phyton i thought i'd just buy the book and work trough it for a basic understanding of how to program with MicroPhyton. I guess its a book that's mostly for children so it does make me feel a little bit stupid but i guess its fine to learn the basics.

So once you get to page 54 they explain that when you use the argument "machine.Pin.In" it defaults to a input with a pull down resistor. I got very random readings and feared i might have damaged the input with 5V logic. Other pins gave the same problem, and replacing the switch didnt either. Adding a pulldown however fixed it.

Luckily i have some Arduino experience so i understood what was happening. I was also lucky enough to find this topic because a quick google search did not help me in finding the right arguments. Hashdef's code works fine. Thank you dude!

I'm wondering what caused this. Obviously there was some time between the writing of the book, and the first Pico to be sold. Maybe the machine library changed, or something else was changed in code. In the book however its stated that for all experiments its not needed to activate a pull down resistor, and this seems to be very wrong!

I'm not sure how the mistake crept in, just one of those things that occasionally escape. Considering we have produced over 1000 pages of docs and this book, there's bound to be a few teething issues. And you are right, the book had to go to printing well before the actual release, and lots of stuff was changing right up to that point.

[Superkris]

I think i have the same problem. As i have no experience with Phyton i thought i'd just buy the book and work trough it for a basic understanding of how to program with MicroPhyton. I guess its a book that's mostly for children so it does make me feel a little bit stupid but i guess its fine to learn the basics.

So once you get to page 54 they explain that when you use the argument "machine.Pin.In" it defaults to a input with a pull down resistor. I got very random readings and feared i might have damaged the input with 5V logic. Other pins gave the same problem, and replacing the switch didnt either. Adding a pulldown however fixed it.

Luckily i have some Arduino experience so i understood what was happening. I was also lucky enough to find this topic because a quick google search did not help me in finding the right arguments. Hashdef's code works fine. Thank you dude!

I'm wondering what caused this. Obviously there was some time between the writing of the book, and the first Pico to be sold. Maybe the machine library changed, or something else was changed in code. In the book however its stated that for all experiments its not needed to activate a pull down resistor, and this seems to be very wrong!

I'm not sure how the mistake crept in, just one of those things that occasionally escape. Considering we have produced over 1000 pages of docs and this book, there's bound to be a few teething issues. And you are right, the book had to go to printing well before the actual release, and lots of stuff was changing right up to that point.

Many thanks for your reply. Does this mean you confirm that by design the pins are floating when only "Pin.IN" is used?
Either that needs to be fixed in the book, or there is a error in the library's im using.

[jamesh]

The book will be updated for its next printing I believe. I guess the PDF will be changed more quickly.

[Superkris]

The book will be updated for its next printing I believe. I guess the PDF will be changed more quickly.

Thanks again for you reply. I really love the concept of the RP2040 and microphyton. I really hope the community for this microcontroller grows to similar size as the Atmel Arduino's. At this point its still hard to make a fair comparison, but i think the potential is huge!

[SilentRhetoric]

Thanks, that works.

The official getting started book published by Raspberry Pi Press says that the default is pull down and the code examples are all of the form:

Code: Select all

Pin(2, Pin.IN)

Which simply omits the parameter to specify whether it is pull down or pull up. The net result is that it seems to float so I think the book must be wrong.

I just started working through the book today and found other examples, too. In the traffic light with pedestrian button example, the given code will throw a NameError because “button” isn’t defined as a global variable inside and outside of the function used by the _thread. Had I not some experience with Python and help from the Python Discord (no response in the Raspberry Pie Discord, sadly), I would have been stuck.

I had a great time with the original Raspberry Pi book, but this Pico book has been more frustration than fun, so far.

[jamesh]

Thanks, that works.

The official getting started book published by Raspberry Pi Press says that the default is pull down and the code examples are all of the form:

Code: Select all

Pin(2, Pin.IN)

Which simply omits the parameter to specify whether it is pull down or pull up. The net result is that it seems to float so I think the book must be wrong.

I just started working through the book today and found other examples, too. In the traffic light with pedestrian button example, the given code will throw a NameError because “button” isn’t defined as a global variable inside and outside of the function used by the _thread. Had I not some experience with Python and help from the Python Discord (no response in the Raspberry Pie Discord, sadly), I would have been stuck.

I had a great time with the original Raspberry Pi book, but this Pico book has been more frustration than fun, so far.

Can you post any issue you find with the book in the github pico-feedback issue tracker please. We'll get them fixed as soon as possible.

https://github.com/raspberrypi/pico-feedback/issues

Might be worth checking to see if it already been reported first.

[philkingmagpi]

In the traffic light with pedestrian button example, the given code will throw a NameError because “button” isn’t defined as a global variable inside and outside of the function used by the _thread.

Sorry about this. We have since found that adding a small delay to the function's while loop will prevent this intermittent error appearing:

Code: Select all

def button_reader_thread():
    global button_pressed
    while True:
        if button.value() == 1:
            button_pressed = True
        utime.sleep(0.01)
_thread.start_new_thread(button_reader_thread, ())

[scruss]

There is no Pin.PULL_NONE so I'm not sure if there's a default and/or permanent pull which can't be disabled. Couldn't find any info on that when skimming through the datasheets.

There is; since the Python SDK document is a potted summary of available commands, you have to go to the MicroPython docs for machine.Pin()

pull specifies if the pin has a (weak) pull resistor attached, and can be one of:

None - No pull up or down resistor.

Pin.PULL_UP - Pull up resistor enabled.

Pin.PULL_DOWN - Pull down resistor enabled.

So pull=None should do it, in the rare occasions you'd want it.

Explicitly setting pull=Pin.PULL_UP|Pin.PULL_DOWN is probably a good idea to avoid the floaties.

[Superkris]

The book will be updated for its next printing I believe. I guess the PDF will be changed more quickly.

Today i received a mail from the store that you/they will be providing new books free of charge.

Thank you very much for this great support. Keep up the good work!

[jamesh]

The book will be updated for its next printing I believe. I guess the PDF will be changed more quickly.

Today i received a mail from the store that you/they will be providing new books free of charge.

Thank you very much for this great support. Keep up the good work!

Excellent news!

[DirkS]

The book will be updated for its next printing I believe. I guess the PDF will be changed more quickly.

Today i received a mail from the store that you/they will be providing new books free of charge.

To add to that: the PDF version as available through the Pi Bookshelf (and manual download) has had a couple of updates over the last week or so. Don't know exactly what changed though.