Portable, software-driven IQSPIBus backend built only on pinMode()/digitalWrite() - works on any Arduino core, notably RP2040 and STM32, neither of which exposes a hardware peripheral for this panel family's quad-SPI protocol the way ESP-IDF's esp_lcd does for ESP32 (see QSPIBusESP32.h): More...
#include <QSPIBusBitBang.h>
Public Member Functions | |
| QSPIBusBitBang (int8_t cs, int8_t sclk, int8_t d0, int8_t d1, int8_t d2, int8_t d3) | |
| bool | begin () override |
| Sets up the bus (pins/peripheral). Returns false on failure. | |
| void | end () override |
| bool | writeCommand (uint8_t cmd, const uint8_t *param, size_t len) override |
| bool | writeColor (uint8_t cmd, const uint8_t *data, size_t len) override |
 Public Member Functions inherited from IQSPIBus | |
| virtual | ~IQSPIBus ()=default |
| virtual bool | begin ()=0 |
| Sets up the bus (pins/peripheral). Returns false on failure. | |
| virtual void | end ()=0 |
| virtual bool | writeCommand (uint8_t cmd, const uint8_t *param, size_t len)=0 |
| virtual bool | writeColor (uint8_t cmd, const uint8_t *data, size_t len)=0 |
Detailed Description
Portable, software-driven IQSPIBus backend built only on pinMode()/digitalWrite() - works on any Arduino core, notably RP2040 and STM32, neither of which exposes a hardware peripheral for this panel family's quad-SPI protocol the way ESP-IDF's esp_lcd does for ESP32 (see QSPIBusESP32.h):
- RP2040 has no dedicated quad-SPI-out peripheral; its PIO blocks could bit-bang this protocol at much higher throughput with a custom PIO program, but that's a real follow-up project, not something to get subtly wrong un-tested against real hardware.
- STM32's QUADSPI/OCTOSPI peripheral (where present - H7/F7/L4+/..., not every part) is designed for external flash/PSRAM (address-phase memory-mapped or indirect reads/writes), not for driving a display controller's command/pixel-write protocol, and its pin/AF/clock setup is per-variant CubeMX territory - not something this library can wire up generically without a specific target board.
Reproduces the same wire protocol QSPIBusESP32/esp_lcd's quad_mode produces (see IQSPIBus.h and DisplayDriverQSPI.h's class doc comment): the 32-bit {opcode, cmd, 0x00, 0x00} frame is always clocked out over all 4 data lines (a nibble per clock, MSB-first); what follows is clocked out over D0 only (1 bit/clock) for a 0x02 ("param") frame, or over all 4 lines (a nibble/clock) for a 0x32 ("color") frame.
This is correctness-first, not throughput-first: each bit is one digitalWrite() pair (data setup + clock pulse), so a full-screen writeColor() call is far slower here than on QSPIBusESP32's DMA path. Good enough to bring a panel up and validate the higher layers (NV3041ADriver, ...) on RP2040/STM32; treat clock-limited frame rate as an expected tradeoff of this backend, not a bug.
Constructor & Destructor Documentation
◆ QSPIBusBitBang()
|
inline |
Member Function Documentation
◆ begin()
|
inlineoverridevirtual |
Sets up the bus (pins/peripheral). Returns false on failure.
Implements IQSPIBus.
◆ end()
|
inlineoverridevirtual |
◆ writeColor()
|
inlineoverridevirtual |
Sends len bytes of pixel/color data for the given RAM-write command (usually 0x2C), framed with the 0x32 ("data over 4 lines") opcode. Returns false on transport failure. Blocks until the whole transfer has been accepted by the panel (synchronous from the caller's point of view, even if the underlying transport is internally asynchronous/DMA-driven).
Implements IQSPIBus.
◆ writeCommand()
|
inlineoverridevirtual |
Sends one MIPI-DCS/vendor register command with up to len parameter bytes, framed with the 0x02 ("param bytes over 1 line") opcode. Returns false on transport failure.
Implements IQSPIBus.
The documentation for this class was generated from the following file:
- src/TinyGPU/Abstractions/QSPIBusBitBang.h
