Go Down

Topic: Graphics library for NodeMCU (ESP8266), ESP32 and serial+parallel TFT displays (Read 95583 times) previous topic - next topic

Stan_S

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

bodmer

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.

Stan_S

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

bodmer

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.

ZinggJM

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?

Code: [Select]
#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
No personal message please; any question may be useful for other users. Use code tags for code. Make links clickable with URL tags. Provide links to the product in question.

bodmer

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...

Stan_S

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


ZinggJM

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
No personal message please; any question may be useful for other users. Use code tags for code. Make links clickable with URL tags. Provide links to the product in question.

bodmer

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  :)

bodmer

Hi Stan,

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

Code: [Select]
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).

bodmer

Ah hah!  This is the format needed:

Code: [Select]
const String WUNDERGRROUND_LANGUAGE = "EN";
const String WUNDERGROUND_COUNTRY = "US";
const String WUNDERGROUND_CITY = "FL/Boca_Raton";

Stan_S

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

bodmer

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?

bodmer

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).

bodmer

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.

Go Up