A closer look at Raspberry Pi RP2040 Programmable IOs (cnx-software.com)

Any I/O is basically compression. So lets think about what we're actually outputting. We're converting a raw bitstream from two GPIO pins paired (Ex: 00, 01, 01, 01, 11, 11, 10, 00, 01, 11), into a singular message: such as +6.

There are two applications of a quadrature encoder that I can think of.

1. Virtual Pot -- Converting the messages into a kind of "-100 to +100 slider", such as a volume control knob. In this case, you want a regular update schedule at human-interface speeds (~1000 updates / second or slower).

2. Rotational Velocity sensor -- Converting the messages into a speed. You're willing to batch the bitstream up as slowly as possible, maybe waiting for a rollover event (+128 or -128). And you just interrupt on those overflows.

-------

Since the input format is already set, we now think about the output format: how to represent +6 and or -12?

Based on the PIO instruction set, it seems like +6 and -12 probably would be easiest as two separate registers in two different state-machines.

Every time an "increment" is detected, the FIFO-associated with +1 gets a +1 bit added to it. Every time a "decrement" is detected, the 2nd FIFO associated with -1 gets a +1 bit added to it.

----

In pseudocode:

    IncrementSide(){
        currentState = 00; // default

        while(1){
            nextState = in(GPIO0) | in(GPIO1);
            if(currentState == 00 and nextState == 01){
                push 1;
            }
            if(currentState == 01 and nextState == 11){
                push 1;
            }
            if(currentState == 11 and nextState == 10){
                push 1;
            }
            if(currentState == 10 and nextState == 00){
                push 1;
            }
            currentState = nextState;
        }
    }

I'm saying "push 1", but "push 1 into the OSR". It looks like the OSR has some kind of auto-push mechanism, but if that doesn't work then a manual-push might be needed in the code proper. Hard to say from the docs alone.

DecrementSide would be just the inverted if-statements:

            if(currentState == 00 and nextState == 11){
                push 1; // Decrement side checking for a decrement
            }

This above methodology would only work for #2 ("velocity"), and fails for #1 ("positional"), because the increment-side and decrement-side would be updating at varying rates.

I probably can make a positional-decoder instead of a velocity one using similar principles. Or maybe by somehow ensuring that the +1 and -1 messages go into the same FIFO to be picked up by the host CPU.

The idea is route "0" messages to /dev/null, compressing the input stream. The host still sees the important +1 and -1 messages. The exact mechanism for that is up for debate, but the simple if-else state machine above seems to accomplish that to a limited extent.

------

EDIT: Hmmm, maybe a singular FIFO can be done if we have push1 and push0 for the two kinds of messages: 1 representing +1 and 0 representing -1.

Anyway, my point is that there's lots of solutions here. It doesn't seem very difficult to me conceptually. Just a lot of experimentation needed to know exactly how those 9 instructions work and the exact mechanisms of the ISR / OSR / X reg / Y reg.

Ex: 00 -> 10 -> 00 is interpreted as 0 -> 3 -> 0, or -1 transition then a +1 transition.

01 -> 11 -> 01 is interpreted as 1 -> 2 -> 1, or +1 followed by a -1 transition.

All possible combinations of bounces (00 -> 01 -> 00, 00 -> 10 -> 00, 01 -> 11 -> 01, 01 -> 00 -> 01, etc. etc.) have this +1 / -1 or -1/+1 property.

Your discussion point of "here's a VHDL block" seems to understand the general issue. You need a non-trivial amount of FPGA-magic (LUTs) to implement logic and routing at those speeds. SATA has some kind of error-correction code if I remember correctly... so its not exactly easy to parse those messages.

Even though I did not intend to say we should have SATA and HDMI on the RP2040 itself (I didn't know if it was possible), it still proves that having realtime control on the IOs opens the door for way more functionalities than SPI/I2C/UART specific ports. All of it using the same SoC and potentially less pins.

Having the same level of control on any device would be beneficial in my opinion.