search

rm-hull / luma.lcd

Python module to drive PCD8544, HT1621, ST7735, ST7567 and UC1701X-based LCDs
https://luma-lcd.readthedocs.io
MIT License
156 stars 56 forks source link

ILI9341 TFT support #67

Closed sgjava closed 4 years ago

sgjava commented 5 years ago

Do you anticipate supporting the ILI9341 TFT display? I'm looking for a bigger display for a weather station.

rm-hull commented 5 years ago

Always open to supporting new devices, but I've have conversations with other people about supporting other higher-resolution displays (have a browse through some of the issues to see the discourse), and have said before that because we're using a fairly slow interpreted language, as the number of pixels increases exponentially, the longer it will take to render a frame.

There are some tricks I've employed in other drivers to make it a bit quicker:

If you think about the small monochrome OLEDs - we have to push out 1024 data bytes (= 128 x 64 / 8) for a full frame, but for the color LCD display above (assuming 64k colors) it would need to process 153600 bytes (= 240 x 320 x 2) ... 150 times as much data

If you need quicker rendering times, I would be inclined to use the kernel-based framebuffer-based display drivers that come pre-bundled with the Raspberry Pi distros.

That said, it is possible to add a driver (of course), ... but it will be slow

sgjava commented 5 years ago

Understood. I'm looking for a cross platform solution for a larger display (I really do not use Pis). What is the largest display you support? Monochrome is fine.

rm-hull commented 5 years ago

I haven’t looked at the data sheet for the ili9341 but if it is a color LCD, I would assume that the minimum colour mode would be 16 bits.

Have you got a link/url to the specific breakout board that you are looking at?

rm-hull commented 5 years ago

I'm looking for a cross platform solution for a larger display

It suddenly struck me that we can implement a luma /dev/fb bridge device-type. This would allow us to capitalize on pre-existing kernel display drivers, but allow programs that have already been written against luma components to work against a standard linux framebuffer. Using /dev/fb means driving larger displays is handled by C code in the kernel (so should be quick), so this will open up being able to support ILI9341 (and many others).

I think the generic implementation for this framebuffer driver would be quite straightforward and quick to implement, but the question is... which luma submodule do we put it in? I'm thinking luma.emulator or possibly luma.core ...

any thoughts @thijstriemstra ?

thijstriemstra commented 5 years ago

Documentation about linux framebuffers: https://www.kernel.org/doc/Documentation/fb/framebuffer.txt

I would say, put it in luma.core, but once there's a pr, it'll become more clear where it belongs. Cool idea!

martin-Stv commented 4 years ago

HI

I am a complete novice with this stuff and have produced a set of gauges for my car using your LUMA and I wanted some bigger screens, trying to port from ST7735 to ili9341 is almost impossible,

support for these screens would be very useful, and as i dont do fast moving graphics slow is fine. any advice or a date when drivers might be available in the Luma.LCD package,

the big problem with fb is you can only have one screen, with SPI you can have two, the Adafruit ILI9341 library works but does not support canvas which just so easy to use

Thanks for taking the time to read this Regards

rm-hull commented 4 years ago

v2.2.0 of luma.lcd (https://pypi.org/project/luma.lcd/2.2.0/) now supports ILI9341.