Closed skeyvin closed 1 year ago
Those drivers work in a different way in that they draw directly to the screen rather than using a frame buffer. In this respect it is similar to this driver. It is an approach which is very fast and can be economical in RAM.
In order to be compatible with nano-gui
, micro-gui
and writer
a display driver must be subclassed from FrameBuffer
. This enables a driver to be small in terms of code size, but there is a cost in RAM usage. There is also a cost in performance since the contents of the frame buffer must be transferred to the display. The drivers I have developed have performance adequate for user GUI screens. The main reasons for requiring higher performance are gaming and simulations.
While it would be possible to write a parallel driver based on a frame buffer I'm unconvinced that it fits any use case: it would probably still be too slow for gaming. The improvement in micro-gui
screen performance would be minimal. There is also the pin count which is a big problem on many platforms. I have also opted not to support touch on micro-gui
for the reasons here.
The bottom line is therefore no. If you want to develop high speed applications you are best off using or adapting the driver you cited.
hi will there be support for non spi protocols like 8bit parallel? there is a library for basic controlls at https://github.com/HughMaingauche/ILI9341-parallel-TFT-driver-for-micropython and i would like to see it being supported