search

greeng1 / u8glib

Automatically exported from code.google.com/p/u8glib
Other
0 stars 0 forks source link

Support for SSD1351 18-bpp color mode #232

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
Hello,

Thanks for making u8glib.  It is an awesome library.

Attached is a patch for supporting 18-bpp/262K/666 color mode, tested and 
working on the following hardware:

http://www.wide.hk/products.php?product=SPI-%252d-1.5%22-Color-OLED-display-for-
Arduino-{47}-PIC-{47}-AVR-{47}-ARM-{47}-Gadgeteer-%29

You can typically find that display on ebay as well.

The "extras" patch includes some routines for drawing bitmaps.  They take as 
input a byte array of RGB values (8-bpp), but discard the lower two bits of 
data per channel when drawing to the display.  They were split into a separate 
patch because they make some assumptions about the display hardware and may not 
be suitable for a general-purpose API.

Here are some pics of the project where I'm using u8glib and the display: 
http://imgur.com/a/wBI0y

A word about the close-up pictures of the display where there are graphical 
glitches:  I dropped and broke the display which caused the glitches, but it 
since has been replaced and works well with the above patch.

However, one time I passed a bad u8g_t pointer to one of the display routines 
and now I have a perpetual column of pixels stuck on red, which persists even 
after disconnecting and reconnecting the power. :-(

Original issue reported on code.google.com by mik...@gmail.com on 22 Jan 2014 at 3:07

Attachments:

GoogleCodeExporter commented 9 years ago 
Forgot to mention, this patch reserves a 3KB page draw buffer (8 rows per page 
* 128 pixels per row * 3 bytes per pixel) in SRAM.

That entails 16 total pages (128 rows / 8 rows per page), thus the display must 
be drawn 16 times to render a single screen of imagery.  That can be slow.  
Decreasing the page buffer size below 3K will save memory but add more pages, 
thus incurring more passes through the drawing functions, and make drawing 
slower.  Increasing the page buffer size quickly consumes lots of memory.

To compensate, the extras patch defines a u8g_DrawFullScreenBitmapP() function 
that will render a full-screen image, but only having to draw it once (instead 
of once per page, or 16 times in the current configuration).  That improves the 
rendering speed a lot for that specific use case.

Original comment by mik...@gmail.com on 22 Jan 2014 at 3:37

GoogleCodeExporter commented 9 years ago 
I probably will remove support for any true color devices from u8glib in the 
future.
Instead there will be a true color library "ucglib" which will take over fonts 
and functionality, but will not require the picture loop. Ucglib will also not 
require any buffer. Speed will be also optimized for true color displays.

Ucglib already supports 18 bits per pixel.

Ucglib is here: http://code.google.com/p/ucglib/

Drop me a note if you want a prerelease.

Original comment by olikr...@gmail.com on 22 Jan 2014 at 6:01

GoogleCodeExporter commented 9 years ago 
Very cool.  Are you doing random pixel addressing and drawing directly to the 
display?  Seems like it would make sense for hardware that doesn't pack many 
pixels into a single write, though (for the SSD1351 at least) there would be 
command overhead in addressing the data randomly rather than sequentially.

Is the prerelease in hg?

Original comment by mik...@gmail.com on 22 Jan 2014 at 9:43

GoogleCodeExporter commented 9 years ago 
Yes, all data is written directly to the display. There is some optimization: 
Vertical and horizontal lines are written without position update. Also text 
output is optimized so that only x or y is updated, but no both. Latest version 
is in hg.

Original comment by olikr...@gmail.com on 22 Jan 2014 at 11:00

GoogleCodeExporter commented 9 years ago 
i will close this...

Original comment by olikr...@gmail.com on 24 Jan 2014 at 8:54