Il driver Rust epdsi pilota pannelli e-paper su microcontrollori diversi senza cambiare una riga del codice del pannello. Mariusz Jurgielewicz lo ha dimostrato su due schede molto distanti fra loro: un Adafruit RP2040 Feather ThinkInk con core Cortex-M0+ e un Seeed Studio XIAO ESP32-C3 con architettura RISC-V. Sul XIAO, abbinato alla ePaper Driver Board di Seeed, il framework gestisce sette pannelli e cinque controller IC diversi. Cambia solo il glue del HAL, cioè il codice che parla con il silicio della scheda.
epdsi è un framework no_std basato su embedded-hal 1.0. La sua idea portante è separare quattro cose che di solito finiscono ammucchiate nello stesso file: il pannello fisico, il controller IC, il trasporto SPI e l’orchestrazione. Così aggiungere un pannello a un controller già supportato richiede un solo nuovo file, quello che descrive il pannello. La pagina del progetto su Hackster.io di Mariusz Jurgielewicz raccoglie il lavoro completo, con il codice e le prove sui vari pannelli.
EpdPanel, EpdController e SpiBusWrapper: come è fatto il framework
L’architettura di epdsi si regge su quattro tipi principali. EpdPanel è un tipo zero-sized che descrive il pannello fisico: larghezza, altezza, modalità colore e particolarità di tensione o LUT. EpdController contiene la logica di comando del driver IC, quindi la sequenza di init, l’indirizzamento, la scrittura del frame, il refresh e lo sleep. SpiBusWrapper gestisce il trasporto fisico, cioè un embedded-hal SpiDevice più i pin di controllo DC, RST e BUSY. EpdDriver orchestra il tutto tramite EpdBuilder ed espone l’API pubblica, mentre i colori passano per gli enum ColorMode e ColorChannel.
- EpdPanel: descrive il pannello fisico, dimensioni, modalità colore, tensione e LUT
- EpdController: sequenza di init, indirizzamento, scrittura frame, refresh e sleep del driver IC
- SpiBusWrapper: trasporto SPI più i pin DC, RST e BUSY
- EpdDriver: orchestra i componenti tramite EpdBuilder ed espone l’API pubblica
- ColorMode e ColorChannel: gestiscono i colori passati all’API
Il framework offre build bloccanti su embedded-hal e build asincrone su embedded-hal-async, selezionate da feature flag. Per chi ha poca RAM c’e’ render_paged(), che disegna il pannello a bande orizzontali con buffer allocati sullo stack. In questo modo un frame da 48.000 byte resta gestibile anche su hardware limitato. Il target di compilazione per il XIAO ESP32-C3 è riscv32imc-unknown-none-elf, con esp-hal 1.0.0 e embedded-graphics per la grafica.
Sette pannelli, cinque controller e i tempi misurati su SPI
Sul XIAO ESP32-C3 con ePaper Driver Board girano diversi pannelli. Il GDEQ0426T82 è un mono da 4,26 pollici, 800×480, con controller SSD1677. Il GDEM0213B74 è un mono da 2,13 pollici, 122×250, con SSD1680. Lo ZJY122250-0213AJH-E5 è un quad-color da 2,13 pollici, 122×250, con JD79661. Il GDEM0154Z90 è un tri-color da 1,54 pollici, 200×200, con SSD1681. Poi ci sono SE0352N14 e GDEY037T03, entrambi con controller UC8253, il primo tri-color da 3,52 pollici e il secondo mono da 3,7 pollici. In totale epdsi copre 8 controller IC che pilotano 13 pannelli.
I numeri aiutano a capire cosa aspettarsi. A 4 MHz di SPI, il pannello mono da 4,26 pollici fa un refresh completo in circa 3,75 secondi e un refresh parziale in circa 1,0 secondo. Spostare un frame da 4.000 byte via SPI richiede circa 8 ms. I pannelli tri-color e quad-color invece richiedono da 14 a 17 secondi per aggiornamento e non hanno una modalità parziale significativa. Perciò la scelta del pannello dipende molto da quanto spesso si vuole aggiornare lo schermo. Il socket FPC del Feather ThinkInk ha 24 pin, mentre il pannello JD79661 da 2,13 pollici è quad-color.
Chi vuole rifare il progetto parte da un XIAO ESP32-C3 con la ePaper Driver Board di Seeed, oppure da un RP2040 Feather ThinkInk. In ogni caso il codice del pannello non cambia: cambia solo il glue del HAL.
Vale la pena sapere che la build in debug supera i 5 MB, mentre la release scende a circa 750 KB. Chi compila per microcontrollori con flash limitata deve quindi lavorare in release. Il framework usa Rust con no_std, esp-hal 1.0.0, embedded-graphics, embedded-hal 1.0 ed embedded-hal-async. Sono tutte librerie mature, quindi il progetto si può ricostruire senza dipendenze esotiche. La dimostrazione su due architetture diverse, Cortex-M0+ e RISC-V, è la prova che il livello di astrazione tiene.
Fonte: https://www.hackster.io/melastmohican/driving-e-paper-displays-with-rust-on-the-xiao-esp32-c3-7c6ecb
