Support for random displays for which the user already has a driver

[nikthefix]

It would be useful to have a user profile which is driver agnostic and simply prints to a psram buffer. This way TFT_eSPI could be used directly with the new AMOLED boards from Lilygo and others, which always have unfamiliar driver chips but have driver code which will accept 'push colours' from a specified frame buffer. This would also allow TFT_eSPI to be used with arbitrary QSPI , RGB parallel (ST7701S etc) and MIPI-DSI displays. For those who would rather not use LVGL this would be welcome I think.

[Bodmer]

The library has previously used that method to support ePaper displays. using an external hardware interface library. The ePaper support has been deprecated recently.

However, this may work as a "sprite only functionality" setup file but I am not able to test it:

// For sprite only functionality (untested)
#define USER_SETUP_ID 0

#define TFT_WIDTH  1000
#define TFT_HEIGHT 1000

#define TFT_INIT_DELAY 0

#define TFT_NOP     0x00
#define TFT_SWRST   0x00

#define TFT_CASET   0x00
#define TFT_PASET   0x00
#define TFT_RAMWR   0x00

#define TFT_RAMRD   0x00
#define TFT_IDXRD   0x00

#define TFT_MADCTL  0x00
#define TFT_MAD_MY  0x00
#define TFT_MAD_MX  0x00
#define TFT_MAD_MV  0x00
#define TFT_MAD_ML  0x00
#define TFT_MAD_BGR 0x00
#define TFT_MAD_MH  0x00
#define TFT_MAD_RGB 0x00

#define TFT_INVOFF  0x00
#define TFT_INVON   0x00


#define TFT_MISO -1
#define TFT_MOSI -1
#define TFT_SCLK -1


#define LOAD_GLCD   // Font 1. Original Adafruit 8 pixel font needs ~1820 bytes in FLASH
#define LOAD_FONT2  // Font 2. Small 16 pixel high font, needs ~3534 bytes in FLASH, 96 characters
#define LOAD_FONT4  // Font 4. Medium 26 pixel high font, needs ~5848 bytes in FLASH, 96 characters
#define LOAD_FONT6  // Font 6. Large 48 pixel font, needs ~2666 bytes in FLASH, only characters 1234567890:-.apm
#define LOAD_FONT7  // Font 7. 7 segment 48 pixel font, needs ~2438 bytes in FLASH, only characters 1234567890:-.
#define LOAD_FONT8  // Font 8. Large 75 pixel font needs ~3256 bytes in FLASH, only characters 1234567890:-.
//#define LOAD_FONT8N // Font 8. Alternative to Font 8 above, slightly narrower, so 3 digits fit a 160 pixel TFT
#define LOAD_GFXFF  // FreeFonts. Include access to the 48 Adafruit_GFX free fonts FF1 to FF48 and custom fonts

#define SMOOTH_FONT

I will add to my long to do list.

[nikthefix]

Thanks Bodmer, this is exactly what I was looking for. With the recent proliferation of cheap esoteric displays it's good to have an option to detach TFT_eSPI graphics from display driver and data bus config. It would be great to have a standard interface which all devs could agree on as an option - like Linux framebuffer. Once everything is up and running with whatever display then optimizing for speed with partial graphics RAM updates should be straightforward albeit at the mercy of the supplied display driver implementation.

If such a TFT_eSPI profile could contain a data set of 'need to update' screen coordinates then this could be easily passed to our glue code. I can see a profile like this easing the burden on you to constantly support new hardware. It could be the corner for 'all others - at your own risk'. And then I bet the manufacturers of dev boards featuring these larger displays will provide glue code as often for TFT_eSPI as they seem now to do for LVGL.

LVGL / Square Line Studio is absolutely fantastic but is nowhere near as fast as using TFT_eSPI raw. You can see this using Gifs in LVGL compared to TFT_eSPI / Larry Bank's Gif player - of course taking into account the LVGL overhead of dealing with touch etc.

Am I correct in thinking that TFT_eSPI code is used 'under the hood' of LVGL? If so then this could be the nugget needed for a driver / bus agnostic framework for those who want to stick with Bodmer no matter what.