ePaper modules with SSD1680

[Dompie]

I have two WeAct ePaper modules: a 2.9" white-black-red and a 3.7" white-black, both with an SSD1680. There's an Arduino library, but I don't want to use it and want to control the modules with Positron. Are there any people on this forum who have worked with the SSD1680? That would save a lot of work.

Johan

[trastikata]

Hello Dompie,

ePaper support is next on the list to add to my TFT Graphic Library 2 together with some AMOLED displays. Probably will happen in the next month or two when I will have more free time, at the moment I don't have much time for the hobby projects.

[Dompie]

@trastikata Great, I really appreciate that. I'll wait and play around with your library with some TFT display in the meantime.

Johan.

[Sommi]

@trastikata

this is good news! any outlook when ths epaper stuff will be ready for playing?

Sommi

[RGV250]

Hi,

There's an Arduino library, but I don't want to use it and want to control the modules with Positron.

Have you looked at the Arduino library to convert to Positron, that is what I do. A word of caution, Arduino libraries are normally rubbish compared to Positron so do not try to do a "bit for bit" conversion as you will end up with a mess.

Regards,
Bob

[top204]

I have looked at it, but the epaper displays are too expensive to buy for experiments, especially the colour ones.

They have been around for such a long time, they should cost pennies by now.

Regards
Les

[Dompie]

@RGV250 the SDD1680 driver isn't that difficult but only the display isn't enough, you need a graphic library with it. That is the reason I love it when Trastikata implement one in his graphic library.

@top204 At AlieExpress a Weact 2.9"black-white-red is €10

Johan

[trastikata]

Hello all,

I've put together an adapter PCB to connect the TFT test board to various e-paper modules, and I've also received a few modules from China.

Writing the drivers themselves isn't particularly difficult, but e-paper displays behave very differently compared to TFTs, both in terms of interface and operation. I've been going through the specifics and already have a rough idea for an abstraction layer between the TFT library and the e-paper modules.

A few things worth noting:

-Graphics data is stored in the controller RAM as bits, not pixels
-Data transfer is in bytes however
-To modify one pixel you need to know the state of the other 7 pixels in the byte to be modified
-There are usually two or more RAM planes for different colors
-Only one controller I've seen supports RAM readback
-Because of this, drawing and updating graphics will likely require:
--A full frame buffer in MCU RAM (or external memory), or
--Pre-generated images
-Pre-generated images will probably need some form of compression
-Partial and full updates require careful handling, since each pixel/color uses specific waveform sequences
-Avoiding ghosting may require:
--RAM readback and selective updates, or
--Full display refresh/reset (controller RAM is cleared on power reset)
etc ...

Everything is ready on my side, but my day job needs priority right now. I work on a project basis, and my current project has a deadline around Easter. After that, I should have a few weeks free to focus on this.

So hopefully it won't be too long before I can share some results.

[Dompie]

Oh, that is great news that you are already this far. Yes, the driver isn't the biggest problem, but the rest is. I think it's great that you want to devote so much attention to this. Amazing!!!

I am retired and I am away a lot with the camper during the summer months, so unfortunately, there won't be any time for nice testing in the coming months.

Johan

[trastikata]

Project Update:

-I have implemented a fully compatible virtualization layer between the TFT Graphic Library and the EPD display frame buffer.

- Due to the nature of EPDs, where rows are bit-oriented and columns are byte-aligned, and because most controllers do not support RAM read-back, either internal RAM or external SRAM is required. Each pixel consumes 1 bit for the black/white plane and an additional 1 bit for the red/yellow plane (if used).

*Only SSD1681 controllers support internal RAM read-back; other controllers do not. Therefore, EPDs using SSD1681 can operate without additional RAM.

- I have extended the functionality of the SdCardWriteRGB565.exe tool to support image conversion for EPD displays. This is not a graphic editing tool, it converts existing images into HEX data using run-length encoding (RLE) compression, allowing large images to fit into internal flash memory.

- I have started implementing shape and font routines that do not rely on a frame buffer. This allows EPDs to be used without large RAM requirements, although with some limitations in functionality.

- A significant amount of code has been written. Some parts still require debugging. While developing, many new ideas are emerging, so the current phase is focused on brainstorming and implementation.

- The next step will be to organize the code into structured sub-libraries and develop drivers for 4–5 different EPD controller ICs. Most of the complex design work is complete the remaining effort is mainly coding and organization.

Here is one example showing how simple the end-user code will be:

Code Select Expand

    EpdSetUp(0,0)                                           'Set display
    EpdSetBorder(BLACK)                                     'Set border
    EpdResetScreen(WHITE)                                   'Reset screen to white
    EpdBmpFromCodeRam(Cat, 0,0)                             'Draw Cat picture from FLASH code
    EpdSetOrientation(1)                                    'Rotate working plane 90 degrees
    TftRectangleRC(0,1, 105,55, 20,1,WHITE,0,1)             'Empty area using solid rectangle   
    TftRectangleRC(0,1, 105,55, 20,0,BLACK,3,-1)            'Draw a thick border empty rectangle    
    TftSetBdfFont(5)                                        'Set current BDF font to #5
    TftPrintBdfString("Positron", 6,33, 0,0, BLACK,WHITE,1) 'Print string
    TftPrintBdfString("Compiler", 6,11, 0,0, BLACK,WHITE,1) 'Print string
    EpdSendBuffers()                                        'Send the RAM frame buffer to EPD
    EpdFrameUpdate(EPD_UPDATE_NORMAL)                       'Update EPD screen
    EpdDeepSleep()                                          'Enter deep sleep


[JonW]

That looks brilliant mate

[charliecoutas]

Brilliant, will get myself an Epaper module and try it. Thanks very much.

[top204]

Absolutely brilliant Dyanko.

Best regards
Les

[JonW]

Only real issue with epapers is the refresh rate, great for low power, slow-changing functions though.  They do look superb

[Dompie]

Wow, that's awesome!

Johan

[trastikata]

Only real issue with epapers is the refresh rate, great for low power, slow-changing functions though.  They do look superb

There's another quirk with them - they require either a (S)RAM buffer for sophisticated overlay functions, or using stored images in FLASH, otherwise some limitations can apply because of the way the internal memory is accessed, except SSD1681 which allows access to the driver RAM.

[Craig]

Fantastic work Dyanko Well done