Arduino TFT libraries compatibility

ChrisMicro
Posts: 308
Joined: Fri Mar 24, 2017 4:51 pm
Location: Germany

Arduino TFT libraries compatibility

Post by ChrisMicro » Wed Jun 21, 2017 12:02 pm

Hello together,

because I like to use Arduino programs on different platforms I realized a problem: Many examples are written for the ILI9341 TFT. But sometimes I use the F746 disco or F429 disco and sometimes a BluePill with a ILI9341.

But the most of the time there are different names for the same functionality so the code has to be rewritten.
Why not having one interface for all this displays?

Even on the Arduino site for the TFT library itself they make this software design errors:

Code: Select all

#include <TFT.h> // Hardware-specific library
#include <SPI.h>
#include <Esplora.h>

void setup(){
  EsploraTFT.begin();  
  EsploraTFT.background(0,0,0);  // clear the screen with black
  delay(1000);  // pause for dramatic effect
}

void loop(){
  EsploraTFT.stroke(255, 0, 0); // set the stroke color to red
  EsploraTFT.line(0, 10, EsploraLCD.width(), 10); // draw a line across the screen
  delay(1000); 
Why naming the display EsploraTFT ? To make the code incompatible with other displays?

User avatar
zoomx
Posts: 526
Joined: Mon Apr 27, 2015 2:28 pm
Location: Mt.Etna, Italy

Re: Arduino TFT libraries compatibility

Post by zoomx » Wed Jun 21, 2017 12:18 pm

Unfortunately it happens also in other libraries.

But the Esplora let you to use the old commands

Code: Select all

The Arduino TFT library extends the Adafruit GFX, and Adafruit ST7735 libraries that it is based on.
.....
The library is backwards compatible, which means you can still use the Adafruit functions described here.

david.prentice
Posts: 112
Joined: Wed Nov 16, 2016 8:52 am

Re: Arduino TFT libraries compatibility

Post by david.prentice » Wed Jun 21, 2017 3:28 pm

The beauty of C++ is that you can inherit classes. e.g. many TFT, OLED, GLCD libraries inherit all the Adafruit_GFX methods which in turn inherit the Print methods.

So I can expect tft.println("Hello World") to work just like Serial.println("Hello World");
Or tft.drawRect(0, 10, 5, 20, WHITE) to work like any other drawRect()

As a matter of convention you might name the object tft whatever TFT controller library you are using.
Much like most 16x2 objects are called lcd.

It seems a little odd to call the object EsploraTFT but it looks as if it is from a "stroke" type of graphics class rather than an Adafruit_GFX class.

Yes, you do tend to get a few anomalies. e.g. some TFT libraries have begin(void) and some have begin(uint16_t ID)
But the bulk of a TFT graphics program will work on an SPI ST7735 or a parallel ILI9341 if the specific libraries share the GFX methods. i.e. you just need specific include and constructor.

David.

User avatar
RogerClark
Posts: 7177
Joined: Mon Apr 27, 2015 10:36 am
Location: Melbourne, Australia
Contact:

Re: Arduino TFT libraries compatibility

Post by RogerClark » Thu Jun 22, 2017 1:18 am

david.prentice wrote:
Wed Jun 21, 2017 3:28 pm
So I can expect tft.println("Hello World") to work just like Serial.println("Hello World");
Or tft.drawRect(0, 10, 5, 20, WHITE) to work like any other drawRect()
I doubt even if you always used libraries by the same company e.g. Adafruit, whether tft.println() would work the same across all their libs or whether it worked the same as Serial.println

From what I can tell, libs by the same company e.g. Adafruit are often written by different people and don't confirm to any style guide.

In my day job I use libs on various platforms from various sources, and they all behave differently

I think the only time you can expect the sort of coherence to a fixed API style and functionality is if you single source your SDK / API / Libs from one company as a commercial product e.g. All Apple iOS API's strongly follow a style, but this is a heavily funded commercial team.

ChrisMicro
Posts: 308
Joined: Fri Mar 24, 2017 4:51 pm
Location: Germany

Re: Arduino TFT libraries compatibility

Post by ChrisMicro » Thu Jun 22, 2017 10:01 am

I want to make an easy to use and simple GUI library which supports several TFT displays.
What interface technique would your recommend to attach the different drivers?

david.prentice
Posts: 112
Joined: Wed Nov 16, 2016 8:52 am

Re: Arduino TFT libraries compatibility

Post by david.prentice » Thu Jun 22, 2017 10:30 am

RogerClark wrote:
Thu Jun 22, 2017 1:18 am
david.prentice wrote:
Wed Jun 21, 2017 3:28 pm
So I can expect tft.println("Hello World") to work just like Serial.println("Hello World");
Or tft.drawRect(0, 10, 5, 20, WHITE) to work like any other drawRect()
I doubt even if you always used libraries by the same company e.g. Adafruit, whether tft.println() would work the same across all their libs or whether it worked the same as Serial.println

From what I can tell, libs by the same company e.g. Adafruit are often written by different people and don't confirm to any style guide.

In my day job I use libs on various platforms from various sources, and they all behave differently

I think the only time you can expect the sort of coherence to a fixed API style and functionality is if you single source your SDK / API / Libs from one company as a commercial product e.g. All Apple iOS API's strongly follow a style, but this is a heavily funded commercial team.
Rubbish. If one class inherits from Print.h it will inherit all the Print.h methods.
This is a feature of C++ and most OO languages.

Yes, the new class can implement new methods. It can even overwrite some of the inherited methods. But as a general rule, you extend methods or add new methods rather than change behaviour.

e.g. you might add tft.blueCircle(x, y, radius) to draw a circle in blue.
e.g. it is possible that you overwrite the existing tft.drawCircle(x, y, radius, color) method to draw triangles. But extremely unlikely.

Yes, I suppose that a disgruntled Apple ex-employee might try to change the style.

So libraries that inherit from Adafruit_GFX are easy to use by existing Arduino owners.
It makes life easier for the library author too.
But any library can invent any new class with any named methods that do not follow any logical pattern.

David.

User avatar
RogerClark
Posts: 7177
Joined: Mon Apr 27, 2015 10:36 am
Location: Melbourne, Australia
Contact:

Re: Arduino TFT libraries compatibility

Post by RogerClark » Thu Jun 22, 2017 11:57 am

I missunderstood your post

I thought you meant that all libraries that has a println function (should always implement it the same way)
Not just Adafruit libs that inherit from the same base class

david.prentice
Posts: 112
Joined: Wed Nov 16, 2016 8:52 am

Re: Arduino TFT libraries compatibility

Post by david.prentice » Thu Jun 22, 2017 12:57 pm

No problem!

Yes, I agree that println() is just a name. It does not necessarily mean inheritance of Print.h
But I maintain that most library authors would attempt to mimic the behaviour even if they implement without inheritance.

e.g. MarekB and Bodmer implement their own Graphics methods that behave identically to the Adafruit_GFX methods.

Somehow, println() is very likely to behave like Print.h
I suspect that print() is less likely to conform.

David.

danieleff
Posts: 336
Joined: Thu Sep 01, 2016 8:52 pm
Location: Hungary
Contact:

Re: Arduino TFT libraries compatibility

Post by danieleff » Thu Jun 22, 2017 2:59 pm

Whats wrong with

Code: Select all

class GUI {
  public:
    GUI(Adafruit_GFX &gfx): gfx(gfx) {};
    Adafruit_GFX &gfx;
    
    void button() {
        gfx.drawPixel(...);
    }
};

//Use as:
Adafruit_ILI9341 tft(); // or other display
GUI(tft);
Or templated class, and hope that the display class has the same `drawPixel()` etc...
Otherwise create your own drawing API, and write a driver for every display.

Or google more, maybe there is one. For example it would be cool to have a (partial) SDL implementation, lots of stuff is written on that.

ChrisMicro
Posts: 308
Joined: Fri Mar 24, 2017 4:51 pm
Location: Germany

Re: Arduino TFT libraries compatibility

Post by ChrisMicro » Fri Jun 23, 2017 5:18 am

I try this with your F746 TFT implementation but it seems not to be a derivative of the Adafruit_GFX.
So I would have to rewrite it to

Code: Select all

class GuiPittixObject {
  public:
    GuiPittixObject( LTDC_F746_Discovery &gfx ): gfx(gfx)
    {
    };
  private:  
    LTDC_F746_Discovery &gfx;
};

LTDC_F746_Discovery tft;
GuiPittixObject myObject(tft);
which makes it incompatible to the others. What do you suggest?

Post Reply