Re: TFT Text Over Image

by cjbaar on Mon Nov 12, 2012 11:48 pm

heh; true. But 1k of eeprom doesn't gain me much. 256k of progmem on a mega would make the upgrade worthwhile.
cjbaar
 
Posts: 71
Joined: Fri Aug 26, 2011 4:58 pm

Re: TFT Text Over Image

by tldr on Tue Nov 13, 2012 1:58 am

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.
"If I had known it was harmless, I would have killed it myself." - Phillip K. Dick, A Scanner Darkly
User avatar
tldr
 
Posts: 464
Joined: Thu Aug 30, 2012 12:34 am

Re: TFT Text Over Image

by adafruit_support_rick on Tue Nov 13, 2012 8:26 am

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.
User avatar
adafruit_support_rick
 
Posts: 8496
Joined: Tue Mar 15, 2011 10:42 am
Location: Buffalo, NY

Re: TFT Text Over Image

by tldr on Tue Nov 13, 2012 9:10 am

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.
"If I had known it was harmless, I would have killed it myself." - Phillip K. Dick, A Scanner Darkly
User avatar
tldr
 
Posts: 464
Joined: Thu Aug 30, 2012 12:34 am

Re: TFT Text Over Image

by cjbaar on Tue Nov 13, 2012 10:08 am

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.
cjbaar
 
Posts: 71
Joined: Fri Aug 26, 2011 4:58 pm

Re: TFT Text Over Image

by adafruit_support_rick on Tue Nov 13, 2012 12:04 pm

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
adafruit_support_rick
 
Posts: 8496
Joined: Tue Mar 15, 2011 10:42 am
Location: Buffalo, NY

Re: TFT Text Over Image

by cjbaar on Tue Nov 13, 2012 2:26 pm

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.
cjbaar
 
Posts: 71
Joined: Fri Aug 26, 2011 4:58 pm

Re: TFT Text Over Image

by adafruit_support_rick on Tue Nov 13, 2012 3:04 pm

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
adafruit_support_rick
 
Posts: 8496
Joined: Tue Mar 15, 2011 10:42 am
Location: Buffalo, NY

Re: TFT Text Over Image

by cjbaar on Tue Nov 13, 2012 3:11 pm

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.
cjbaar
 
Posts: 71
Joined: Fri Aug 26, 2011 4:58 pm

Re: TFT Text Over Image

by cjbaar on Tue Nov 13, 2012 3:13 pm

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
cjbaar
 
Posts: 71
Joined: Fri Aug 26, 2011 4:58 pm