TFT Text Over Image

[cjbaar]

I purchased the 2.2 TFT display (using HX8340BN driver). While these are a lot of fun to play with, what I'd really like to do is have changing text over a constant background... without re-drawing the entire background image every time, as this takes several seconds.

In other words:
1) load background image (easily done)
2) write text over the image (easily done)
3) erase or re-write that text, with the background still intact (not so easy)

Since these displays use their own pixel buffer, my arduino doesn't have access to the data to put it back in place. Can the driver chip for this display handle this? Can the driver for any of the TFT screens sold by ada accomplish this?

I don't know of any way to this in the microcontroller, because I don't have near enough RAM to store an entire background image. Any help is appreciated!

[tldr]

is the image going to come off the micro sd?

can you redraw the affected portions of the screen from there?

if the image is not coming from the micro sd, could you just buffer it there?

might be simpler to go with image over text

[cjbaar]

Thanks, tldr; that sounds reasonably simple. My brain had completely ignored that route.

Yes; the image is coming from an SD card at the moment. I was concerned about how to buffer the data at the time I overwrite it. But, since I already know where the image data is, I can re-read it. I guess I have to brush up on the SD library to figure out how to seek to where I need in the files.

It would be nice if the display could buffer all of the data, and then "latch" it all at once, so that you don't see the image being drawn across the screen... but I don't think these work that way.

[cjbaar]

OK... well with some minor modifications to the ada library (less than I imagined, actually), I am able to easily pull a section of the image to be re-written. However, it's still fairly slow. Even re-drawing a 36x24 pixel area takes about 1/10 of second, which produces noticeable flicker. Not to mention I would be hammering the SD card constantly, so I don't know if there are any long-term side effects to the card from that.

I am going to be looking at other displays. Does anyone know if any of the other displays on sale here support multiple-layer buffering? (Not sure if that's really a term; I just made it up.) Basically, enough RAM to recall two states for each pixel.

Or, maybe, just a faster display? I've looked at videos for the 2.8" TFT touch modules, but it looks like the overall speed is the same, based on the amount of time it takes to wipe the screen.

[adafruit_support_bill]

Not to mention I would be hammering the SD card constantly, so I don't know if there are any long-term side effects to the card from that.

No problem with repeated reads. It is the erase/write cycles that are limited.

The Arduino is a capable microcontroller, but it doesn't have the memory or bandwidth for anything beyond very simple image processing. You might consider moving up to a Raspberry Pi.

[cjbaar]

Thanks, ada. I get that there are limitations to the microcontrollers. I have a raspberry pi, but the size limitations of this particular project are more constrained than that. I figured that's why these displays with built-in graphics processing were ideal... but I had hoped they had bit more power or flexibility built in. At the very least, it would nice if they could buffer the data before displaying, so the user doesn't have to watch the processing of drawing.

Are there any similar-size screens that can be driven by a 328 with any greater speed? It takes 2-4 seconds on this one (depending the SPI divider speed I use) to fill the screen with an image.

Thanks for your help!

[adafruit_support_rick]

It sounds like you are comfortable with library-level programming. If so, then I think you can solve this problem quite easily.

First, have a look at how one of our buffered graphics libraries works; a monochrome OLED, for example.

The main library class inherits from Adafruit_GFX:

Code: Select all

class Adafruit_SSD1306 : public Adafruit_GFX {


So all the graphics functions are handled by Adafruit_GFX, while Adafruit_SSD1306 only handles the specific details of the hardware interface (in this case, that mostly involves uploading the buffer to the screen).

Further, if you dig through Adafruit_GFX, you find that just about everything boils down to calls to drawPixel.

drawPixel is a virtual function in Adafruit_GFX, and it is implemented in Adafruit_SSD1306. So, that's where the magic happens. If you have a command-oriented display like the 2.2 TFT, drawPixel does command-oriented stuff. If you have a buffered display, drawPixel updates the buffer.

So what? Well, you could write your own simple class that inherits from Adafruit_GFX, defines a small buffer, and implements drawPixel. Using this class, you could write your segment of bitmap to the buffer, and then overwrite write your text to the buffer.

Now, you can write that same buffer to your TFT with no flicker.

[cjbaar]

Thanks, driverblock. (nice pic, btw)

I completely understand what you're saying... but since I'm in microcontroller land, I don't have near enough RAM to do a buffer of any significant size, especially when dealing with two-byte pixels, and the SD library already using 1/3 of the available RAM. The keyword in your post is a "small" buffer.

I think my main issue is the speed at which I can send data to the display, if it can't do buffering/latching on it's own. It takes 0.5 seconds just to clear the screen. A process that the user has to watch, instead of just seeing the screen instantly go black (for example). If the display isn't capable of doing that kind of work for me, then I don't think any amount of software optimizations will help.

So, I am back to... is there a better (eg, faster) display for this kind of updating? I see that the 2.8 screen uses a parallel interface, though it also more pixels, so the net effect seems to be the same, based on the videos I've looked at so far.

[adafruit_support_rick]

Welllll … You're talking about text, right? So your buffer only has to be as big as a character space. A lot of the speed issues have to do with data transfer speed, I suspect, so a small buffer will help there. Also, since you would be writing the background in place, a user would only see the character change - even a half-second lag wouldn't be noticeable.

[tldr]

ok, i'm in way over my head, here. don't have the display. not going to dive too far into the drivers or the data sheet. tldr, right? i am what i am.

however... why not buffer a row from the bitmap, over write it with the appropriate row from the each of the characters to be displayed, then write the row to the display. repeat. might incur a bit less addressing overhead than doing things character by character and at least the visual disruption would appear as a more or less orderly top to bottom scan.

[cjbaar]

Maybe I'm missing something obvious in my math here (wouldn't be the first time).

Yes... I am talking about text. However, I want text that is readable from more than a few inches away. One of the goals is to use the display as a clock. There are only a few characters... but a readable character on this screen -- let's use the built-in font example at size "3" -- is 18x24 pixels. In order to keep re-drawing the background, I have to buffer 18x24 pixels of the image, which are addressed as 16-bit values. So ... 18 x 24 x 2bytes = 864 bytes.

Right now... just using the example sketch (hx8340bmp_test), I have only 303 bytes of RAM available, so I can't even buffer a single character at size "3".


BTW... I'm having a hardware issue with this display; not sure if I should open another thread on it. When I first apply power to the setup (arduino+display), the display does not work. I have to hit the reset button on the arduino every time before the display functions. I added a delay(500) to the beginning of setup(), but doesn't seem to help. Is there something else I should be doing to make sure the display works the first time around?

[tldr]

my suggestion is to buffer a single line of the bitmap or whatever piece of one you can get in a single read from the sd card. that might even be a freebee, since the sd library must have a buffer somewhere. overwrite which ever bytes need to be overwritten in the foreground color dump the data to the screen. rinse and repeat.

oof, i guess that's still 220 * 3 bytes per display line, but since you're probably not writing edge to edge, you can shave a few bytes at either end.

[adafruit_support_rick]

but a readable character on this screen -- let's use the built-in font example at size "3" -- is 18x24 pixels. In order to keep re-drawing the background, I have to buffer 18x24 pixels of the image, which are addressed as 16-bit values. So ... 18 x 24 x 2bytes = 864 bytes.

Ewww! Uncle! Uncle! Didn't think we were talking that big. What about using a Mega? Then you get a whole 8K of SRAM to rattle around in.

[cjbaar]

That is true; though it alters the cost equation, too. I might have to go that route, just for the RAM. It still seems, even if I can get the RAM, the speed of drawing that many pixels will be noticeable. But I will keep playing.
Too bad I can't write to progmem on-the-fly.

[adafruit_support_rick]

Too bad I can't write to progmem on-the-fly.

You can write to eeprom on the fly. Supposed to be good for 100,000 writes...