Bodmer / TFT_eSPI

Arduino and PlatformIO IDE compatible TFT library optimised for the Raspberry Pi Pico (RP2040), STM32, ESP8266 and ESP32 that supports different driver chips
Other
3.69k stars 1.06k forks source link

multiple user setups ? #319

Closed tobozo closed 5 years ago

tobozo commented 5 years ago

Hello and thanks for this awesome library 👍

Is there a way to use the library in the Arduino IDE without editing User_Setup.h ?

Altering the contents of a file located inside the library folder feels so wrong, and also frustrating since custom settings are overwritten or lost on every release update.

So far I've tried to define the settings in my sketch instead of burrying them in the library folder, but I can't get this to work by using simple defines.

Doing this:

#define ST7789_DRIVER
#define TFT_WIDTH  240
#define TFT_HEIGHT 240

#define TFT_DC    23
#define TFT_RST   32
#define TFT_MOSI  26   // for hardware SPI data pin (all of available pins)
#define TFT_SCLK  27   // for hardware SPI sclk pin (all of available pins)

#define USER_SETUP_LOADED
#include <TFT_eSPI.h>
TFT_eSPI tft = TFT_eSPI();

results is this : error: 'TFT_WIDTH' was not declared in this scope

As I'm working on different projects with different models of TFT displays, editing and re-editing User_Setup_Select.h on every driver update or project change isn't a satisfying option and leaves only two solutions:

1) duplicate the library inside every project folder (and lose maintainability / updates) 2) choose an alternate driver

M5Stack chose solution 1) and the result is as unmaintainable as it's ugly.

Obviously I won't choose solution 1) or 2) since I'm posting here, so I'm wondering if there is a clean way to achieve this ?

Pablo2048 commented 5 years ago

I'm using Platformio. Every project has its own platformi.ini file in which You can do things something like

build_flags =
  -DST7789_DRIVER
  -DTFT_WIDTH=240
...

maybe it helps...

Bodmer commented 5 years ago

I understand the issue and this has been raised a few times in #29, #67, #97, #240. It is due to a limitation imposed by the Arduino IDE to avoid #define conflicts in sketch and library.

The main advantage of the approach taken is that the examples all run without modification once the setup is defined. As I have at least 12 different display hardware test setups it would mean I need 12 copies of each example sketch or edit every sketch to test with each hardware setup...

So for me all that needs to be done to change hardware setups is add // and remove // in a couple of lines in the User_Setup_Select.h file which is very quick and easy. I also write the correct setup file number on each board configuration for easy reference. Other library examples such as those with Dark Sky weather, THTShape, or TFT_eFEX also run without modification.

You can define your own setup in the folder User Setups, see comments in the setup files. As User_Setup_Select.h uses a files path to the setup file you can add your own folder and save setups there. It is best to make a copy of your setup files and folder before updating the library.

As noted above if you migrate to the PlatformIO IDE you can define the setup as part of your project.

If you find an easier solution for this then do let me know.

tobozo commented 5 years ago

@Pablo2048 @Bodmer thanks both for the prompt reply and duly noted the Arduino IDE is the limitative factor.

I'll keep on looking for a way to achieve this and post updates on this thread. The closest solution I can think of is doing like U8G2 by providing per-device constructors that accept different pinouts, or means to add such constructors from outside the library.

BTW I'm on a ST7789 model (from this build) that seems to behave differently from the defaults, I'll submit a PR as soon as I've reached the plateau of stability and I'm wondering what name I should give to the new files.

Would "ST7789-Dstike" fit for this particular model ?

tobozo commented 5 years ago

followup: pulled my hair out trying to play with #defines and #includes but gave up after a couple of hours because implementing a new driver is much faster :D

I made a PR for this ST7789 variant so I can close this issue, thanks again for your help !

mensink commented 5 years ago

I'm using Platformio. Every project has its own platformi.ini file in which You can do things something like

build_flags =
  -DST7789_DRIVER
  -DTFT_WIDTH=240
...

maybe it helps...

This worked for me. The trick is to make sure to define USER_SETUP_LOADED and then all the required settings from User_Setup.h, like this:

lib_deps =
  TFT_eSPI
build_flags =
  -DUSER_SETUP_LOADED
  -DILI9341_DRIVER
  -DTFT_CS=5
  -DTFT_DC=26
  -DTFT_RST=-1
  -DTFT_MISO=19
  -DTFT_MOSI=23
  -DTFT_SCLK=18
  -DLOAD_GLCD
  -DLOAD_FONT2
  -DLOAD_FONT4
  -DLOAD_FONT6
  -DLOAD_FONT7
  -DLOAD_FONT8
  -DSMOOTH_FONT
  -DSPI_FREQUENCY=27000000
  -DSPI_READ_FREQUENCY=20000000
  -DSPI_TOUCH_FREQUENCY=2500000
tobozo commented 5 years ago

oh I wish Arduino IDE supported build flags overloading 😭

u48 commented 3 years ago

Hello and thanks.

I have the same problem, many different boards, with displays on different pins ... Moreover, for some reason, it is required that projects are built on Arduino. :)

As a lesser evil, I make copies of the library under different names. TFT_eSPI_TTGO_T4_V13 / TFT_eSPI_TTGO_T4_V13.h TFT_eSPI_TTGO_T4_V11 / TFT_eSPI_TTGO_T4_V11.h TFT_eSPI_SPECTRUM / TFT_eSPI_SPECTRUM.h TFT_eSPI_smarton86b / TFT_eSPI_smarton86b .h ... Include paths also edited in the TFT_eSPI * files.

As a result, instead of #include in the project I write taking into account the board, for example #include

This is not graceful, but the library remains a library, when you change the board in the project, only one line changes, which suits. And I not see reason in updating the library version that works with a specific board. Although.. and manual renaming is not long and not often.

nikthefix commented 2 years ago

One way I tried to deal with this was to run a 'find and replace' script for the contents of user_setup using winautomation. Each time I switched board / display combination I just ran the script (compiled to .exe) and it was tolerant of updates for as long as I did it this way. Now I just use multiple portable instances of the whole Arduino setup - one instance per hardware config. Inefficient but safe and no repeat editing of libraries or board manager settings. Especially useful if you want to use a dev branch as well as a master branch of a lib when experimenting.