TFT Text Over Image

EL Wire/Tape/Panels, LEDs, pixels and strips, LCDs and TFTs, etc products from Adafruit

Moderators: adafruit_support_bill, adafruit

Please be positive and constructive with your questions and comments.
User avatar
cjbaar
 
Posts: 73
Joined: Fri Aug 26, 2011 5:58 pm

Re: TFT Text Over Image

Post by cjbaar »

heh; true. But 1k of eeprom doesn't gain me much. 256k of progmem on a mega would make the upgrade worthwhile.

tldr
 
Posts: 466
Joined: Thu Aug 30, 2012 1:34 am

Re: TFT Text Over Image

Post by tldr »

cjbaar wrote:eh; true. But 1k of eeprom doesn't gain me much. 256k of progmem on a mega would make the upgrade worthwhile.
what if you store your images in flash at compile time? the gimp will output an image as a c source file.

oops. unfortunately the compiler throws up all over itself if you feed it a string longer than 32k. which 220 * 176 * 3 is.

but you could cut the image into 3 parts...

of course, only two images would fit into 256k of flash.

User avatar
adafruit_support_rick
 
Posts: 35092
Joined: Tue Mar 15, 2011 11:42 am

Re: TFT Text Over Image

Post by adafruit_support_rick »

tldr wrote: what if you store your images in flash at compile time? the gimp will output an image as a c source file.
Good point, although you wouldn't necessarily do it at compile time

How often does the background change? If you stored all possible clock digits, including background, on the SD, you would do your updates by writing a bitmap instead of writing text.

Buffer a "digit" line-by-line or column-by-column, and the screen update latency goes from being a problem to a cool dissolve-effect feature. Venetian-blind dissolves, random blocks, there are lots of possibilities.

tldr
 
Posts: 466
Joined: Thu Aug 30, 2012 1:34 am

Re: TFT Text Over Image

Post by tldr »

driverblock wrote:Good point, although you wouldn't necessarily do it at compile time
yeah. it's just that a mega was mentioned. and all that flash. then i realized how large the files actually were and that all that flash wasn't, in fact, all that much. on the other hand reading the flash would be a whole lot faster than reading sd. 3 clock cycles versus a minimum of about 18 per byte. and you could lose all the sd card stuff.

another option would be to forgo the file system on the sd card. get rid off all the fat overhead. just write one big file to the thing with pointers at the beginning to the images.

arrrrgh. gotta go to work.

User avatar
cjbaar
 
Posts: 73
Joined: Fri Aug 26, 2011 5:58 pm

Re: TFT Text Over Image

Post by cjbaar »

yeah. it's just that a mega was mentioned. and all that flash. then i realized how large the files actually were and that all that flash wasn't, in fact, all that much
It would plenty large enough to buffer the parts of the image I need on an ongoing basis. But, my goal, is still to stay within the boundaries of the 328 for now. I have very little physical space, so I'm trying to limit myself to an arduino mini form factor.
If you stored all possible clock digits, including background, on the SD, you would do your updates by writing a bitmap instead of writing text.
I'd actually considered that. Even at a large font size (say "6"), I'm at about 4K per digit. Assuming I don't use seconds on the clock, there are 28 possible bg/digit combinations... so about 112K of extra data.

One of my ideas was to have enough bg images in the card to display a new one every day of the year, perhaps. Now that ada has broken down the format of the bitmap file in the example sketch, I don't think it would take too much effort to read in a new bg image every night at midnight... and, if the digit files aren't there, I could create them on-the-fly. Might take a couple of minutes to do them all, but I'd only have to do it once a day at a maximum.

User avatar
adafruit_support_rick
 
Posts: 35092
Joined: Tue Mar 15, 2011 11:42 am

Re: TFT Text Over Image

Post by adafruit_support_rick »

cjbaar wrote:Now that ada has broken down the format of the bitmap file in the example sketch, I don't think it would take too much effort to read in a new bg image every night at midnight... and, if the digit files aren't there, I could create them on-the-fly. Might take a couple of minutes to do them all, but I'd only have to do it once a day at a maximum.
Perfect! Sounds like you got y'self a solution there, son. And it sounds like a pretty cool clock idea, too. :D

User avatar
cjbaar
 
Posts: 73
Joined: Fri Aug 26, 2011 5:58 pm

Re: TFT Text Over Image

Post by cjbaar »

Thanks for all the input, guys. Now I just need to figure out where all my RAM is going. I know the SD library takes about 700 bytes when it loads... but no idea why I am down to only 300 bytes free. That's about 1K I can't account for.

User avatar
adafruit_support_rick
 
Posts: 35092
Joined: Tue Mar 15, 2011 11:42 am

Re: TFT Text Over Image

Post by adafruit_support_rick »

First thing to do is move any literal string you can find to flash by using the F("") macro. By default, literal strings are placed in SRAM. Example:

Code: Select all

Serial.println(F("Hello World!"));

User avatar
cjbaar
 
Posts: 73
Joined: Fri Aug 26, 2011 5:58 pm

Re: TFT Text Over Image

Post by cjbaar »

Thanks, I'll take a look. Just odd that the example sketch -- which isn't doing anything beyond reading a file from SD and dumping it to the display -- is using that much.

User avatar
cjbaar
 
Posts: 73
Joined: Fri Aug 26, 2011 5:58 pm

Re: TFT Text Over Image

Post by cjbaar »

SO... get this. I took a long hard read through the datasheet for this driver. It turns out that the display is capable of the features I was looking for. It has a RAM buffer you can write to, then control the frame display which would happen all at once. You can even read the data back from the display to see what a given pixel is set to.

The catch? Those functions only work in parallel mode; the ada model uses serial SPI.
dang

Locked
Please be positive and constructive with your questions and comments.

Return to “Glowy things (LCD, LED, TFT, EL) purchased at Adafruit”