The Pico Display 2 example specifies a baud of 74 * 1000 * 1000.
However, the highest baud the Raspberry Pi Pico can achieve is
62,500,000.
I checked and even when the baud of 74 * 1000 * 1000 is specified,
it ends up using the max that the Raspberry Pi Pico can handle anyway.
This commit removes the incorrect baud parameter, using the default
parameter instead.
Defensively tear down DMA/PIO so it's in a known good state upon (soft)reset.
Issue was a race condition with DMA interrupts firing and not being achknowledged, leaving a stuck raised IRQ.
The blocking wait for DMA transactions also exacerbated this, turning a borken DMA interrupt and blank screen into an unrecoverable hardlock.
...not that the blank screen was recoverable without a soft reset anyway!
Switch from 12-bit to 10-bit gamma to fit RGB into a uint32_t. Simplifies PIO and halves the RAM usage for F/B buffer.
Switch "flip" to *literally* swap the front and back buffers, and then asyncronously DMA the new back buffer into the front ready for the next draw.
The FM6126A register write was causing some weirdness on soft reset where the pin state wasn't predictable.
Have twiddled some pins at startup to ensure everything works as expected.
Add set_hsv and set_all_hsv (since setting individual pixels with hsv is S L O W)
Made "flip()" blocking, it was easy to accidentally get a little tearing.
Switch MicroPython HUB75 driver over to DMA/PIO.
TODO:
* Move this into drivers for C++ use too
* Fix hitting "Stop" in Thonny causing rows to stick on the display (this is bad, and should not happen)
* Fix "Stop -> Start" in Thonny causing weird display issues (it's not memory offets, maybe DMA/PIO issues?)
This code is intentionally written in C++ to illustrate the basics of driving HUB75 without being overly complicated to read and understand.
Tested on a 32x32 panel and a 64x64 "FM6126A" panel, for which this code includes a magic pair of register settings.