TFT Text Over Image

[cjbaar]

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

[tldr]

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.

[adafruit_support_rick]

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]

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.

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

[adafruit_support_rick]

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.

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

[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!"));

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

[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