Sharp LS027B7DH01 display driver

[aeroman]

Hi,

just to share this gdisp driver for Sharp LS027B7DH01 memory in pixel display, monochrome 400x240 LS027B7DH01_driver.zip .

I've tweak gdisp.c (line 18) to add choosing the logo color ability in gfxconf.h :

#ifndef GDISP_STARTUP_LOGO_COLOR
    #define GDISP_STARTUP_LOGO_COLOR        GFX_WHITE
#endif

The driver works but is not extensively tested for now.

ps : i was unable to upload the file, the web page returned " There was a problem uploading the file." or "-200" messages. So here a google drive link :

https://drive.google.com/drive/folders/1kaTg_je2_ncuifPSORbFXQg_BW9XKjqj?usp=sharing

[Joel Bodenmann]

Thank you for sharing your driver

We'll look into the forum upload issue that you mentioned.

[aeroman]

Hi,

the buffer used for this driver (whole screen 400*240 pix)  weighs a lot (12482 bytes).

Is it possible with µGFX to work with a reduced screen area for the buffer ?

thanks

[aeroman]

Hi,

the buffer used for this driver (whole screen 400*240 pix)  weighs a lot (12482 bytes).

Is it possible with µGFX to work with a reduced screen area for the buffer ?

thanks

[inmarket]

uGFX can work with no buffer at all provided pixels are individually addressable when talking to the controller and the controller itself maintains an internal framebuffer. When that is not the case the driver needs to maintain enough of the screen image that it can merge pixel drawing operations into the existing screen image before sending the merged data to the controller.

In practice it is typically controllers driving displays of less than 1 byte per pixel that fall into this category.

As the buffer is managed by the driver, the buffer can be in any format that works for the controller, be that expanded to one pixel per byte, packed into a byte stream (like most uGFX monochrome drivers), or compressed in some other way.

[aeroman]

Thank you @inmarket for these explanations,

i've seen the ED060SC4 driver as buffer size drop example.

But this type of displays (sharp MiP) have limitation on memory writes frequency (max 20 Hz) and i suppose flushing the reduced buffer to display memory on driver side  when it's full may bring to not respect that requirement, using gdisp side timer flush seems more suitable.

At this time, with my limited understanding of how gdisp drawing operations works, i don't see how to achive this driver with a reduced buffer.

It's not a problem since my application can survive (for now) with this heavy buffer.

Looking on these interresting (from a power consumption point of view) displays from "Japan Displays" https://www.j-display.com/english/product/reflective.html it would be nice to find a solution.