Hello!
I’ve been trying to get an EC11 rotary encoder to work with a PCB that I designed which runs an RP2040. I was using micropython initially since I wasn’t that experienced with arm programming and it just seemed like the easiest route to get up and running asap, but after a few months I noticed a serious performance bottleneck and so set out into the world of the PicoSDK (I landed on the Earle Philhower core, but I miss micropy ).
I’ve been trying to add a feature where a user can set the duration for a 24v motor to run through a basic GUI on an OLED and a rotary encoder. Once said duration is reached, a GPIO pin from the RP2040 pulls the control pin of a boost converter IC low to disable power output. My issue is that I can’t for the life of me get the board to read the state of a rotary encoder. I’ve tried a handful of libraries and examples from here but nothing seems to return any life at all outside of the encoder button being pressed.
Was wondering if anyone had any pointers or ideas?
Sorry this isn’t about a specific product, I wanted to ask since I’ve seen a lot of Pi and encoder guides from here
Hi Finn
There is quite an array of solutions for decoding.
You will have to consider switch bounce. I did some experiments along these lines using a simple Arduino sketch which you would have to adapt to RPi (Python ???)
Results here
Hi Mark
Not familiar with MicroPython but that looks interesting. Your encoder being optical has not got the switch bounce problem I was addressing in the 2 links above. you also probably also have a Schmidt trigger output which would ensure a fast clean unambiguous pulse stream
The EC11 series however is mechanical switch which does have the debounce problem which I attempted to address above both without and with RC filters on the switch outputs. Using filters was OK but I personally would like to clean the output up by using a Schmidt trigger. You might find a read of these posts interesting along with the CRO screenshots.
A lot of this filtering has been done by using delays here and there in the processing system Personally I prefer the hardware approach which enables a system to be broken up into bits like:
Encoder output completely debounced-----driving------Processing-----applied to------end use.
I think then everything can be considered a different entity which can take a lot of the load off problem solving during development.
Diversing from rotary encoders with their single throw switches, if it is only a single button push or single throw switch operation to be debounced a nicer way would be to upgrade the switches to double throw types and use the 2 NAND gate latch system which is pretty fool proof.
Cheers Bob
).
