Add support for 4.2 inch b/w screen

[thedevleon]

This adds support for the 4.2 inch b/w screen.

ToDo

• Get partial refresh working
• Extend sample with partial refresh test

References

• https://github.com/ZinggJM/GxEPD2/blob/master/src/gdey/GxEPD2_420_GDEY042T81.cpp
• https://github.com/WeActStudio/WeActStudio.EpaperModule/blob/master/Example/EpaperModuleTest_APM32F103/Epaper/epaper.c

[thedevleon]

[avsaase]

Thanks! I don't have this screen to test it because it seems to go in and out of stock on AliExpress. Do you have a lick where I can order one?

I'll review this and your other PR later today.

[thedevleon]

I got mine here, still seems to be in stock atm.

[thedevleon]

Partial update doesn't seem to quite work right, I will have to do some more digging as to why.

[capt41nkirk]

I found in the c driver for this display that this display seems to need other commands and data for fast partial refresh. Here you can see the commands. When changing the driver.rs code i get fast partial refresh working:

    /// Start a fast refresh of the display using the current in-screen buffers.
    ///
    /// If the display hasn't done a [`Self::full_refresh`] yet, it will do that first.
    pub async fn fast_refresh(&mut self) -> Result<()> {
        if !self.initial_full_refresh_done {
            // There a bug here which causes the new image to overwrite the existing image which then
            // fades out over several updates.
            self.full_refresh().await?;
        }

        if !self.using_partial_mode {
            self.command_with_data(command::WRITE_LUT, &lut::LUT_PARTIAL_UPDATE)
                .await?;
            self.using_partial_mode = true;
        }
        self.command_with_data(command::DISPLAY_UPDATE_CONTROL, &[0x00])
            .await?;
        self.data(&[0x00]).await?;
        self.command_with_data(command::UPDATE_DISPLAY_CTRL2, &[flag::UNDOCUMENTED])
            .await?;
        self.command(command::MASTER_ACTIVATE).await?;
        self.wait_until_idle().await;
        Ok(())
    }

This would prob break the other displays but i think it's possible to make display specific code.

diff --git a/src/driver.rs b/src/driver.rs
index 37ab26c..de25bd1 100644
--- a/src/driver.rs
+++ b/src/driver.rs
@@ -377,7 +377,10 @@ where
                 .await?;
             self.using_partial_mode = true;
         }
-        self.command_with_data(command::UPDATE_DISPLAY_CTRL2, &[flag::UNDOCUMENTED])
+        self.command_with_data(command::DISPLAY_UPDATE_CONTROL, &[0x00])
+            .await?;
+        self.data(&[0x00]).await?;
+        self.command_with_data(command::UPDATE_DISPLAY_CTRL2, &[0xfc])
             .await?;
         self.command(command::MASTER_ACTIVATE).await?;
         self.wait_until_idle().await;

Snapchat-886308807.mp4

[marsjo]

@capt41nkirk This looks promising. Seems that you are using an esp32 c3 as well. I struggle with clearing the display.
Sometimes it works but most of the time it does not.
Could you also share your example code ❤️

[capt41nkirk]

you can find my code in this repo:
https://github.com/capt41nkirk/weact-studio-epd

the example is in the espc6 folder, though it is actually rewritten for c3. Still i have some issues with the coordinates i think.

[marsjo]

My White is not updating properly. Looks like white in the buffer is treaded like transparent and just black dots are set.
But also not allways - sometimes it just works. The Arduino example from WeAct works fine. Probably I have to also invest some research into it.

IMG_4363.1.mov

Your code on my setup starting from a black screen ...
Actually doing partial updates - but not the full_screen_update

[patcher-ms]

Hello, I have one of these 4.2" displays and I'd be interested in this PR to land. Is there any testing I can help with?
For now I am depending on thedevleon's fork, using full updates, and everything works well for me.

[capt41nkirk]

@patcher-ms you could clone my code from above and use the ESP32-C3 example if you have that chip to test whether this works (including the full update at beginning and partial fast refresh afterwards).

[marsjo]

So full refresh didi not work for me. If I run it twice with different (long) text I get a mess. Anyhow I stepped through the code comparing it with GxEPD2 and I fixed it for me with the following patch (full_update) that's shares some common stuff with your partial fix.

diff --git a/src/driver.rs b/src/driver.rs
--- a/src/driver.rs	(revision 932d92e5d22f017ed3f64ee6ea9316eefd4f8f80)
+++ b/src/driver.rs	(date 1738971139965)
@@ -216,6 +216,10 @@
         self.initial_full_refresh_done = true;
         self.using_partial_mode = false;
 
+
+        self.command_with_data(command::DISPLAY_UPDATE_CONTROL, &[0x40, 0x00])
+            .await?;
+
         self.command_with_data(command::UPDATE_DISPLAY_CTRL2, &[flag::DISPLAY_MODE_1])
             .await?;
         self.command(command::MASTER_ACTIVATE).await?;

[capt41nkirk]

@marsjo thanks for the update. Your change doesn't break my display, so it seems this is the more general solution. I updated my fork accordingly. Now we need to rewrite the code to make the functions screen specific for general usage of the driver for all screen sizes.

[marsjo]

I do not have the others Display currently - thinking of ordering them.
I think the main difference should be between B/W and B/W and Red. Maybe also the controller chip?

I dislike the partial_buffer approach - but I have to find out more about the code.

[capt41nkirk]

@marsjo I find it strange that your 4.2 screen did not work before your code change in full_refresh but mine did. Maybe there are also other controller chips/revisions. I attach a pic of the backside, maybe you can spot some differences.
I currently have bw 2.13, 2.9 and 4.2 screen as well as 2.9 bwr one.

[marsjo]

I do not have the sticker and the text on the cable - but the rest looks equal.
Did you try to run the full_update example from this PR with differente sized text?

I added the command 21 (see SSD1683 page 28) telling the chip to bypass Red RAM content as 0 (do not paint) while using BW normally.

During Initalisation the options are set to Normal for Red and Inverse for B/W so I have no clue how this should work if we do not set it.

By the way DISPLAY_UPDATE_CONTROL expects two data values instead of

        self.command_with_data(command::DISPLAY_UPDATE_CONTROL, &[0x00])
            .await?;
        self.data(&[0x00]).await?;

we should write:

        self.command_with_data(command::DISPLAY_UPDATE_CONTROL, &[0x00, 0x00])
            .await?;

I think I should read how fast_update is done because I read that it uses the Red Buffer in some way.

BTW: Is there a easy way to get the current millis is esp-rs?

[marsjo]

Next question: I read more inside the code and I wondering why do we write to the Red and B/W Buffer after the refresh?

    /// Update the screen with the provided partial frame buffer at the given position using a fast refresh.
    ///
    /// `x`, and `width` must be multiples of 8.
    pub async fn fast_partial_update_from_buffer(
        &mut self,
        buffer: &[u8],
        x: u32,
        y: u32,
        width: u32,
        height: u32,
    ) -> Result<()> {
        self.write_partial_bw_buffer(buffer, x, y, width, height)
            .await?;
        self.fast_refresh().await?;
        self.write_partial_red_buffer(buffer, x, y, width, height)
            .await?;
        self.write_partial_bw_buffer(buffer, x, y, width, height)
            .await?;
        Ok(())
    }

This might make sense for the red_buffer because we store the old image in it to enhance fast_update. But why would we write the same information into the b/w Buffer again?

Removing those two lines I can reduce the update time of the example from 1912ms to 877ms.
But actually we should initialize SPI with 20MHz and then it would not matter anyhow.

[thedevleon]

Thanks everyone for their input, I have tried to implement all the suggestions in this thread as display-specific code (unfortunately a bit of a hacky way, let me know if there's a better way), and can confirm that fast refresh now works in my screen. I do however get a border around the screen that slowly fades to back until it is cleared by the next partial refresh, so that's odd. I guess there's still more tinkering needed...

[thedevleon]

Tested also with the 2.9" B/W screen, still seems to work fine with the display-specific fixes.
If you want to test, just comment (out) the parts in the sample as required.

I tried to see if any of the additions would also work for the 2.9" screen, but they all break the screen in some way or another, so they are truely specific to the 4.2" screen.

[thedevleon]

Added a bit more code specific to the 4.2 inch variant, based on the source code from here: https://github.com/WeActStudio/WeActStudio.EpaperModule/blob/master/Example/EpaperModuleTest_GD32F303/Epaper/epaper.c

[giomf]

Any news on this topic? Im planing to buy a 4.2 screen. Can I help in some way when I get it?

[cojmeister]

Hey @avsaase!
Are you planning on merging this? It would be very useful for me as well!