Jump to content

Sharp LS027B7DH01 display driver


aeroman

Recommended Posts

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

Link to comment
Share on other sites

  • 2 weeks later...

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...