Jump to content
aeroman

Sharp LS027B7DH01 display driver

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
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.

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


×
×
  • Create New...