Supporting multiple displays

[codewitch-honey-crisis]

It may not be the most common thing, but there are certain situations where driving multiple displays is desirable. One example is the nook e-reader that has e-paper and an LCD touch screen below it to navigate.

I've written some code for a proposed driver framework that I based off of your code, but it uses templates and constexpr instead of macros. It generates the same machine code, but type safe with less namespace pollution, and lets you run multiple displays. It also decouples the bus code from the driver code.

Anyway, in case you're interested, here's a brief article I wrote on it along with a bit of code with support for several displays, I2C, SPI, and 8-bit parallel. It also may be able to use pins higher than 31 for parallel but I have not tested that yet.

https://www.codeproject.com/Articles/5324976/High-Performance-Decoupled-Buses-for-IoT-Displays

[Bodmer]

It is possible to use two displays of the same type and pixel width/height when the chip select is managed by the sketch. This approach is used in the animated eyes example, but it is a bit of a cludge as things like cursor position and view port are not unique to each display.

Ideally all the hardware driver and display specific stuff needs separating but, as you say, mixed multi-display setups are relatively rare .

I will move this to the discussions section and have a look at you work.

[codewitch-honey-crisis]

Sure thing. The relevant ugly where you're concerned - the code I basically from your code is in common/tft_spi.hpp and common/tft_parallel8.hpp. Keep in mind the parallel code has some untested, unworking features, like the generic arduino code (which I'm not done messing with to see if i can make it work) and what I haven't tested is using pins higher than GPIO 31.

Edit: One thing to note is the extensive use of constexpr and otherwise C++ compiler magic to eliminate a lot of those code paths. It's not self-evident from looking at the source code, but a lot of the if statements in tft_parallel8.hpp for example are compiled out. Also GFX is a generic drawing library that uses this driver code to do higher level drawing ops like lines and fonts. It similarly uses constexpr and such so if you do happen to dig into things like gfx_pixel.hpp keep in mind that 90% of that code is also compiled out. I've checked the output at godbolt.org with GCC just to be sure.

[codewitch-honey-crisis]

I improved on that code quite a bit. It also happens to have I2C support. One thing I was thinking is that you could use templates behind the scenes so that you get statics per instantiation, allowing for multiple drivers of different types, different buses, etc, and then what you do is expose the primary's configuration with defines in the User_Setup.h so that stays mostly or entirely the same. For second and third drivers you can instantiate the templates directly. (But there's a primary one instantiated based on the defines in User_Setup.h)

Anyway, feel free to use that code or whatever. The main disadvantage of it is I haven't factored the processor support into separate headers, but because of the use of templates that gets a little tricky.

[KBLiveSolutions]

Hi
I have a project that requires having 5 displays, with 2 different displays types (1xILI9488 480x320, and 4xST7735 160x80).
Would that be possible to achieve somehow ?

[codewitch-honey-crisis]

you can do it with UIX and GFX.
GFX
UIX

But what I would do actually is use UIX or LVGL with the ESP LCD Panel API in order to do this, if you're using an ESP32

If you're using another mcu you can use my GFX drivers. like codewitch-honey-crisis/htcw_ili9488 and codewitch-honey-crisis/htcw_st7735

My stuff works with PlatformIO. It will not work with the Arduino IDE out of the box due to IDE limitations.

[KBLiveSolutions]

Thanks for the help. I'm using a RP2040.
I'd like to stick to TFT_eSPI if possible...

[Bodmer]

There is no built in capability to handle multiple display types. Perhaps using two RP2040 boards in the answer, one for the ILI9488 and one for the 4 ST7735 types.

[KBLiveSolutions]

There is no built in capability to handle multiple display types. Perhaps using two RP2040 boards in the answer, one for the ILI9488 and one for the 4 ST7735 types.

That's what I was thinking. Thanks for the feedback !

[athinboy]

I prefer the way of ucglib that past config info by construct function para :
Ucglib_ST7735_18x128x160_HWSPI ucg(/cd=/ 9 , /cs=/ 10, /reset=/ 8);
first ,avoided to modify .h file.
second ,it is easy to support mulitple display.
sorry for my poor english!

[Bodmer]

The key advantage of changing the header is that the examples need no changes to run. If you use the User_Setup_Select.h file are create a template header for each hardware configuration, then changing between setups is fast and easy.