Image from EEPROM

So here is my situation. I have very limited physical space to work with. I am currently testing everything with one of the 4D 144 displays because I happen to have one. However, it is very expensive when compared to a Nokia knockoff that provides the exact same quality output. While I can use text and simple shapes to convey a decent interface, it would be infinitely more professional looking if I used a background image and wrote text over it.

On the 4D display, there is a command to display an image from the SD card. I cannot afford the cost nor the space for an SD card module on my finished project so I am looking for another option. An i2c 64K EEPROM is less than $1.00. I only need to store one image that serves as the background on the display with a minimal amount of text written over it.

In the end what I am hoping to do is use the EEPROM to store the Image (128x128 16 bit image is a little over 32K). I want to use the Nokia display or its chinese knockoff equiv. Or possibly one of the Varitronix displays that are $5.00 on Digikey. The image will always be on and the text will be written over it. Is this possible using the existing Nokia library and is the refresh rate on this going to be a problem? I know on the 4D display, showing an image is much faster than even changing the background color but I have no idea why. It seems that in order to do this, I would have to write the individual pixels. Would I need to interface with the display via parallel to make sure this is not a problem? If so, would I need to also get a parallel EEPROM or could I buffer data in chunks to avoid the issue and still use I2C. The parallel EEPROM chips are in the $5-7 range.

Lots of questions needing some insight from someone that has used these displays and has some knowledge of EEPROM usage.

Edit: I just looked at the datasheet for the 4D Goldelox controller and it does use an 8bit parallel interface to the display but reads the data from the SD card via SPI.

Thanks,

Wade

If you compress the image (e.g. using Huffman encoding), it will take up a lot less than 32K and you can probably store it in the Arduino's own program memory instead. You just need to choose a compression algorithm that doesn't need too much RAM during decpmpression.

Thanks for that, I was just relying on standard 16bit Jpg.

I also found an option in the 4D Goldilox datasheet for building an image using hex. I had never tried it so I glossed over that section of the datasheet probably 50 times.

The problem for me still remains that I want to use one of the cheaper displays. This may still present a challenge.