Sorry for the ambiguity, it's just that big I2C upload throwing off things, more of a pointing-out-the-obvious-thing, not a this-is-a-solution thing. The I2C in the SDK is blocking.
You're doing a lot in display_update(), that's gotta hurt the main loop. Might want to shuffle the display stuff off to the second core, at least, separate real time stuff from everything else.
In display.c, I2C seems to be initialized at 100 kHz. Worst case updating a 128*64 mono OLED would be a ~1KB I2C write, or say 1000 bytes * 10 * 10 us == 100 ms. So a busy display will spoil things. SH1106 works with 400 kHz, but a 25 ms update is still much more than the latency of a single serial MIDI of ~1 ms. Can't mix this into the real-time stuff.
I was also wondering about fitting something interrupt-driven in there but then I'm not familiar with tusb.
Someone did write non blocking I2C for the Pico, but code on this topic seems to be hard to find:
Non-blocking PIO I2C example available
viewtopic.php?t=341501
Multicore seems to be the safest option. Then both cores are available for tasks.
You're doing a lot in display_update(), that's gotta hurt the main loop. Might want to shuffle the display stuff off to the second core, at least, separate real time stuff from everything else.
In display.c, I2C seems to be initialized at 100 kHz. Worst case updating a 128*64 mono OLED would be a ~1KB I2C write, or say 1000 bytes * 10 * 10 us == 100 ms. So a busy display will spoil things. SH1106 works with 400 kHz, but a 25 ms update is still much more than the latency of a single serial MIDI of ~1 ms. Can't mix this into the real-time stuff.
I was also wondering about fitting something interrupt-driven in there but then I'm not familiar with tusb.
Someone did write non blocking I2C for the Pico, but code on this topic seems to be hard to find:
Non-blocking PIO I2C example available
viewtopic.php?t=341501
Multicore seems to be the safest option. Then both cores are available for tasks.
Statistics: Posted by katak255 — Fri Oct 17, 2025 11:26 pm