Graphics library for NodeMCU (ESP8266), ESP32 and serial+parallel TFT displays

Hi, I got it working, I just need to figure out the proper settings for my city. I set it for UK and london and it works fine. it looks great!! You are a genius.

I loaded the eye sketch and it looks interesting as well.

I need to do a clean install of the IDE on my desktop that is my next project. Then I would like to work on the plane spotter.

I have a couple more of the 2.8" displays coming as well as a couple more of the esp chips with the better usb driver. The power & technology in these things for under $4.00 is amazing.

I attached a photo of the finished clock.

Thanks for all your patience and help. It is greatly apriciated. Regards, Stan

Great to hear it is working.

All the hard coding work was done by Daniel Eichhorn, see here. I just tweaked it, tidied up the formatting, added the wind speed and weeded out some bugs.

The Wunderground City list is here , most big cities are probable there for the UK.

Hi, My problem ids getting it to find my city. I think for the US you need a state as well. I tried adding a state identifier in the settings.h file but have not been successful so far. I will keep plugging away at it.

I tried Daniels projects but was not able to get them to compile. Your code works.

I need to clean out my IDE and start fresh on my desktop, I think there is to much junk in it and it is giving me problems.

Regards, Stan

The TFT_ILI9341_ESP library has morphed into a new library called TFT_eSPI on Github. This new version carries over all the features of the TFT_ILI9341_ESP library and is compatible with the Espressif ESP8266 and SPI based TFT displays. At the moment the supported display drivers are ILI9341 and ST7735. New display drivers will be added periodically.

This new library absorbs all the functions present in the TFT_ILI9341_ESP library, thus the TFT_ILI9341_ESP library will no longer be developed further. Potential users will be pointed towards the new TFT_eSPI library.

The old TFT_ILI9341_ESP library will remain on Github to support legacy projects.

The new TFT_eSPI library is extensible to support other display drivers, this is something I have been meaning to do for some time. It also supports multiple "User_Setup" files for different hardware setups (different pins used, different display driver etc). Selection of which setup to use is via a simple "User_Setup_Selection.h" file. This allows the same example/user sketches to be used for different hardware configurations, with no need to edit the sketch (providing the display resolution is compatible).

If any bugs are found then the best place to report them is via the Github "Issues" form, but I will respond to messages on this thread too.

Hi Bodmer,

Thank you for this new version and all your work that I and we all use, like and depend on.

My display classes are derived from TFT_HX8357, TFT_HX8357_Due and TFT_ILI9341_ESP.

My current work is still based on these, but uses a new design to separate the display class from the IO class. This makes it slightly less performing, but makes enhancements easier.

May I propose you take a look at this idea?

#include "Arduino.h"

class GxIO
{
  public:
    GxIO(){};
    virtual void reset();
    virtual void init();
    virtual void writeCommandTransaction(uint8_t c);
    virtual void writeDataTransaction(uint8_t d);
    virtual void writeData16Transaction(uint16_t d);
    virtual void writeData16Transaction(uint16_t d, uint32_t num);
    virtual void writeCommand(uint8_t c);
    virtual void writeData(uint8_t d);
    virtual void writeData16(uint16_t d);
    virtual void writeData16(uint16_t d, uint32_t num);
    virtual void writeData2x8(uint16_t d);
    virtual void startTransaction();
    virtual void endTransaction();
    virtual void setBackLight(bool lit);
  protected:
    int8_t _cs, _rs, _rst, _wr, _rd, _bl; // Control lines
};

#if defined(ARDUINO_ARCH_SAM)

class GxIO_TikyOnDue : public GxIO
{
  public:
    GxIO_TikyOnDue();
    void reset();
    void init();
    void writeCommandTransaction(uint8_t c);
    void writeDataTransaction(uint8_t d);
    void writeData16Transaction(uint16_t d);
    void writeData16Transaction(uint16_t d, uint32_t num);
    void writeCommand(uint8_t c);
    void writeData(uint8_t d);
    void writeData16(uint16_t d);
    void writeData16(uint16_t d, uint32_t num);
    void writeData2x8(uint16_t d);
    void startTransaction();
    void endTransaction();
    void setBackLight(bool lit);
  private:
    void strobe();
    void strobes(uint32_t num);
};

class GxIO_HVGAOnDue : public GxIO
{
  public:
    GxIO_HVGAOnDue();
    void reset();
    void init();
    void writeCommandTransaction(uint8_t c);
    void writeDataTransaction(uint8_t d);
    void writeData16Transaction(uint16_t d);
    void writeData16Transaction(uint16_t d, uint32_t num);
    void writeCommand(uint8_t c);
    void writeData(uint8_t d);
    void writeData16(uint16_t d);
    void writeData16(uint16_t d, uint32_t num);
    void writeData2x8(uint16_t d);
    void startTransaction();
    void endTransaction();
    void setBackLight(bool lit);
  private:
    void strobe();
    void strobes(uint32_t num);
};

#endif

You will notice it is influenced by both TFT_HX8357 and SPI.

kind regards

Jean-Marc Zingg

Hi Jean-Marc,

Thanks for you input. There is certainly scope for improving the way extensions could be added to the library

The original set of libraries were targeted at specific displays and processors to try and squeeze the best performance out of each component combination. The ESP8266 has changed the game somewhat as it has a much higher performance compared to an UNO so optimisation is less critical (but still nice to have).

Ideally it would be nice to have different displays classes and processor IO classes all sat on top of the graphics class but at the moment that is a step too far for my coding skills. I like the breakdown you have listed and it will reduce the number of undesirable #ifdef's in the code.

The new library was pulled together in one evening to start moving in the direction you suggest and help get one of my projects going. The library will probably evolve in the direction you suggest but this will occur at a future time and will be transparent at the user sketch level interface to the library.

Thanks, you have given me "food for thought" and that is helpful, I will think on this further...

Hi, I still can't get the weather sketch to get data for my city. I think that the problem is that for the US you need to identify the state as well as the city. I have tried adding this line to the setup.h file:

const String WUNDERGROUND_COUNTRY = "US"; const String WUNDERGROUND_STATE = "Fl"; const String WUNDERGROUND_CITY = "Boca Raton";

And added state to these lines in the sketch #259, 263, 267 wunderground.updateConditions(WUNDERGRROUND_API_KEY, WUNDERGRROUND_LANGUAGE, WUNDERGROUND_COUNTRY , WUNDERGROUND_STATE, WUNDERGROUND_CITY);

When I try to compile it it creates errors in the Wundergroundclient.h file that I can't seem to fix.

Do you have any suggestions on what to do?

The sKetch works fine calling up cities in the UK.

Also it seems the problems I was having before were from this sketch conflicting with the SD card library's

bodmer: Thanks, you have given me "food for thought" and that is helpful, I will think on this further...

Thank you for looking at my design idea.

I am still on a steep learning curve for displays usable with Arduinos.

May I present some more thoughts about my design idea:

Displays usable with Arduinos have four mayor aspects or properties: - display dimensions in pixels, - color depth (or color/bw), - controller used, - io connection or method.

For color TFTs my design handles the 3 "dimensions" the following way: - display dimensions are parameters of the display class constructor, - controller is an enum, and passed as parameter to the init method, - io is handled by subclassing a general io base class, and passing a reference to the chosen instance as parameter to the display class constructor.

With this io sublassing approach, a wide range of io connections and methods can be handled. The SPI connection is one of them, maybe the most general, so it could be handled in the base class.

As my display class is "work in progress", this is the third approach, I refrain from posting a preliminary version.

Jean-Marc

Hi Jean-Marc,

OK, all good stuff. Attached is a view on what the library pipeline structure could look like when/if completed.

As summer approaches the weather improves and much less time is spent tinkering with software so perhaps this is next winters project :slight_smile:

Graphics library 2.pdf (18.8 KB)

Hi Stan,

As far as I can tell the sketch should accept the following:

const String WUNDERGROUND_COUNTRY = "FL US";
const String WUNDERGROUND_CITY = "Boca Raton";

However it seems the sketch does not handle or send spaces correctly if they are either in the country command string or in the city name. I guess I have been lucky that these rules do not apply and similarly for the original author of the sketch who lives near Zurich.

I will investigate further and see if I can fix this bug. I note that Adafruit produced a variant of the weather station sketch so I will look to see if they fixed it (as Adafruit are based in the USA too).

Ah hah! This is the format needed:

const String WUNDERGRROUND_LANGUAGE = "EN";
const String WUNDERGROUND_COUNTRY = "US";
const String WUNDERGROUND_CITY = "FL/Boca_Raton";

Hi, I found that at Adafruit yesterday and tried it but it doesn't work. I have spent several hours trying to get this working but success still eludes me.

Regards, Stan

Hi Stan,

I tested the exact setup in post #70 and it worked fine so I am at a loss as to what to suggest other than the following:

The forward sloping slash / is important (don't use back slash \ ) and spaces in the city name must be replaced with the underscore _ character, (not a - sign).

Does it still work for the UK?

In the Github respository all the library examples have been tested and updated to remove legacy text etc.

A new “weather station” example has been added, see this post, this requires 3Mbytes of FLASH set aside for SPIFFS as the sketch will use a WiFi connection to download the required images (weather icons, Moon phase images etc) from the internet and a total of more than 1 Mbyte of image files will be saved. That sketch also needs some other libraries including the JPEGDecoder.

The “uncannyEyes” example runs on a display of either type (ILI9341 or ST7735), the others are tailored for a particular display resolution (160 x 128 for ST7735 and 320 x 240 for ILI9341).

Two more drivers have been added, the library now supports the ILI9341, ILI9163, ST7735 and S6D02A1 based TFT displays with an SPI interface.

Supporting higher resolution Raspberry Pi targeted serial interface displays is planned, but adding those is not so easy and will take some time.

Hi,
I finally got this to work. My mistake was so stupid it is painful. When I put in my API key, I didn’t delete the < & > in the quotes. After removing them it worked. I found the information on Adafruits web page a couple of days ago and tried it, but it didn’t work. I went back today and compared their input to mine & realized the mistake with the API Key.
Thank you for all your help with this , I can’t thank you enough.
Best Regards,
Stan

The TFT_eSPI library has been updated to add a screen shot viewer client called "Screenshot_client" in the Tools folder. This is a Processing sketch and it runs under Processing 3.3.

Processing is an image processing tool that has an Ardiono-like IDE. The Processing sketch can be changed to suit your own preferences.

There is also a new companion sketch called "TFT_Screen_Capture" compatible with the ILI9341 display that acts as a screenshot server and can be uploaded to an ESP8266 with connected display. This example draws colourful graphics on the screen and then sends a screen screenshot image pulled off the TFT to the Processing client. It takes about 3.5s to send a 240 x 320 RGB image to the PC at 921600 baud (theoretical minimum is ~2.5s).

Each screenshot is saved automatically as sequentially numbered "png" images. Other image formats are supported (e.g. jpg,tif, bmp) by commenting/uncommenting lines in the processing sketch.

At the moment the Processing screen capture client uses the serial port, another version that runs over a Wifi network connection is also in development, this promises much faster screen grabs.

Have fun, report any bugs/suggestions here.

A couple of links to test images grabbed off the ILI9341 TFT screen, 5 pixel back border added by Processing client, png format:

Hi, you have been really hard at work with this, the processing looks interesting. I am watching the videos.

I found this video on youtube, it gets weather from a noaa site: https://www.youtube.com/watch?v=gCJHwWqE9c0

Regards, Stan

Thanks for the link Stan, it is another interesting project!