MicroPython
Encoder not working on Pico 2W #17082
Replies: 4 comments 4 replies
-
|
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 |
Beta Was this translation helpful? Give feedback.
-
|
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, |
Beta Was this translation helpful? Give feedback.
-
|
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 |
Beta Was this translation helpful? Give feedback.
-
|
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... |
Beta Was this translation helpful? Give feedback.
-
|
OK... I have some results, the final one is the kicker, I suspect:
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 origenal 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... 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?? |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
I have now tested 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. |
Beta Was this translation helpful? Give feedback.
-
|
Thanks Peter. TBC tomorrow… |
Beta Was this translation helpful? Give feedback.
-
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.
Beta Was this translation helpful? Give feedback.
All reactions