adafruit / Adafruit_EPD

e-paper display driver for Arduino
140 stars 56 forks source link

Partial update example #50

Open tgikal opened 3 years ago

tgikal commented 3 years ago

Feather M4 Express 2.9" E-Ink Featherwing Arduino IDE 1.8.14

Using the ThinkInk_partial.ino example in examples, I get a clear "0000" display, but each partial update results in a block that resembles a QR code. Every 10 updates, during the full screen refresh, the counter displays properly again, I'm not really sure how to troubleshoot this.

ladyada commented 3 years ago

yeah that is not surprising, the partial code barely works and it wasnt very fun when it did :(

tgikal commented 3 years ago

The part that's driving me nuts is I effectively have the same or better hardware as used in this demo video: https://youtu.be/eipKg2pUQ_8?t=280 But there is no supporting code for how to make it do that.

ladyada commented 3 years ago

i think they used gxepd, a different library. good luck!

tgikal commented 3 years ago

With some modifications, calling the proper pins, importing the correct display class, ect. I was able to get a working counter to display with the PartialUpdateTest in the GxEPD library, so I'm a little less frustrated.

I'm sure the GxEPD library isn't designed to use the buffer memory on the display, so it's using a bunch of ram on the processor.

I guess all I can do is hope somebody with a better understanding of this library than me gets the ambition to update it someday.

nzhang1218 commented 3 years ago

Hi @tgikal , I got extract the same issue you had before (using the same hardware you have). I'm happy that you have figured it out. I've tried to debug it but failed. Do you mind elaborating more details on how you did the modifications? Thanks a lot!

digamesystems commented 3 years ago

Hi all,

I'm also having issues getting partial update to work on my board. -- In my case, I'm using the 1.54" monochrome display.

1.54" Monochrome Display

I spent a bit working with Mike over on Adafruit's forum and thought it might be good to reach out here. Here's a link to the discussion we had:

eInk Partial Update: Supported Boards?

I realize that this is a new feature, but we should be able to get there! Any progress on this?

Thanks!

John

ladyada commented 3 years ago

there is no ETA - any PRs are accepted but we have no plans to spend more time on it.

digamesystems commented 3 years ago

Thanks, @ladyada.

I appreciate the reply.

Maybe there is a way to leverage some of the work that @ZinggJM has done:

https://github.com/ZinggJM/GxEPD

I've used his libraries with Waveshare displays and they work quite well.

From his GitHub page it looks like there may be an opportunity to extend his library to new displays:

I can and will only support e-paper panels I have!

- promotion panels from suppliers are welcome, to add support to GxEPD
- donation panels from users are welcome, to add support to GxEPD

'Might be worth sending him a free display?

;)

Regards, John

ladyada commented 3 years ago

its probably already supported - please try that library!

digamesystems commented 3 years ago

Got it!

If you select:

GxEPD2_BW<GxEPD2_154, GxEPD2_154::HEIGHT> display(GxEPD2_154(/*CS=5*/ SS, /*DC=*/ 17, /*RST=*/ 16, /*BUSY=*/ 4)); // GDEP015OC1 no longer available

as your mapping, in 'GxEPD2_display_selection.h' it works just fine with my display.

Thanks for the tip!

Regards,

John

digamesystems commented 3 years ago

Got it working and made a little example program for the 1.54" Mono Display.

https://github.com/digamesystems/eInkPartialUpdate

I'm guessing it should work with other monochrome displays if you select the appropriate display in the header above.

gitdode commented 1 year ago

Could someone please confirm the following on displays using the SSD1680/SSD1681 drivers, regarding the "Display Update Control 2" command (0x22)?

I'm working on a simple "plain" avr-libc support for these displays and while partial update seems to work somewhat, I would be curious about fast update, to save power and possibly longer lifetime of the display - but it seems the SSD168x drivers don't support it?

markbirss commented 1 year ago

Could someone please confirm the following on displays using the SSD1680/SSD1681 drivers, regarding the "Display Update Control 2" command (0x22)?

  • 0xf7 ("DISPLAY Mode 1") does a full update
  • 0xff ("DISPLAY Mode 2") does a partial update
  • there is no "DISPLAY Mode" for the fast update mentioned in the GoodDisplay datasheet on page 10 (I'm just guessing that this is the producer of these displays)

I'm working on a simple "plain" avr-libc support for these displays and while partial update seems to work somewhat, I would be curious about fast update, to save power and possibly longer lifetime of the display - but it seems the SSD168x drivers don't support it?

@gitdode Here

https://github.com/ZinggJM/GxEPD2/blob/283ed6366af70fc11dca76705b78b159288edcb7/src/epd/GxEPD2_213_BN.cpp#L410

gitdode commented 1 year ago

@markbirss Thanks for the interesting pointer. As there is no mention of fast update mode either I guess it is simply not available and I'm looking at the wrong data sheet or the information provided is wrong.

markbirss commented 1 year ago

@markbirss Thanks for the interesting pointer. As there is no mention of fast update mode either I guess it is simply not available and I'm looking at the wrong data sheet or the information provided is wrong. @gitdode

Yes, I received a 4inch GoodDisplay sample - https://www.youtube.com/shorts/-o7ax1c39Vo SDD1677 based

and has some additional functions for fast update in the sample code but i modified GxEPD2 support for it

https://www.good-display.com/product/457.html

void EPD_HW_Init_Fast(void)
{
  EPD_W21_RST_0;  // Module reset   
  delay(10);//At least 10ms delay 
  EPD_W21_RST_1;
  delay(10); //At least 10ms delay 

  Epaper_READBUSY();   
  EPD_W21_WriteCMD(0x12);  //SWRESET
  Epaper_READBUSY();   

  EPD_W21_WriteCMD(0x18);   
  EPD_W21_WriteDATA(0x80); 

  EPD_W21_WriteCMD(0x0C);
  EPD_W21_WriteDATA(0xAE);
  EPD_W21_WriteDATA(0xC7);
  EPD_W21_WriteDATA(0xC3);
  EPD_W21_WriteDATA(0xC0);
  EPD_W21_WriteDATA(0x80);

  EPD_W21_WriteCMD(0x01); //Driver output control      
  EPD_W21_WriteDATA((EPD_WIDTH-1)%256);   
  EPD_W21_WriteDATA((EPD_WIDTH-1)/256);
  EPD_W21_WriteDATA(0x02);

  EPD_W21_WriteCMD(0x3C); //BorderWavefrom
  EPD_W21_WriteDATA(0x01);  

  EPD_W21_WriteCMD(0x11); //data entry mode       
  EPD_W21_WriteDATA(0x03);

  EPD_W21_WriteCMD(0x44); //set Ram-X address start/end position   
  EPD_W21_WriteDATA(0x00);
  EPD_W21_WriteDATA(0x00);
  EPD_W21_WriteDATA((EPD_HEIGHT-1)%256);    
  EPD_W21_WriteDATA((EPD_HEIGHT-1)/256);

  EPD_W21_WriteCMD(0x45); //set Ram-Y address start/end position          
  EPD_W21_WriteDATA(0x00);
  EPD_W21_WriteDATA(0x00); 
  EPD_W21_WriteDATA((EPD_WIDTH-1)%256);    
  EPD_W21_WriteDATA((EPD_WIDTH-1)/256);

  EPD_W21_WriteCMD(0x4E);   // set RAM x address count to 0;
  EPD_W21_WriteDATA(0x00);
  EPD_W21_WriteDATA(0x00);
  EPD_W21_WriteCMD(0x4F);   // set RAM y address count to 0X199;    
  EPD_W21_WriteDATA(0x00);
  EPD_W21_WriteDATA(0x00);
  Epaper_READBUSY();

  //TEMP (1.5s)
  EPD_W21_WriteCMD(0x1A); 
  EPD_W21_WriteDATA(0x5A);

  EPD_W21_WriteCMD(0x22); 
  EPD_W21_WriteDATA(0x91);
  EPD_W21_WriteCMD(0x20);

  Epaper_READBUSY();  
}
gitdode commented 1 year ago

Great, thanks! I wasn't aware they have sample code: https://www.good-display.com/companyfile/631.html