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