Problems with PIO implementation of quadrature encoder

[JeffreyUitbeijerse]

Hi all,

For my graduation assignment I need to build a test setup which contains 6 quadrature encoders. I want to use the TI LAUNCHXL-F28379D to run a control algorithm, but this board can only read up to 3 quadrature encoders. Therefore my proposed solution was to read the 6 encoders using the state machines on the Raspberry Pi Pico, and send the counts to the F28379D through SPI.

I am new to the Raspberry Pi Pico, MicroPython and state machines, but using several examples online I managed to write my own program, which reads a quadrature encoder using the A and B channel, and also resets the counter once the Index channel is high for the first time. At first glance the program seems to do its job perfectly, but upon further inspection I encountered the following problem:

I tested the algorithm using a miniature positioning stage, which contains an encoder (grey), a voice coil motor and some flexures, as shown below:

Using the mechanism, I can oscillate the encoder with a fixed amplitude and frequency. Doing so results in the following encoder readings on the F28379D:

compared to the readings from my algorithm on the Pico:

It seems to me that the algorithm increments the counter faster than it decrements the counter, even though I implemented delay cycles such that each possible action (increment, decrement, no update) takes 12 clock cycles. I added the code down below for reference. Does anybody have an idea of what could be the issue here? Thanks in advance.

import utime
import rp2
import sys
from machine import Pin, SPI

# PIO state machine to decode quadrature encoder signals into counts
@rp2.asm_pio(in_shiftdir=rp2.PIO.SHIFT_LEFT, out_shiftdir=rp2.PIO.SHIFT_RIGHT)
def quadrature():
    # 00 state
    jmp("update")     [3]  # read 00
    jmp("decrement")  [1]  # read 01
    jmp("increment")  [0]  # read 10
    jmp("update")     [3]  # read 11

    # 01 state
    jmp("increment")  [0]  # read 00
    jmp("update")     [3]  # read 01
    jmp("update")     [3]  # read 10
    jmp("decrement")  [1]  # read 11

    # 10 state
    jmp("decrement")  [1]  # read 00
    jmp("update")     [3]  # read 01
    jmp("update")     [3]  # read 10
    jmp("increment")  [0]  # read 11

    # 11 state
    jmp("update")     [3]  # read 00
    jmp("increment")  [0]  # read 01
    jmp("decrement")  [1]  # read 10
    jmp("update")     [3]  # read 11
    
    # main loop starts
    wrap_target()
    label("update")
    
    # copy the current count into the input shift register (ISR) and push
    # it into the RX FIFO as a single 32-bit message without blocking
    mov(isr, y)
    push(noblock)

    # check the index flag
    label("check_indexflag")
    jmp(not_x, "extra_cycle")

    # check the index pulse
    label("check_index")
    jmp(pin, "reset_counter")

    # shift into isr the last state of the 2 input pins (now in osr) and
    # the new state of the 2 pins, thus producing the 4-bit target for the
    # computed jump into the correct action for this state
    label("sample_pins")
    out(isr, 2)
    in_(pins, 2)
    
    # save the state in the osr, so that we can use isr for other purposes
    mov(osr, isr)

    # jump to the correct state machine action
    mov(pc, isr)

    # reset the counter y and set the index flag x to 0
    label("reset_counter")
    set(y, 0) [7]
    jmp(x_dec, "update")

    # synchronize the amount of cycles in each sample loop
    label("extra_cycle")
    jmp("sample_pins")

    # decrement the counter y and continue at the update label
    label("decrement")
    jmp(y_dec, "decrement_cont")
    
    label("decrement_cont")
    jmp("update")
    
    # the pio does not have an increment instruction, so to do that we do a
    # negate, decrement, negate sequence
    label("increment")
    mov(y, invert(y))
    jmp(y_dec, "increment_cont")

    label("increment_cont")
    mov(y, invert(y))
    wrap()

# Pin assignments for encoder 1
pinI1 = Pin(13, Pin.IN, Pin.PULL_DOWN)
pinA1 = Pin(14, Pin.IN, Pin.PULL_DOWN)
pinB1 = Pin(15, Pin.IN, Pin.PULL_DOWN)

# Initialize statemachines
sm0 = rp2.StateMachine(0, quadrature, freq=120000000, in_base=Pin(14), jmp_pin=Pin(13))
sm0.exec("set(x, 1)")
sm0.exec("set(y, 0)")
sm0.active(1)

while True:
    print(sm0.get())
    utime.sleep(0.1)

[mendenm]

Are you carefully filtering the edges from the encoder, so that they have clean transitions, and do you have the inputs in Schmitt-trigger mode?

[robert-hh]

How large is your PIO program? I faintly recall from an analysis sometime ago that programs are loaded into the state machine memory top-down. If your code is smaller than the state machine memory size, the computed jumps may go to a different address than intended. But then the code should fail.

[Josverl]

programs are loaded into the state machine memory top-down

They do indeed load aligned to the top of the available memory in thevstatemachine

[rkompass]

When having a look at my similar program:

# Quadrature encoder for RPi 2040 PIO
#
# Resolution: 4 in-/decrements per cycle.
#
# Original version (c) 2021 pmarques-dev @ github
#   (https://github.com/raspberrypi/pico-examples/blob/master/pio/quadrature_encoder/quadrature_encoder.pio).
# Adapted and modified for micropython 2022 by rkompass.
#
# Quadrature encoding uses a state table in form of a jump table
#   which is fast and has no interrupts.
# This program was reduced to take 'only' 25 of 32 available PIO instructions.
# The jump table has to reside at the beginning of PIO program memory, therefore
#   the instructions are filled up with 7 nop()'s.
# 
# The counter x is permanently pushed nonblockingly to the FIFO.
# Reading the actual value requires emptying the FIFO then waiting for and getting the next pushed value.

# The worst case sampling loop takes 14 cycles, so this program is able to read step
#   rates up to sysclk / 14  (e.g., sysclk 125MHz, max step rate = 8.9 Msteps/sec).
#
# SPDX-License-Identifier: BSD-3-Clause
#
#
# --------------------------------------------------------
#
#  Example of usage:
#  -----------------
# #
# # pinA = Pin(8, Pin.OUT)          #  Pins for generation of the quadrature signal, if you do not want to use switches.
# # pinB = Pin(9, Pin.OUT)          #  Then connect pin 6 with pin 8, and pin 7 with pin 9 on the Raspi Pico.
# # qgen = QGen_Pio((pinA, pinB), 250, freq=60_000)
# 
# pinX = Pin(6, Pin.IN, Pin.PULL_UP)
# pinY = Pin(7, Pin.IN, Pin.PULL_UP)
# qenc = QEnc_Pio_4((pinX, pinY), freq=125_000_000)
# 
# # qgen.start()
# for i in range(200):
#     print('x:', qenc.read())# , qgen.running())
#     sleep_ms(100)
# 
# --------------------------------------------------------


from rp2 import PIO, StateMachine, asm_pio

# -----  Quadrature encoder class, using RPI2040 PIO. Resolution: 4 in-/decrements per cycle  --------

class QEnc_Pio_4:
    def __init__(self, pins, sm_id=0, freq=10_000_000):
        if not isinstance(pins, (tuple, list)) or len(pins) != 2:
            raise ValueError('2 successive pins required')
        pinA = int(str(pins[0]).split(')')[0].split('(')[1].split(',')[0])
        pinB = int(str(pins[1]).split(')')[0].split('(')[1].split(',')[0])
        if abs(pinA-pinB) != 1:
            raise ValueError('2 successive pins required')
        in_base = pins[0] if pinA < pinB else pins[1]
        self.qenc = StateMachine(sm_id, self.sm_qenc, freq=freq, in_base=in_base)
        self.qenc.exec("set(x, 0)")  # instead of sm_qenc.restart()
        self.qenc.exec("in_(pins, 2)")
        self.qenc.active(1)
    
    @asm_pio(in_shiftdir=PIO.SHIFT_LEFT, out_shiftdir=PIO.SHIFT_RIGHT)
    def sm_qenc():         #             AB    AB     !!! *** this logic is wrong, it's BA, the lower pin always is on the right side
        jmp("read")        # 0000 : from 00 to 00 = no change
        jmp("decr")        # 0001 : from 00 to 01 = backward
        jmp("incr")        # 0010 : from 00 to 10 = forward
        jmp("read")        # 0011 : from 00 to 11 = error
        jmp("incr")        # 0100 : from 01 to 00 = forward
        jmp("read")        # 0101 : from 01 to 01 = no change
        jmp("read")        # 0110 : from 01 to 10 = error
        jmp("decr")        # 0111 : from 01 to 11 = backward
        jmp("decr")        # 1000 : from 10 to 00 = backward
        jmp("read")        # 1001 : from 10 to 01 = error
        jmp("read")        # 1010 : from 10 to 10 = no change
        jmp("incr")        # 1011 : from 10 to 11 = forward
        jmp("read")        # 1100 : from 11 to 00 = error
        jmp("incr")        # 1101 : from 11 to 01 = forward
        label("decr")
        jmp(x_dec, "read") # 1110 : from 11 to 10 = backward    !!! we cannot change all incr <-> decr because
        label("read")      # 1111 : from 11 to 11 = no change   !!! this next read has to be here after a decrement
        mov(osr, isr)      # save last pin input in OSR
        mov(isr, x)
        push(noblock)
        out(isr, 2)        # 2 right bits of OSR into ISR, all other 0
        in_(pins, 2)       # combined with current reading of input pins
        mov(pc, isr)       # jump into jump-table at addr 0
        label("incr")      # increment x by inverting, decrementing and inverting
        mov(x, invert(x))
        jmp(x_dec, "here")
        label("here")
        mov(x, invert(x))
        jmp("read")        
        nop()
        nop()
        nop()
        nop()
        nop()
        nop()
        nop()

    def read(self):
        for _ in range(self.qenc.rx_fifo()):
            self.qenc.get()
        n = self.qenc.get()
        return -n if n < (1<<31) else (1<<32)-n  #  !!! *** therefore we change the polarity of counting here

I notice that the saving of the pin input before writing the counter to isr, and restoring it, seems essential:

mov(osr, isr)      # save last pin input in OSR
mov(isr, x)
push(noblock)
out(isr, 2)        # 2 right bits of OSR into ISR, all other 0

Could it be that this is missing in your code? Your code is more complicated than mine in this respect, so I could not exclude that at a first inspection. Feel free to try this one out.

Note the fill-up with nop() until we have 32 instructions. Otherwise the code is placed at the upper free space in instruction memory as Robert stated.

[mendenm]

@JeffreyUitbeijerse Given the extremely uniform slope of the error in the count, I think @rkompass suggestion could be right. It really doesn't look like the erratic behavior that would be caused by bad input shaping that I was considering earlier. One does have to remember that the shift registers don't clear stray bits unless you explicitly do an out() to them.

[peterhinch]

@JeffreyUitbeijerse You might like to read this doc on the general principles.

[mendenm]

That's a really good, complete article on the subject. It was the pre-conditioning problem that worried me in my previous comment. Without using a hard counter or dedicated quadrature peripheral, it is easy to miss multiple transitions within the response time of the loop. Some microcontrollers do have built-in quadrature decoders.

[peterhinch]

I cut my teeth on this problem fifty years ago, designing an early NC machine. The (hardware) optical encoder interface had to be perfect, never missing an edge. It took me some time to discover the various pitfalls - in particular metastability was little known in the early 70's.

They are interesting devices in that they seem simpler than they are. By some margin.

More recently I've had various people claiming that the exclusive-or solution is wrong. Hence the rather heavy-duty justification :)

[mendenm]

@peterhinch You've been at this even longer than I have. I got my first paying job doing computer interfacing in 1977. Building 8080 and z80 boards with 1kB - 4 kB (on our BIG system) of 2100-series sram with a 4 us cycle time.

[mendenm]

@peterhinch An interesting side note is about the metastability issue. When I took quantum mechanics from Richard Feynman in 1980, one of the things we worked through was the proof that no possible system can be guaranteed to always make a decision in finite time. In other words, you can never guarantee that it won't go metastable, no matter how hard you try. Of course, for all practical purposes, you can make the metastable window almost arbitrarily narrow, although there are both thermodynamic and quantum mechanical limits to how narrow it can be. TLDR: it can be pretty narrow, which is why circuits such as what you show are nearly perfect.

[rkompass]

@JeffreyUitbeijerse
I found that you have the sequence

    out(isr, 2)
    in_(pins, 2)
    mov(osr, isr)   # save the state in the osr, so that we can use isr for other purposes

and the OSR is not used otherwise.
So my impression that you lost sometimes a bit in the

    mov(isr, y)
    push(noblock)

sequence is not justified.
Also I ran your code against a quadrature code generator (using the other PIO block).
The results were flawless: It showed correct counting up or down, measured up to
10_000_000 times with frequencies up to 375 kHz (full rotation cycle i.e. 1.5 MHz state change). Possibly much higher.

So my next guess is that

1. In the interaction from pin13, something might interfere. I do not understand the role of the pinI1, to be honest.
2. You might lose a few counts while reading the FIFO out. Your PIO program permanently pushes noblockingly to the FIFO, as my program does.
   For that purpose I have the reading procedure:

        for _ in range(self.qenc.rx_fifo()):
            self.qenc.get()
        n = self.qenc.get()

that first removes the older results before getting the actual one.
In just doing a sm0.get() and afterwards perhaps resetting the counter you might lose the more actual counts.

[JeffreyUitbeijerse]

Hi all,

Thank you for all the suggestions already, I will provide some answers to them below.

Are you carefully filtering the edges from the encoder, so that they have clean transitions, and do you have the inputs in Schmitt-trigger mode?

• At first I did not think the quality of the signals from the encoder was the problem, since the encoder peripheral on the F28379D is able to read the signals perfectly. However, this peripheral (and the output signals of the encoder) are in 5V logic, and I use a voltage divider to convert the signals to 3.3V logic to use as inputs to the Pico. Again, I am not an electrical engineer so I am not familiar with the pros and cons of said divider, but could this affect the signal quality? I will have to use an oscilloscope to inspect it, which I do not have at home.

How large is your PIO program? I faintly recall from an analysis sometime ago that programs are loaded into the state machine memory top-down. If your code is smaller than the state machine memory size, the computed jumps may go to a different address than intended. But then the code should fail.

• My program is exactly 32 instructions, so that should not be the problem.

@JeffreyUitbeijerse You might like to read this doc on the general principles

• Thank you for the suggesion, I will have a look at it.

Also I ran your code against a quadrature code generator (using the other PIO block).
The results were flawless: It showed correct counting up or down, measured up to
10_000_000 times with frequencies up to 375 kHz (full rotation cycle i.e. 1.5 MHz state change). Possibly much higher.

• I actually did the same using the a different state machine to simulate the quadrature signals, and used it to debug my code initially. As you mentioned, it works like a charm, which is why I was surprised to encounter the issue when trying the code with an actual encoder. Now that I think about it, this might point out once more that the voltage divider I use to shift logic levels is the actual problem here, not the PIO implementation.

In the interaction from pin13, something might interfere. I do not understand the role of the pinI1, to be honest.

• The role of the pin is to be able to know an actual position of your encoder, rather than just know the relative movement of it. The picture below shows the A, B, and Index signals (in this case called Z signal). In this picture, the Index/Z signal goes high once per revolution, so if you know at what exact angle this happens, you know the exact angle (in real life) of the encoder and not only the relative movement. Resetting the counter once the Index/Z signal is high for the first time, is essentially way of 'homing' your system.
  
  That said, I do not use this signal yet in the experiments described in the original post, and also tied Pin 13 low to ensure no interaction.

You might lose a few counts while reading the FIFO out. Your PIO program permanently pushes noblockingly to the FIFO, as my program does. For that purpose I have the reading procedure:

for _ in range(self.qenc.rx_fifo()):
            self.qenc.get()
        n = self.qenc.get()

that first removes the older results before getting the actual one.
In just doing a sm0.get() and afterwards perhaps resetting the counter you might lose the more actual counts.

• Good point, but the suggested implementation unfortunately does not fix the issue.

[mendenm]

I previously asked if the pins were in Schmitt-trigger mode. Are they set up this way?

[mendenm]

You will have to directly read the PADx register for the appropriate pin, using mem32[0x4001c004 + 4*pin_number] and then mask off the bit , so schmitt_enabled = (mem32[0x4001c004 + 4*pin_number] & 0x2) != 0 should give you the result. (See table 340 and beyond in the data sheet.) The rp2040 data sheet does say they default to 'on', and if the SDK also implies this, they probably are, but I would check. I don't like hardware that is probably in the right state.

Added note: mem32[] is in the machine module.

[JeffreyUitbeijerse]

Executing the check when connected to the Pico gives the following result, so the pins are in Schmitt trigger mode.

[mendenm]

being an old (hence paranoid) programmer, I would suggest you add:

machine.mem32[0x4001c004 + 4*14] |= 2
machine.mem32[0x4001c004 + 4*15] |= 2

to your code, so you aren't depending on hidden features. You might do these things by creating a function to set this bit, of course, to make it more self-explanatory.

[JeffreyUitbeijerse]

Unfortunately it does not resolve the problem. I also tried to make a different logic level shifting circuit using a MOSFET, but this does not resolve the issue either.

[rkompass]

Did you try my PIO program?