EPD super slow in comparison to python library

[caemor]

See #33 for more info. But in short:

This seems to be about twice as slow to write to the screen as the Waveshare Python controller (specifically the July 10 2017 version, which is what I currently have hooked up to my screen), despite using the same panel settings.

Measuring some drawing times (DATA_START_TRANSMISSION_1 + DISPLAY_REFRESH):

* Old Python driver: 24s
  
  * Buffer is 30720 bytes (`= HEIGHT * WIDTH / 8`)
  * Writes 4 data bytes per buffer byte

* Latest Python driver: 30s
  
  * Buffer is `HEIGHT * WIDTH / 4` bytes
  * Writes 2 data bytes per buffer byte

* This Rust driver: 53s
  
  * Buffer is `HEIGHT * WIDTH / 8` bytes
  * Writes 4 data bytes per buffer byte

Tested on a raspberry pi zero w by @str4d

[caemor]

@str4d: You were using the oldest link from here? https://www.waveshare.com/wiki/File:7.5inch-e-paper-hat-code.7z or did you try their github: https://github.com/waveshare/e-Paper/tree/master/RaspberryPi%26JetsonNano/python/examples ?

[str4d]

The "Old Python driver" test does indeed use the driver from the oldest link on that wiki page. The "Latest Python driver" test used whatever was in latest master of their repo at the time of testing.

[frioux]

I suspect that if people want to try to implement the faster updates this would be the place to look: https://github.com/repaper/gratis/. The python "driver" just writes to a FUSE filesystem backed by C.

[kburgi]

Hi there,

I may have misunderstood, but the initial reporter said that it was way longer to write on the e-paper using this crate, versus the python equivalent.

In my case, I've the epd7in5 (first version) and it was also faaaar longer to put a simple text on the screen than the equivalent python version

It tooks ~ 30 seconds in the update_frame() function

Here is my quick test :

hardware :

• raspberry pi zero w
• 7.5inch HD e-Paper HAT (https://www.waveshare.com/wiki/7.5inch_HD_e-Paper_HAT)

    let mut delay = Delay;

    let mut epd7in5 = Epd7in5::new(&mut spi, busy, dc, rst, &mut delay, None).expect("eink initalize error");

    let mut display = Display7in5::default();

    println!("here_1 {}", Local::now());
    display.set_rotation(DisplayRotation::Rotate0);
    draw_text(&mut display, &my_string_utc, 20, 20);

    println!("here_2 {}", Local::now());
    epd7in5.update_frame(&mut spi, display.buffer(), &mut delay)?;
    println!("here_3 {}", Local::now());
    epd7in5
        .display_frame(&mut spi, &mut delay)
        .expect("display frame new graphics");

    println!("here_4 {}", Local::now());
    let new_delay: u32 = 7000;
    println!("Set delay to {} ms", new_delay);
    delay.delay_ms(new_delay);

    println!("Finished tests - going to sleep");
    epd7in5.sleep(&mut spi, &mut delay)

here_1 2024-02-28 21:03:32.851235119 +01:00
here_2 2024-02-28 21:03:32.852281108 +01:00
here_3 2024-02-28 21:04:08.387091203 +01:00            <= MORE THAN 30 seconds btw these 2 steps !
here_4 2024-02-28 21:04:08.388867185 +01:00
Set delay to 7000 ms
Finished tests - going to sleep

Any idea on how to improve this ?

Thanks

[caemor]

@kburgi Which display are you using? If you have the referenced one (https://www.waveshare.com/wiki/7.5inch_HD_e-Paper_HAT) you should use the epd7in5_hd module not the one you linked above with a slightly different update_frame method:

    fn update_frame(
        &mut self,
        spi: &mut SPI,
        buffer: &[u8],
        delay: &mut DELAY,
    ) -> Result<(), SPI::Error> {
        self.wait_until_idle(spi, delay)?;
        self.cmd_with_data(spi, Command::SetRamYAc, &[0x00, 0x00])?;
        self.cmd_with_data(spi, Command::WriteRamBw, buffer)?;
        self.cmd_with_data(spi, Command::DisplayUpdateControl2, &[0xF7])?;
        Ok(())
    }

It would then be great if you could benchmark the lines here and compare it to the python parts and maybe even check if they skip one of the commands or parts.