Support for inverted monochrome displays?

[olikraus]

Originally reported on Google Code with ID 253

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.)

Reported by pabigot on 2014-04-10 10:15:59

[olikraus]

Attached is a proposed solution.  Comments welcome.

Reported by pabigot on 2014-04-10 11:18:21

---

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

[olikraus]

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.

Reported by olikraus on 2014-04-10 19:06:19

[olikraus]

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.

Reported by pabigot on 2014-04-21 12:22:34

[olikraus]

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.

Reported by olikraus on 2014-04-21 14:03:56

[olikraus]

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.

Reported by pabigot on 2014-04-21 16:08:54

[olikraus]

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. 

Reported by olikraus on 2014-04-21 16:59:10

[olikraus]

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).

Reported by pabigot on 2014-04-21 17:28:39

[olikraus]

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.

Reported by olikraus on 2014-04-21 17:52:31

• Labels added: Type-Enhancement
• Labels removed: Type-Defect

[olikraus]

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.

Reported by pabigot on 2014-04-21 18:04:32

[olikraus]

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.

Reported by olikraus on 2014-04-21 20:00:55

• Labels added: Milestone-Future

[olikraus]

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?

Reported by pabigot on 2014-04-21 20:35:25

[olikraus]

good point.

Reported by olikraus on 2014-04-21 20:47:09

[ayourk]

I for one would be interested in u8glib support for this display.