Recommendation: move screen/pin definition in common files

[marcmerlin]

(feel free to close this issue after you've read it, there is a suggestion, plus some pointers to my own work that may be useful to you)

The examples you give are really good, but the many many ways to define the screens, is very long because there are so many options (and for good reason).
Have you considered factoring that out into a common file?

For instance, see:

• https://github.com/marcmerlin/tft-playground/blob/master/tft_pins.h => this is compatible with you, adafruit libs, and other libs
• https://github.com/marcmerlin/tft-playground/blob/master/arduinogfx.h => those are definitions just for your lib

Then you can have the adafruit example like this: https://github.com/marcmerlin/tft-playground/tree/master/ili3941graphicstest
And your example code like that: https://github.com/marcmerlin/tft-playground/tree/master/PDQgraphicstest

This makes it easy to change the pin and screen in one place and all the demos are updated at the same time.

And if you have a little time, please look at
https://github.com/marcmerlin/FastLED_NeoMatrix_SmartMatrix_LEDMatrix_GFX_Demos
especially https://github.com/marcmerlin/FastLED_NeoMatrix_SmartMatrix_LEDMatrix_GFX_Demos/blob/master/neomatrix_config.h
neomatrix_config solves a similar problem to yours: a single config file that contains 2D hardware definition and then all the demos source that file and work automatically.

Currently I support a few TFTs from adafruit lib, but I will add support for your driver because your driver is better :)

If you are curious, I support a lot of different hardware, including RGBPanels and neopixel matrices, see my base class:
https://github.com/marcmerlin/Framebuffer_GFX

The only issue is that my base class is RGB888, which is a bit wasteful for TFTs that are RGB565. For 320x240, the framebuffer is 224KB which is too big on an ESP32 without PSRAM

[moononournation]

I know it become a little bit clumsy when I add more and more driver on it. In my previous using other display library experience, Ucglib is most straightforward to let me configured to what I want and test the examples. So I followed its style. I am considering only keep this style in only one example and comment in other example refer to it. 「Marc MERLIN <notifications@github.com>」在 2021年2月13日週六，14:16 寫道：

…

(feel free to close this issue after you've read it, there is a suggestion, plus some pointers to my own work that may be useful to you) The examples you give are really good, but the many many ways to define the screens, is very long because there are so many options (and for good reason). Have you considered factoring that out into a common file? For instance, see: - https://github.com/marcmerlin/tft-playground/blob/master/tft_pins.h => this is compatible with you, adafruit libs, and other libs - https://github.com/marcmerlin/tft-playground/blob/master/arduinogfx.h => those are definitions just for your lib Then you can have the adafruit example like this: https://github.com/marcmerlin/tft-playground/tree/master/ili3941graphicstest And your example code like that: https://github.com/marcmerlin/tft-playground/tree/master/PDQgraphicstest This makes it easy to change the pin and screen in one place and all the demos are updated at the same time. And if you have a little time, please look at https://github.com/marcmerlin/FastLED_NeoMatrix_SmartMatrix_LEDMatrix_GFX_Demos especially https://github.com/marcmerlin/FastLED_NeoMatrix_SmartMatrix_LEDMatrix_GFX_Demos/blob/master/neomatrix_config.h neomatrix_config solves a similar problem to yours: a single config file that contains 2D hardware definition and then all the demos source that file and work automatically. Currently I support a few TFTs from adafruit lib, but I will add support for your driver because your driver is better :) If you are curious, I support a lot of different hardware, including RGBPanels and neopixel matrices, see my base class: https://github.com/marcmerlin/Framebuffer_GFX The only issue is that my base class is RGB888, which is a bit wasteful for TFTs that are RGB565. For 320x240, the framebuffer is 224KB which is too big on an ESP32 without PSRAM — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#24>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ADE5WWZDPXNWRW4U7V7EORDS6YKNRANCNFSM4XR2NU3Q> .

[marcmerlin]

thanks for your reply, it's just a suggestion since I went through the same thing than you with my set of 2D libraries. Having a file with definitions that you can include, makes things easier in my opinion, but you can decide what's best for you.
I will add support for your library in mine, and will contact you when I'm done. This will allow a lot of FastLED and LEDMatrix code to work on top of your libraries
Something like this: http://marc.merlins.org/perso/arduino/post_2019-05-26_FastLED_SPITFT_GFX-on-top-of-Framebuffer_GFX-for-SPI-TFTs-like-SSD1331-or-ILI9341.html

[moononournation]

Another alternative is build a Wiki for Arduino_GFX and simple drop a link in code comment.

[marcmerlin]

That works too. I'll leave it up to you, it's your library and your choice ;)

[moononournation]

Just commit the changes, only PDQgraphicstest.ino keep the long version. Is it good enough?

[marcmerlin]

I think that helps the other examples, yes. Thank you for that.

Now, if it were me (and what I did in my lib) is to use an include file where the screen is defined
You could have
https://github.com/moononournation/Arduino_GFX/tree/master/examples/arduinogfx.h
and move the TFT definition there.
Then, all examples include the file.

After that when I use your library, I only have to edit arduinogfx.h , and all the demos would work.
Then if I change my TFT for another kind, again, I only change arduinogfx.h once, and all the code works.
How does that sound?

[moononournation]

Arduino IDE not show header files at parent folder, user cannot read that file easily. And also when you start a new project from save as an example, the header files at parent folder will not copy to new project folder and that is not easy to fix for beginner.

[marcmerlin]

Thanks for letting me know. So, in my library, I cheat: I use symlinks
#include "config.h"
and
config.h is a symlink to ../config.h which is shared by all the demos.

It works great on linux and MacOS, but not on windows which does not support symlinks :(

I really wish there was a simple solution to this need that works for everyone, your library and mine have the same exact need.

[marcmerlin]

I posted the question here, maybe we'll get a good suggestion: https://forum.arduino.cc/index.php?topic=731975

[marcmerlin]

the answers I got, were

1. symlinks (like i do), but they don't work on windows, so not great
2. have the definition file be inside the library directory, that way you can include "arduinogfx_config.h" and the arduino manager will automatically find the file inside your library directory.

I'm not sure if you like option #2 , I'll let you decide.