Encoder not working on Pico 2W

[tgnorman]

Hi,
I have a rotary encoder that was working just fine on a Pico 1 W, using Peter Hinch's asyncio encoder. I was forced to migrate to Pico 2 as I needed more memory, but the same code does not trigger any interupts on the Pico 2. I am using Micropython v1.25.0-preview.380.g226434055.

Encoder driver form https://github.com/peterhinch/micropython-samples/blob/master/encoders/ENCODERS.md
I am using encoder.py... not encoder_rp2.py, which to be honest, I didn't find until today. encoder_rp2.py generates interupts, but the values generated are"interesting"... encoder.py does not do anything on Pico 2.

Hardware is fine.. works with my simple IRQ that just compares encoder Pin values, but Peter's code is rather more elegant ;-)
However, the reason for reporting the issue here is that there seems to be something broken in v1.25 ... at least, running on a Pico 2.

[peterhinch]

There is a problem with RP2350 pins when used as inputs - see this issue. I'm not sure if this is relevant to the basic encoder script, but it will almost certainly affect the RP2 version which uses the PIO.

In my view the machine.Pin class is not yet fully functional on RP2350.

[tgnorman]

Thanks Peter (for your reply, but also generally for providing a fantastic repo!)

Testing the encoder_rp2.py, using PIO gives odd results on my RP2350. Values increment inconsistent amounts on each click of the rotary...

My chief concern was that encoder.py - not using PIO, but some fancy asyncio code - just does not work at all on the RP2350. Nada. Zip. Maybe it is another symptom of what you describe. I make fairly heavy use of GPIO pin inputs in my project, so this is a real concern for my pump control project, the more so as my code exceeds the limits of the RP2040, so I am stuck with RP2350.

I'll just have to work around things until the machine.Pin class stabilises. Good to know folk such as yourself are aware of the issue... that was my reason for posting ;-)

Cheers,

[peterhinch]

Re PIO solutions you might like to try the workround here. As written it fixes GPIO numbers 0 and 1, but check the RP2350 manual for the means of adapting to other pins. In my testing PIO input was utterly broken without that code.

There is another possible issue in that the signals from mechanical encoders aren't particularly clean logic signals. I use 1KΩ pullups to try to get reasonably fast transitions. It is possible that the revised hardware/firmware is particularly intolerant of these signals. To put this into context, the portable driver has been used on a wide range of platforms (STM32, ESP32, ESP8266, RP2040, and probably others) without problems.

As a general point, given that you're using asyncio, please read this section of my doc to check if this issue needs to be addressed in your design.

[tgnorman]

I will try the 1KΩ pullups tomorrow... it's 2 AM where I am (Australia). I have looked at the pins on my DSO.. and yes, they are pretty dirty.

I did read (or tried to, anyway!) the section in your asyncio repo when I first obtained my rotary, it was all a bit confusing at the time, as I was pretty new to microcontrollers & Python, not to mention asyncio. Steep learning curve! I got your encoder.py and related test sript running on my Pico 1, and moved on... until it all broke on my Pico2W. I have not yet tried the portable driver version either... again, might play with that tomorrow.

I have also D/L'd the latest nightly build of 1.25... will flash that tomorrow also, and do some more testing.

As a relative newbie, the PIO code is a bit challenging! Not that I need to hack it... I'm more than happy to leave that to you!

Thankyou again for you interest and help...

[tgnorman]

OK... I have some results, the final one is the kicker, I suspect:

1. External 1KΩ pullups made no difference
2. Portable driver... same. Works on Pico 1, fails totally on Pico 2
3. Latest preview build... RPI_PICO2_W-20250327-v1.25.0-preview.428.g50da085d9.uf2 - same result. (My Pico 1 is running v1.23.0)
4. The PIO driver version... sort of works, but not very satisfactory. Position values returned are inconsistent
5. OK... lets look at signals on the pins. Note: I have NOTHING else connected... a bare-bones Pico 1/2, and a rotary encoder on pins 18 and 19. The interesting thing is... there is a marked difference in voltage differentials on rotating the encoder. Pics attached.

Note: Wiring remained the same ... I just popped one Pico out of the header socket, and dropped the other Pico in, and reran the portable encoder, with Pin.PULL_UP set. Nothing else changed. I see the Pico 1 pins are pulled down (almost) to zero, but the Pico 2 stays well above ground. I presume this difference is why the original Pico detects the rotary movement... and the Pico 2 does not, but I will leave further opinions to wiser heads than mine!

I have no idea if this might impact the PIO driver, or other operations, but worth noting...
Regards,
T.

EDIT: Dang... just repeated my measurement... and of course the Pico 2 is now showing 3.6 V delta. Sorry, my theory just went down the gurgle. No idea what changed. Dodgy Dupont wiring on the breadboard??

[peterhinch]

Assume a mechanical encoder linked to 0v, with 1KΩ pullups to 3V3: if the voltage swing isn't 0-3.3V, something is electrically very wrong.

[peterhinch]

I have now tested encoder_portable.py on a Pico 2 W and it works fine (using 1KΩ pullups). Test script:

from machine import Pin
from encoder_portable import Encoder
from time import sleep
px = Pin(0, Pin.IN)
py = Pin(1, Pin.IN)
e = Encoder(px, py)
while True:
    print(e.position())
    sleep(1)

I haven't yet tested the PIO version, but I would expect it to be problematic without the fix I identified above.

[tgnorman]

Thanks Peter.
It’s now 4:30 AM my time… I’ll take another look tomorrow!
I had VBUS connected to my breadboard, so pull-ups were to 5V. I was a but sloppy setting up my scope, so absolute voltages were out in my trace pics, but clearly that should have had no impact on the rotary IRQ not being triggered on the Pico 2. Same result seen with internal pull-ups.
I think my encoder has some extra logic on-board… perhaps that is interfering.

TBC tomorrow…

[tgnorman]

Well - part of my odd behaviour is explained by this: with a 1K pullup to VCC on my encoder, the voltage only drops a very small amount:

Little wonder that the IRQ didn't fire!
This encoder has an on-board RC filter (it is apparently a PEC11R encoder underneath), the debounce circuit is as recommended by Bourns.
Anyway... lesson learned... check with a scope! And (for my encoder) NEVER use external pullups.

Unresolved is why, with internal pull-ups only, where I get a decent voltage swing to ground... encoder_portable still does not fire - ever. Running same code Peter posted last night. Ke ??

This, whilst "interesting", has become less relevant for me, as I am migrating away from using an encoder to drive my UI. If it is useful to others I can continue to tinker, but am also happy to end the conversation!

Thanks Peter for your contribution... much appreciated!
Cheers,
T.

PS If anyone cares, a member of the forum I use (Bob) has done extensive testing on this encoder... you can find it here: https://forum.core-electronics.com.au/t/encoder-module-with-button-ce09436/16772/15. Unlike me, Bob is a very knowlegable electronics guy...

[peterhinch]

@tgnorman A few points.

1. The Pico series (RP2240, RP2350) are not 5V compliant. Do not apply voltages greater than 3.3V.
2. I don't recommend R-C "debouncing" circuits. These have the effect of slowing the edges; logic circuits are not designed to work with slow edges. If you study the state diagram of my encoder drivers, debouncing is inherent in their logic. They are intended to use the raw data from a mechanical (or other) encoder.
3. I normally wire the common pin to Gnd with X and Y connected to GPIO's with 1KΩ pullups to 3.3V.
4. For accurate detent tracking I recommend the asynchronous driver which has extra logic to cope with the typically sketchy mechanical registration of the detents with the encoder contacts.

[tgnorman]

Hey Peter... I had a detailed follow-up post prepared last night, but I had not sent it when my PC rebooted. I will write it up again - but probably not tonight. Why? Well.. I realised that I messed up, possibly from doing this work at like 2AM in the morning!

Key thing is, I reported that even with internal pull-ups, encoder_portable failed. This was WRONG. Sorry...
It seems the encoder I have with in-built debounce RC really is a significant part of the problems I am seeing. That said, there also seems to be some change in behaviour between Pico 1 and Pico 2, I intend to fully (and carefully) document my comparison findings... tomorrow, when I'm awake! And less prone to screw-ups!

I read the RP2350 datasheet, Errata P9... I am not sufficiently qualified to tell if this might be relevant. Nor if it might be relevant to your PIO issue, but I saw Gadgetoid make a reference to this errata in one of his posts on the other thread, so I guess you looked at it already.

Do you know of a way to determine the version of the RP2350 hardware? I saw someone post a query if later fabs might have resolved the issues with Pico 2 GPIO pins... but I can't tell how "new" my silicon is. It is a Pico 2 W... so obviously not a real early fab, ie before the W was added ;-)

PS I also raised the 5V issue with the vendor of my encoder. They specified (incorrectly) that it wanted 5V... and I had noticed the encoder does not work very well at all when I am running my Pico (and several I2C devices) off a LiPo battery, rather than from USB, so I stayed with 5V, but your point is well noted that presenting the 5V from encoder output to a GPIO input pin is likely to cause problems.

More tomorrow
T.

[peterhinch]

My advice is to use encoder_portable with a simple mechanical encoder and (preferably) 1KΩ pullups. Connect the common of the encoder to gnd and the pullups to 3.3V. This will work on any RP2. Then you needn't worry about Pin/PIO problems or chip steppings.

There is no need to use the encoder_rp2 version for a switch - it is intended for use with fast optical or magnetic encoders.

presenting the 5V from encoder output to a GPIO input pin is likely to cause problems.

Or even damage.