Support for inverted monochrome displays?

[GoogleCodeExporter]

I'm using u8glib with Sharp Memory LCDs, which are monochrome but which use 1 
for the "background" color and 0 for the "foreground" color.  As far as I can 
tell, u8glib expects the inverse to hold.

I'm working around this now by simply inverting cgram prior to sending it to 
the display in U8G_COM_MSG_WRITE_SEQ, then inverting it back, but this is a 
pain.

Is there a way to use u8glib for inverted displays now?  If not, do you have a 
preferred interface that you'd incorporate if somebody gave you working code?  
(I'm just starting to look into it, but it appears bit 7 of mode is not 
currently used, and it's tempting to make it a flag that affects color 
interpretation, with the result for monochrome being inverting black/white.)

Original issue reported on code.google.com by pabi...@gmail.com on 10 Apr 2014 at 10:15

[GoogleCodeExporter]

Attached is a proposed solution.  Comments welcome.

Original comment by pabi...@gmail.com on 10 Apr 2014 at 11:18

Attachments:

• 0001-proposed-solution-to-inverted-displays.patch

[GoogleCodeExporter]

The patch affects only some of the pb files, so it is not a generic solution. 
In fact i intentionally decided not to dial with inverted and none inverted 
display. Instead, U8glib will write zero during clear operation and foreground 
color is 1 by default.
If you want inverted display, then i think the best is to draw a box with the 
full size of the LCD, then set the index color to 0 and use this index to draw 
all other elements. This basically will invert everything. drawBox() already is 
very fast, so the additional delay can be ignored usually.

Original comment by olikr...@gmail.com on 10 Apr 2014 at 7:06

[GoogleCodeExporter]

Sorry for the delay; for some reason I wasn't notified of your reply.

The patch affected only one pb file because I wanted your input on the approach 
before doing more work.  In my opinion this solution is pretty clean.  I'd be 
happy to provide a complete patch if you'd be willing to apply it.  

If you prefer to not support this functionality, I'll have to use a forked 
library: I'm operating in a low-power/low-memory environment where I can't 
afford to keep the entire pixmap in memory and want to avoid unnecessary work, 
so setting every pixel then clearing only the ones I want visible is not going 
to work for me.

Original comment by pabi...@gmail.com on 21 Apr 2014 at 12:22

[GoogleCodeExporter]

I really do not understand the benefit of your approach. The overhead of 
drawBox() and setColor() usually is zero. Also, no additional RAM will be 
consumed. In contrast: I do not know how you want to save RAM with your 
approach.

Please feel free to fork from U8glib. I am happy if my work is the base for 
further improvements.

Original comment by olikr...@gmail.com on 21 Apr 2014 at 2:03

[GoogleCodeExporter]

The overhead of memset'ing a buffer can't be zero, but I accept that it's 
smaller than most people will want to worry about.

I suppose the real benefit is that, at the application level, I don't need to 
care 
whether the underlying display that's being used happens to be inverted.  Sharp 
Memory LCDs are really cool displays that seem to be increasingly popular, so 
native support in u8glib without application work-arounds would be nice.

At any rate, since this isn't something you want to support, that's fine; I'll 
work around it either in a fork or by inverting the contents prior to sending 
it over SPI to the display, the way I used to do it.

Thanks for your efforts.  I do appreciate u8glib, which is the only portable 
open source graphics library I've come across for microcontrollers; I use it 
for both my MSP430 (http://pabigot.github.io/bsp430/index.html) and in-progress 
ARM Cortex-M frameworks.

Original comment by pabi...@gmail.com on 21 Apr 2014 at 4:08

[GoogleCodeExporter]

ok, sure, i agree that there is an overhead. But i think there are also other 
options. Most modern controller allow switching a single bit in during 
configuration to invert the display. Moreover, displays can be ordered as 
inverted or not inverted type (see http://www.buydisplay.com/ for some 
examples).

All in all i hesitate do add this, as it adds an extra complexity to the lib.

Anyway, thanks, for using U8glib and your kind words on the project. 

Original comment by olikr...@gmail.com on 21 Apr 2014 at 4:59

[GoogleCodeExporter]

Sharp Memory LCDs (http://www.sharpmemorylcd.com/) don't have a non-inverted 
option, so AFAICT the options are changing u8glib or making the application 
code know what type of display it's using.

The API for these devices is particularly sparse: they're write-only (there's 
not even a MISO signal to read state back from the display).  They are, 
however, extremely low energy, though not as low as ePaper displays.

I understand your reluctance; perhaps if/when other people start using these 
displays the value will become more convincing.

Go ahead and close this issue if you want; I don't seem to have the ability to 
do that (or to change it to an enhancement).

Original comment by pabi...@gmail.com on 21 Apr 2014 at 5:28

[GoogleCodeExporter]

I wonder whether these displays are supported by U8glib. I have never seen 
these displays. However, while going though the docs, i saw a 
M1: Frame inversion flag
mentioned there. Not sure about exact meaning, but it could be the requested 
inversion.

Original comment by olikr...@gmail.com on 21 Apr 2014 at 5:52

• Added labels: Type-Enhancement
• Removed labels: Type-Defect

[GoogleCodeExporter]

No, M1 is a polarity-inversion (not frame-inversion) bit that has to be toggled 
at 1Hz through a SPI command to do polarity inversion on the panel while it's 
powered-up; otherwise a latent charge builds up within the LCD.  The display 
also can be configured by hardware to receive the toggle command through a 
GPIO, though the 430BOOST-SHARP96 display doesn't support this.

There is no facility for inverting the data on these devices.

And no, they're not immediately supported by u8glib, but it's pretty trivial to 
write a driver for them: much easier than finding another graphics library. You 
can see the one I wrote at: 
https://github.com/pabigot/bsp430/blob/next/src/boosterpack/sharp96/u8g_bsp430.c

You can see the workaround I have to use in MAYBE_INVERT_CGRAM() in the 
implementation of U8G_COM_MSG_WRITE_SEQ at lines 145 and 156.

Original comment by pabi...@gmail.com on 21 Apr 2014 at 6:04

[GoogleCodeExporter]

ah, nice work. I think i slowly understand your work. 
I will put this issue on hold. Maybe something convices me in the future to add 
support for inverted displays. However at the moment, i would prefer a compiler 
switch for this.

So the enhancement request would be: Instead of clearing the buffer, use all 
ones to init the buffer, also make the default index color be zero.

Original comment by olikr...@gmail.com on 21 Apr 2014 at 8:00

• Added labels: Milestone-Future

[GoogleCodeExporter]

You mean to do this unconditionally when the library is built, instead of 
checking the display-specific mode?  That could work for my needs, but I 
thought u8glib was intended to support multiple displays in the same 
application.  What if one needs the inversion, and another does not?

Original comment by pabi...@gmail.com on 21 Apr 2014 at 8:35

[GoogleCodeExporter]

good point.

Original comment by olikr...@gmail.com on 21 Apr 2014 at 8:47