Arduino Esplora TFT LCD (160x128) screen pixels do not match resolution (solved)

Using Arduino Displays
#1

Hey guys,

I'm doing my second project ever regarding programming, although I can say that I know the basics by now. I have recently bought an Arduino Esplora and a 160x128 TFT LCD shield that fits right on top. When I plug everything in, including the screen, everything seems to work: lights blink and the screen goes white. However, when I try one of the examples of the Arduino Esplora, not the whole screen is being used.

It looks like 2 rows at the bottom and one on the right side are not being used and they produce some kind of graphical noise - like those old TVs when the signal was lost - but of course the rows are not being refreshed and therefore produce a stationary image. This noise was not produced when the screen was plain white. The actual noise varies from time to time: sometimes all these rows are all noise, sometimes only parts of it. (on the images, it just looks white because of lighting issues and is only situated in the bottom left corner)

I have investigated this problem myself by letting the Esplora set dots from (0,0) to (9,9) in a diagonal line, so I could deduce the physical starting point. That was, and you probably guessed it already, 2 rows above and 1 row to the left of my actual screen.

(the regular add image option wouldn't work)

So the problem is: the resolution of my screen does not start at the same place as where my actual pixels start, and because of that, my images do not fit the screen correctly.

I used both the TFT and SPI library to make it run and also added the Esplora library to see if it would work that way, but I had the same problem both ways.

Do you guys have any idea how I could (manually) adjust the resolution to fit my screen?

#2

Milangelo:
Hey guys,

I'm doing my second project ever regarding programming, although I can say that I know the basics by now. I have recently bought an Arduino Esplora and a 160x128 TFT LCD shield that fits right on top. When I plug everything in, including the screen, everything seems to work: lights blink and the screen goes white. However, when I try one of the examples of the Arduino Esplora, not the whole screen is being used.

It looks like 2 rows at the bottom and one on the right side are not being used and they produce some kind of graphical noise - like those old TVs when the signal was lost - but of course the rows are not being refreshed and therefore produce a stationary image. This noise was not produced when the screen was plain white. The actual noise varies from time to time: sometimes all these rows are all noise, sometimes only parts of it. (on the images, it just looks white because of lighting issues and is only situated in the bottom left corner)

I have investigated this problem myself by letting the Esplora set dots from (0,0) to (9,9) in a diagonal line, so I could deduce the physical starting point. That was, and you probably guessed it already, 2 rows above and 1 row to the left of my actual screen.

20171130 210626 — ImgBB

20171130 210632 — ImgBB

(the regular add image option wouldn't work)

So the problem is: the resolution of my screen does not start at the same place as where my actual pixels start, and because of that, my images do not fit the screen correctly.

I used both the TFT and SPI library to make it run and also added the Esplora library to see if it would work that way, but I had the same problem both ways.

Do you guys have any idea how I could (manually) adjust the resolution to fit my screen?

i have the Esplora and the TFT LCD screen for it. It is the same screen that is used in the Arduino Robot.

Which operating system are you using? Linux, MacOSX or Windows.
Which version are Arduino IDE?
Are the libraries up-to-date?

Which sketches have you run on the Esplora?

Have you run the Etch-o-sketch sketch?

examples/Esplora/EsploraTFTEtchASketch/EsploraTFTEtchASketch.ino

#3

artisticforge:
i have the Esplora and the TFT LCD screen for it. It is the same screen that is used in the Arduino Robot.

Which operating system are you using? Linux, MacOSX or Windows.
Which version are Arduino IDE?
Are the libraries up-to-date?

Which sketches have you run on the Esplora?

Have you run the Etch-o-sketch sketch?

examples/Esplora/EsploraTFTEtchASketch/EsploraTFTEtchASketch.ino

I was running version 1.8.1 of the Arduino IDE on Windows, but after reading your comment, I tried using the newest version - 1.8.5 - as well. That didn't work either.

The TFT library is version 1.0.5, the SPI library is version 1.0.0 and the Esplora library is version 1.0.4. None of them mention a newer version being available, at least within the IDE. I don't know where to check the newest versions of these libraries, as the Arduino website doesn't really mention them (initially, on my first quick check of the website).

I ran multiple example sketches and they all feature my problem mentioned above. And as I said earlier, I tried to figure out the exact location of where the 'programmable pixels' start by creating my own sketch, which also had the same problem.

I have run the Etch-a-sketch example as well. All the coding seems to work as it should, but once again those same rows of pixels are not being included. If I pull the cursor all the way to the left or top, it disappears from the screen and thus, I speculate, draws lines on the 'programmable pixels' but not on the actual pixels, as they do not correspond to each other.

#4

Milangelo:

I have run the Etch-a-sketch example as well. All the coding seems to work as it should, but once again those same rows of pixels are not being included. If I pull the cursor all the way to the left or top, it disappears from the screen and thus, I speculate, draws lines on the ‘programmable pixels’ but not on the actual pixels, as they do not correspond to each other.

I think at this point it is safe to assume that the LCD display is bad or at least has bad pixels.
I have never seen this issue with either of the displays that I have. I have one on the Esplora and one on the Arduino Robot.

If there is an Arduino User Group in your area, see if someone has an extra one to try. Ask someone there to test the one that you have. Contact the retailer were you purchased it and see if they will exchange it.

#5

@Milangelo

The problem you have is because you have been given a display a built in offset, this is not uncommon from eBay suppliers. If you have a genuine Arduino product then I am surprised they have released the Esplora with a TFT display fitted that is not compatible with the stock TFT library...

The library can cope with your problem display and correct the offset but it will be necessary to edit the library.

I suggest you contact your Esplora supplier, explain the problem and ask them to supply instructions on how to change the library or ask them for another display that does not have the offset and works with the stock IDE TFT library.

#6

I have worked around my issue with the display in a fashion that I didn't think possible with my lack of knowledge. So, the following is for people who experience the same problem or are just interested in the matter (conclusion at the bottom):

After searching for many, many different ways of describing my problem on Google, I came across this page on the Arduino forums of someone who had a completely different issue. However, Google found some text embedded in some code posted on that particular page (1.8" 128x160 SPI TFT LCD Display white screen - Displays - Arduino Forum), which had nothing to do with that problem, but was helpful for me:

// Our supplier changed the 1.8" display slightly after Jan 10, 2012
// so that the alignment of the TFT had to be shifted by a few pixels
// this just means the init code is slightly different. Check the
// color of the tab to see which init code to try. If the display is
// cut off or has extra 'random' pixels on the top & left, try the
// other option!

Now I don't have this particular display, but the description of the problem showed similarities to mine. And there was some sort of solution there as well. However, being the n00b I am, I understood next to nothing. I did give me the insight though, that I should try to make a workaround within the libraries that I will use in my programs. This way, I don't have to add extra code within the programs to shift the dimensions, and I can also download other programs and run them just fine with my altered libraries.

To make sure my display wasn't actually defect, I first looked for the option to broaden the resolution specifications, so I could see the pixels work. Instead of the usual 160x128 resolution, I compensated for the deviation with a resolution of 161x130: now all the pixels lit up as they should: no defect.

However, this solution would mean constantly accounting for a weird resolution which would make developing programs much more difficult than needed, since I would have to constantly remind myself of that odd resolution. Plus, there would always be extra columns and rows that recieved some computing, which would limit the speed of the Arduino. So I looked further in the libraries to find the place where the (0,0)-coordinates were defined.

The problem wasn't actually a problem within the files, so I suspect that there is indeed an alignment issue with my display. But I found the code within it, which I changed so that the starting point of the drawing shifted. After looking through all the libraries within the TFT folder (meaning: the TFT library, AdafruitGFX library and Adafruit ST7735 library) and trying to understand as much as I could, I found the location: within the Adafruit_ST7735.cpp file, there is code of the 'Adafruit_ST7735::commonInit(...)' function. This function defines the value of 'colstart' and 'rowstart' as 0. I changed it to correspond with my deviation.

I then of course set the resolution to default, because I don't want to have extra rows and columns on the other side of the display either.

Everything now works as it should have done in the first place.

After multiple hours of work, the description of the problem in the quote above seems very logical to me as how to solve it, but I like how I kind of figured it out by myself as well, knowing very little of programming languages.

Conclusion:
1: Changing the resolution
A TFT display resolution can be configured within Adafruit_ST7735.cpp within the Gcmd array within the Adafruit_ST7735::writecommand(...) function. The other arrays in that function can also be configured, but TFT.cpp specifically states that a TFT display is configured according to the Gcmd array. I don't remember if it is necessary, or if I just added the following because I changed, tried and errored so much, but I also added the corresponding values to the '_width' and '_height' within the TFT.cpp file.
2: Changing the origin
The origin of a TFT display can be configured within Adafruit_ST7735.cpp within the 'Adafruit_ST7735::commonInit(...)' function. Changing the values of 'colstart' and 'rowstart' will change the row and column of the origin. By standard, they are both defined as 0 (-> colstart = rowstart = 0;), but writing them as two different definitions makes it possible to set a virtual origin, relative to the misaligned origin of the display.

#7

bodmer:
@Milangelo

The problem you have is because you have been given a display a built in offset, this is not uncommon from eBay suppliers. If you have a genuine Arduino product then I am surprised they have released the Esplora with a TFT display fitted that is not compatible with the stock TFT library...

The library can cope with your problem display and correct the offset but it will be necessary to edit the library.

I suggest you contact your Esplora supplier, explain the problem and ask them to supply instructions on how to change the library or ask them for another display that does not have the offset and works with the stock IDE TFT library.

Thank you very much, bodmer, for the reply!

Just as your comment came in, I posted my solution to the problem and they match exactly ;). Would I have seen your reply earlier, then I could have been saved from a lot of checking, reading and figuring things out. But I believe that doing this has made me a smarter man :P.

Thanks again!

#8

I've found what I think is a slightly better solution.

In libraries/TFT/src/TFT.cpp the EsploraTFT instance is defined, and the definition is surrounded by a preprocessor directive -

#if ARDUINO_AVR_ESPLORA
TFT EsploraTFT(7, 0, 1);
#endif

So if we change the void TFT::begin() implementation a few lines further down we can add the correct initialisation for the TFT display -

void TFT::begin() {
//  initR(INITR_REDTAB);
#if ARDUINO_AVR_ESPLORA
 initR(INITR_GREENTAB);
#else
 initG();
#endif
 setRotation(1);
}

The implementation of initR is in libraries/TFT/src/utility/Adafruit_ST7735.cpp, and it seems that the good folks at Adafruit were aware that some TFT screens have a different origin. However, on my screen, they seem to have that origin incorrect. The origin they programmed in was at (1,2), whereas my origin is at (2,1). The c preprocessor comes to our rescue again -

#ifdef ARDUINO_AVR_ESPLORA
   colstart = 1;
   rowstart = 2;
#else
   colstart = 2;
   rowstart = 1;
#endif
#9

Hi!

I had the same issue with a TFT 1.8" Adafruit display I acquired at the end of 2011. I was able to correct the issue by doing the following:

  • Got the latest Adafruit libraries. ST7735 (1.4.2) and TFT (1.0.6)
  • I opened ~/Documents/Arduino/libraries/Adafruit_ST7735_and_ST7789_Library/Adafruit_ST7735.cpp
  • I located this line after a big if statement: displayInit(Rcmd3);
  • Finally, I added a line right before so it looks like this.
    setColRowStart(2, 1); // toani
   displayInit(Rcmd3);

I hope this helps.

#10