Lost pin-change interrupts while doing I²C

[radiohyperactivity]

I'm having a bit of an issue, and I'm not really sure how to proceed.

I've created two "drivers". One for tracking the state of a rotary encoder (endoder.py) and one to update a I²C connected LCD display (lcd.py). The code to track the rotary encoder use pin-change interrupts (trigger=Pin.IRQ_FALLING|Pin.IRQ_RISING).

When I test this code using a simple print() statement to output the position, I'm unable to move the encoder fast enough for it to loose interrupts. That is to say, the count shown by the print() statement is always in line with what is expected based on the number of turns of the encoder. When I combine this with code to update the LCD over I²C I start to loose steps; and from this I infer that I'm loosing interrupts.

Now, the encoder I use is of the types normally found on a CNC pendant. It has 100 steps per revolution and it's easily possible to turn it several times per second. At 4 interrupts per "step" and lets say 2.5 turns per second, that should give me about 1k interrupts/second. So, as long as there's time to service the interrupt at least every 1 ms, I shouldn't loose any.

• Board: Raspberry Pi Pico 2
• Version: "Unofficial Latest"
• Downloaded from: https://www.raspberrypi.com/documentation/microcontrollers/micropython.html

I'm including all the code, as it's only about 130 lines.

• Any advice on how to proceed to make sure I don't miss these occasional interrupts?
• Does MicroPython disable interrupts somehow while doing I²C?
• Is this simply asking to much or the Pico 2? Or will I have to move to C to work around this?

main.py

from encoder import Encoder
from machine import I2C
from machine import Pin
from lcd import LCD

i2c = I2C(1, sda=Pin(2), scl=Pin(3), freq=1_000_000)
lcd = LCD(i2c, 0x27, 4, 20)

encoder = Encoder(14, 15)
last = encoder.count

lcd.display(4, 2, str(last))

while True:
    next = encoder.count
    if last != next:
        last = next
        lcd.display(4, 2, f"{last} ")
        # print(last)

lcd.py

from time import sleep_ms
from time import sleep_us

class LCD:
    def __init__(self, i2c, addr: int, rows: int, cols: int) -> None:
        self._i2c = i2c
        self._addr = addr
        self._rows = rows
        self._cols = cols

        self._backlight = True

        RCMD = 0x28 if (rows > 1) else 0x20

        for init in [
            [self._send,    0x00, 50  ], # NoOp
            [self._nibble,  0x30, 1000], # 8bit
            [self._nibble,  0x30, 5   ], # 8bit
            [self._nibble,  0x30, 5   ], # 8bit
            [self._nibble,  0x20, 5   ], # 4bit
            [self._command, RCMD, 5   ], # Rows
            [self._command, 0x0c, 5,  ], # On
            [self._command, 0x01, 5   ], # Clear
            [self._command, 0x06, 5   ]  # L2R
        ]:
            sleep_ms(init[2])
            init[0](init[1])

    def _command(self, value: int, data: bool = False) -> None:
        for shift in [0, 4]: # Send high nibble first, then low nibble
            self._nibble(((value << shift) & 0xf0) | (0x01 * data))

    def _nibble(self, value: int) -> None:
        self._send(value) # Send value
        
        self._send(value | 0x04) # Toggle latch high
        sleep_us(1)

        self._send(value & 0xfb) # Toggle latch low
        sleep_us(50)

    def _send(self, value: int) -> None:
        # Data in high nibble, control signals in low nibble
        self._i2c.writeto(self._addr, bytes([value | (self._backlight * 0x08)]))

    def backlight(self, backlight: bool) -> None:
        self._backlight = backlight
        self._send(0) # Backlight is updated on every send

    def on(self, on: bool) -> None:
        self._command(0x0c if on else 0x08)

    def clear(self) -> None:
        self._command(0x01)
        sleep_ms(2)

    def display(self, x: int, y: int, text: str) -> None:
        if y < self._rows:
            # Address map for columns + bit 7 set for command
            self._command([0x80, 0xc0, 0x94, 0xd4][y] + x)

            for char in text[:self._cols - x]:
                self._command(ord(char), True)

encoder.py

from machine import Pin
import machine

# Based on https://github.com/buxtronix/arduino/blob/master/libraries/Rotary/Rotary.cpp

REST = const(0) # At rest
CW1  = const(1) # 1/4 step clockwise
CW2  = const(2) # 2/4 step clockwise
CW3  = const(3) # 3/4 step clockwise
ACW1 = const(4) # 1/4 step anticlockwise
ACW2 = const(5) # 2/4 step anticlockwise
ACW3 = const(6) # 3/4 step anticlockwise

class Encoder:
    states = [
        [REST, ACW1, CW1 , REST], # Next state from rest
        [REST, REST, CW1 , CW2 ], # Next state from 1/4 step clockwise
        [REST, CW3 , CW1 , CW2 ], # Next state from 2/4 step clockwise
        [REST, CW3 , REST, CW2 ], # Next state from 3/4 step clockwise
        [REST, ACW1, REST, ACW2], # Next state from 1/4 step anticlockwise
        [REST, ACW1, ACW3, ACW2], # Next state from 2/4 step anticlockwise
        [REST, REST, ACW3, ACW2]  # Next state from 3/4 step anticlockwise
    ]

    def __init__(self, a: int, b: int):
        self.a = Pin(a, Pin.IN, Pin.PULL_UP)
        self.a.irq(self.isr, trigger=Pin.IRQ_FALLING|Pin.IRQ_RISING)

        self.b = Pin(b, Pin.IN, Pin.PULL_UP)
        self.b.irq(self.isr, trigger=Pin.IRQ_FALLING|Pin.IRQ_RISING)

        self.state: int = REST
        self.count: int = 0

    def isr(self, _):
        next = self.states[self.state][self.a.value() * 2 + self.b.value()]

        if next == REST:
            if self.state == CW3:
                self.count += 1
            elif self.state == ACW3:
                self.count -= 1

        self.state = next

[GitHubsSilverBullet]

You might want to try hard=True when setting the irq handler.

[radiohyperactivity]

You are of course 100% correct!

And I must admit I feel rather silly now for not having seen this in the documentation!

Though in my defence, I think defaulting to a "soft" interrupt (whatever that means) is in clear violation of the principal of least astonishment! But still; it was always there in the documentation, so there's really no excuse! The lesson for me will have to be; read the documentation, the whole documentation, and don't make assumptions!

Anyway; thank you so much! I was just starting to fall in love with MicroPython, and this issue had me rather disillusioned!

[radiohyperactivity]

Also; was looking around a bit for some more background on what these "soft" interrupts are (under the hood), but neither the "Writing interrupt handlers" section of the documentation1 nor a (admittedly rather quick) Google search provided much insight. Do you have a reference where I can learn more about that concept?

[davefes]

Maybe of interest ... https://forum.micropython.org/viewtopic.php?t=10798 , by jimmo:

Some key things to be aware of:

• MicroPython has both "bare-metal" (e.g. STM32) and "OS" (e.g. ESP32, Linux) ports. On the bare metal ports, when a hardware interrupt fires, the Python VM is executed in the context of the hardware interrupt (i.e. no delay). Hardware interrupts are not blocked by the garbage collector, and hard interrupt handlers may not allocate.
• On OS ports, interrupts happen in "scheduler" context which may have a delay as the VM only runs the scheduler every N instructions, and the VM is blocked while the GC is running.
• Timer interrupts may be pre-empted by other higher-priority interrupts, so it's important to ensure that you don't have other peripherals active (e.g. USB) or you need to account for that.
• Non-interrupt code on bare-metal ports will have non-deterministic timing if the GC is active (allocations take a variable amount of time because they involve scanning the heap), and obviously allocations can trigger collection. You can use gc.lock() (and gc.unlock()) to force your code to not allocate (will raise MemoryError instead). Other than that, the VM is deterministic (i.e. it doesn't have, for example, optimisations that kick in automatically and change behavior).

Which category is the Pico 2 in?

[radiohyperactivity]

Useful information, thanks!

But it still doesn't give me a solid grasp of precisely what a "soft" interrupt actually is. Any further insight into that would be much appreciated!