128x128 color display memory techniques

Timothy D. Swieter

I am considering using a small 128 x 128 pixel color LCD or OLED display in one of my projects.· One of the things I would like to do with the display is to load a bitmap or jpg (preprocessed on a PC to the correct size) from memory or SD card and show it on the display.· Overlaid on the background image would be text and icons, just like many mobile phones.
·There is a wealth of information out there on how to control and get the display working, including a few posts on this forum.· Getting the display to work shouldn’t be a problem, but I am thinking the video memory to take advantage of the colors would be a problem.· Would you agree?·
Some time ago I purchased this OLED screen from Sparkfun.· I can easily build an assembly driver that runs in one cog and clock data from memory out to the display.· From the datasheet on the display there are different color depths that can be used depending on how you setup the display.· If I was to use the 65K mode it would take 2 bytes per pixel to express the color data.
128 x 128 = 16,384 pixels
16,384 x 2 bytes = 32,768 bytes!
Yikes that is a lot of memory for bitmap memory – so much that the Propeller can’t handle it.· I guess a pure bitmap memory technique is out of the question.· I am looking for suggestions from the forum on ways to take advantage of the display, the color, etc and yet minimize the memory required.
From reading Andre’s Hydra book I may be able to do some tile map and palette technique.· I need to read and practice further though.· Maybe I can take advantage of some external memory.· A graphics driver would write the memory and the OLED driver cog would read from the memory.· I have not done enough embedded work to know where to start looking for hardware/software solutions.·
Any other ideas?


▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Timothy D. Swieter
tdswieter.com

---

One little spark of imagination is all it takes for an idea to explode

Graham Stabler

Forgive me, what I am about to say may be a load of rubbish:

When you do graphics with the TV or VGA on the prop you use functions to write to some ram and then stick that ram out to the display over and over. But on this display you use serial communications to draw to the screen, the screen then keep displaying the same image until you alter it.

Does the screen itself not become like the memory? Of course bitmap based menus etc will not be possible but any graphics that are created algorithmically (like vector graphics) will be able to make full use of the colour depth.

I also wondered if it would make sense to actually load the menu screens into the SD card so you can make them as pretty as you like and just overlay cursors etc. With a 1GB card you can have many layers of menu systems all rendered like a mobile phone. I wonder if such menu creation could be done as something like a flash movie and then outputted as a set of bitmaps (or extracted as bmps from an exported movie).

Graham

Ken Peterson

Does anybody know off-hand what data rate is for an SD card with the prop? Is it 400Kb per second?

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔


The more I know, the more I know I don't know.· Is this what they call Wisdom?

Graham Stabler

This may or may not relate to your question (to which I don't know the answer) but the displays by 4Dsystems have the ability to transfer straight from the in build SD card to the display. I've just noticed that Tim is using a different display so it may well be that the reading of an SD card and writing to the display may be too slow for what I suggested. In fact I'm not sure of the update rates with the 4D screens. Hence my caveat.

Graham

potatohead

Some ideas for display memory mapping:

Older computers have this problem.

Do a character mode. Look at the 8x8 driver, for an example of that. Essentially, you define some characters in RAM, then have a 'screen memory' that defines where they appear. If the LCD has it's own display memory, this really leverages that. 8 bits gives you 256 chars. That's enough for alphanumerics, punctuation and some extras for boxes, etc...

In the 'screen memory' have attribute bytes that define colors and modes, that impact the chars. This gets lots of colors on the screen, but not too many in any one place. Keep to the powers of two, for best use of all the bits!

Scanline palettes. Have each display row contain color information, then keep the bitmap at reduced color resolution. This will display a lot of pictures and graphics elements nicely, limitation is number of unique colors per scanline. If you go 16 or 32, your display memory requirements go way down, while still yielding high color displays.

Mix modes.

Have characters in low color depth, for text, boxes, etc... but also have high color ones. Maybe use the most significant bit for a toggle. That way, a screen can be built up that puts the high color depth where it is needed. One can stack up the high color chars to build mini-bitmaps to make zones where dynamic graphics can be displayed.

If you've got displays where there are a lot of static elements, consider storing those in external EEPROM, or something. Maybe just store a whole screen there, for use as a background. A draw operation then would pull from that external storage, then fold in the dynamic elements, defined in the HUB. Draw elements can be reduced color overlays essentially... If the LCD has it's own memory, this might be really sweet.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!

Duffer

If you look at the picture of the display in the SparkFun link, you'll see what looks like a white/silver "bar" to the left of the display, across the width of the flex cable of the display. That is, in the case of this display, the SSD1339 display controller. The controller contains the Graphics RAM (GRAM) for the screen and the control registers for the display. You write your color data directly to GRAM a byte at a time, two bytes per pixel (for 65K colors),·not to the Prop memory.

In order to put anything on the screen, you have to 1. be able to write to the display's registers using several of the 30! connections that are brought out on the loose end of the flex cable. 2. You have to know which registers to write to (the data sheet for the SSD1339 is 66 pages long and filled with register tables and signal timing charts!). Trust me, it's a nightmare. The language deficiencies alone will make your head explode.

Most OLED controllers like this support 16 bit color (two bytes per screen pixel), some few support 24 or 32 bit color.

As an example of the complexity of just the initializarion routine for a module like this, take a look at the uOLED-96-PROP SPIN Object code that can be downloaded from the manufacturer's (4D Systems) web site at: http://www.4dsystems.com.au/downloads/micro-OLED/uOLED-96-PROP/Object-Code/·and read through the Init Method code.

I would suggest that anyone who is considering using a "bare" display like this should take a look at the above code and the SSD1339 datasheet (available from SparkFun on the same page as the link to the display) and decide if this is the kind of project you want to tackle. This is not a project for the faint of heart.

Good luck though , if you decide to go for it,··· Duffer

deSilva

(a) SD cards are connected by SPI rather than by I2C and do not have so many restrictions; they run to 1MB/s and up.

(b) You could arbitrarily reduce the colordepth. Use just 8 bits and either use a palette or spread 8 bits to 16..

Timothy D. Swieter

Thank you for the thoughts forum. I need clearly need to do more reading and rereading of your suggestions to fully understand them.

Duffer - I hear you on how difficult it may be to get a screen up and running. I have experience with software and some embedded work, just not enough in the graphics realm. I got the display because I am willing to tackle the project and it is for a potential product design. Thanks for the word of caution. Also thanks ofr hte link pointing to the uOLED, 4D wrote some great example code for their product!

I understand the display has memory in it. This is the display's memory that it constantly draws from but is not necesarily the memory that I would use to build up the screen. If I wanted to do something like a double buffered memory in the Prop RAM it is diffiuclt to do without reducing the color depth or doing something with palettes, etc. I was hoping to have one cog that did nothing more than clock the memory in RAM out to the display and another cog be the graphics engine for "drawing" in the RAM. From one of the suggestions above I may have to render everything on the fly as it is feed out to the display.

The display can use serial to draw the screen or parallel. I am considering parallel because of the speed.

Thank you for the suggestions potatohead. I like the scanline palettes idea.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Timothy D. Swieter
tdswieter.com

---

One little spark of imagination is all it takes for an idea to explode