Go Down

Topic: U8glib: Graphics Lib for LCDs and OLEDs (Read 54 times) previous topic - next topic

olikraus

Quote
If I must rewrite the full display, I guess I could store all 128 columns in an array and write them all over every time I refresh. I'm not sure how efficient that is, though.


This is correct. You must store the 128 values in order to be able to refresh the display. It is indeed the key difference between u8glib and GLCDv3. For sure this makes u8glib slower than GLCDv3, but this enables u8glib to support displays where the display frame buffer can not be read back from the display (and still avoid a local full frame buffer).

Oliver

rgroener

First, thanks for this great library!
I just tested a LM096-128064 (128x64 OLED; SSD1306) with a atmega168 and it works flawless.

Is there a chance, that in a future version, the picture loop philosophy can be activated / deactivated for drawing graphs.
I am facing the same problem as Muhammad in the last posting.

Best regards Roman

olikraus

Hi Roman

Background:
There are GLCDs were the internal frame buffer (display memory) can not be read by the microcontroller.
This is usually true for displays with SPI interface.
 
Solutions:
1) Reserve memory in the microcontroller, render the picture into it and transfer the memory from the microcontroller to the display.
Disadvantage: Large SRAM consumtion, possible only if display frame buffer size is smaller than the available SRAM.
2) Reserve some smaller amount of memory (e.g. 1/4 of the display frame buffer size) and render the picture more often (e.g. 4x). This trades time vs. SRAM
Disadvantage: Slower frame rate, picture loop (more complex API)

U8glib was designed to support displays without read back ability.
U8glib follows solution 2)
U8glib is one of the view libs which support large SPI displays on small (ATTINY) controllers (with very limited SRAM).

A graphics lib such as GLCDv3 for KS0108 controller has a much more convinient programming interface. But GLCDv3 also depends on the fact that it can read memory from the display frame buffer.

U8glib offers a solution for displays not support by other graphics librarys.
U8glib sometimes is the only available lib.
U8glib might be a bad choice in other cases (like using it for KS0108 based displays)
 
I am glad to hear about success stories with U8glib and i am sorry to offer programming API, which is more complicated and difficult to understand.
I tried to compensate this with many features, a good collection of fonts, reliable functions and a documentation with many pictures.
I am always open to improvements, but i probably can not change its basic feature.

I also suggest to read Bill's remarks on GLCDv3 and u8glib:
http://arduino.cc/forum/index.php/topic,56705.msg1001066.html#msg1001066

More Information:
http://code.google.com/p/u8glib/wiki/tpictureloop

Thanks for your picture,
Oliver




bperrybap



A graphics lib such as GLCDv3 for KS0108 controller has a much more convinient programming interface. But GLCDv3 also depends on the fact that it can read memory from the display frame buffer.

GLCD also has a write-through cache option which creates a frame buffer that it uses for reads
instead of reading the data from glcd memory which can speed up display updates at the expense
of using additional memory.
Turning on the write-through cache also allows GLCD to work the same on write-only displays at the expense of the
memory for the frame buffer. I've thought about creating a shift register interface that could reduce
the number of pins down to 2-3 pins but have never gotten around to it.

Maybe there are some optimizations that could be done to speed up u8glib or offer more capabilities.

For a little speed:
- maybe provide hints to the low level PAGE_NEXT function as to which area(s) are "dirty" and need updating.
It could be as simple as a low and high value that indicates the starting page and ending page
that needs to be pushed to the display.
Or it could be as complex as a bitmap indicating which bytes have pixel data to be flushed out.
The low level code could choose to ignore the hints but smarter lower level update routines could
choose to take advantage of it to reduce updates.
Seems like the simple low/high hints would be pretty easy to implement and might offer some
significant speed improvements in certain situations.

- Could it treat the page buffer as a write through cache instead?
Seems like a pretty big change but that would allow only writing the modified pages to the display.

Form some additional functionality:
- Could it create a full frame buffer to provide additional functionality?
Without write-through, it seems like it wouldn't be that difficult to wedge in.
The code could use all the same mechanisms it does now, so none of the lower interface code
has to change. The difference being it would simply always have the rows of data always available.
The flush code could call the PAGE_NEXT (flush) routines as necessary for each row in the frame buffer
to update the physical display.
This would allow for the possibility for things like scrolling or graphic updates on top of existing pixels.

It's always a tradeoff. Some strategies work better than others depending on the nature
of the display updates being done.

--- bill

olikraus


Quote
- maybe provide hints to the low level PAGE_NEXT function as to which area(s) are "dirty" and need updating.

After the first iteration, it could be known which pages are written. So, empty pages could be skipped. But instead of copying the page to the display, the page needs still to be cleared.

Quote

- Could it treat the page buffer as a write through cache instead?

not exactly sure what you mean about this.

Quote

- Could it create a full frame buffer to provide additional functionality?

Sure, this could be done (as long as there is enough SRAM)

Oliver

Go Up