3.7in Display Problems

[caemor]

Hey @caemor @jamesmunns ,
Thanks for pointers. I'm still figuring it out. I have some weird issues when I try to test the 3.7 display using a NRF52 board. Things I've checked so far - initialization and display sequence match C/Python examples, tried different LUT provided in those examples, width/height match as well, rotation only affects that tiny area where "circle" is shown.
Have you encountered this kind of effect?
an attempt to draw a circle

I got my hands on RPi and tested waveshare Python snippet with the same display, everything worked as expected. Digging into my implementation.

Originally posted by @Alexx-G in #26 (comment)

[caemor]

Copied from #26

Thanks a lot @caemor for your effort!
Is 3.7in b/w display supported?

Not yet.

If no, is #35 still an accurate example of adding a new display?

#35 is is a red/black/white display so it is slightly different.
I believe the instructions from above might be more helpful but #35 as well as any of the other recent PRs adding a new display can help you, just be aware that your display differs in the colors.

Since your 3in7 b/w display seems to have some gray tones you need to define a new color type in color.rs similar to what is defined in their wiki: https://www.waveshare.com/wiki/3.7inch_e-Paper_HAT

So while finishing this I saw you already added a new comment :-D

Thanks @jamesmunns !
I've started working on a PR yesterday, however I'm struggling finding a command table for 3.7 - https://www.waveshare.com/wiki/3.7inch_e-Paper_HAT

If you click on ressources you can find the specifications. (e.g. Command table starting from page 14 onwards https://www.waveshare.com/w/upload/7/71/3.7inch_e-Paper_Specification.pdf)

And just feel free to make a WIP-PR and asks questions if you are stuck anywhere.

[caemor]

Thanks for pointers. I'm still figuring it out. I have some weird issues when I try to test the 3.7 display using a NRF52 board. > Things I've checked so far - initialization and display sequence match C/Python examples, tried different LUT provided in those examples, width/height match as well, rotation only affects that tiny area where "circle" is shown.
Have you encountered this kind of effect?

To me it looks like you might use the wrong color type/wrong amount of bits per pixel. Have you uploaded your changes on github somewhere? If yes I could take a look and maybe help you.

Waveshare has two different init functions for when using the grayscale or just b/w-color:
https://github.com/waveshare/e-Paper/blob/master/RaspberryPi_JetsonNano/c/lib/e-Paper/EPD_3in7.c

Maybe applying this already resolves the issue?

[Alexx-G]

I've followed waveshare examples when implementing initialization/display sequences. There's something I've missed indeed, since waveshare samples work just fine with 3.7.
I'll cleanup some pieces and create a draft PR.

[Alexx-G]

@caemor I've submitted #69 as draft.
Please ignore formatting errors, I'll fix it, add tests and do some clean-up once I get a working MVP

[Alexx-G]

Here's how I'm testing that PR on a NRF52

#![no_main]
#![no_std]

use nrf52_air_quality as _;

use embedded_hal::blocking::delay::DelayMs;
use defmt::info;

use nrf52840_hal::{
    self as hal,
    gpio::{p0::Parts as P0Parts, p1::Parts as P1Parts, Level},
    prelude::*,
    spim::{self, Spim},
    Timer,
};

use epd_waveshare::{
    epd3in7::*,
    graphics::{Display},
    prelude::*,
};

#[cortex_m_rt::entry]
fn main() -> ! {
    // take() returns all peripherals, so we can access them
    let board = hal::pac::Peripherals::take().unwrap();
    // first peripheral: initialize timer
    let mut timer = Timer::new(board.TIMER0);

    let pins = P0Parts::new(board.P0);
    let pins_1 = P1Parts::new(board.P1);

    // instanciate SPI
    // configure SPI
    let din = pins_1.p1_01.into_push_pull_output(Level::Low).degrade();
    let clk = pins_1.p1_02.into_push_pull_output(Level::Low).degrade();
    let cs = pins_1.p1_03.into_push_pull_output(Level::Low);
    let dc = pins_1.p1_04.into_push_pull_output(Level::Low);
    let rst = pins_1.p1_05.into_push_pull_output(Level::Low);
    let busy = pins_1.p1_06.into_floating_input();

    let spi_pins = spim::Pins {
        sck: clk,
        miso: None,
        mosi: Some(din),
    };
 
    let mut spi = Spim::new(board.SPIM3, spi_pins, spim::Frequency::K250, spim::MODE_0, 0);

    let mut delay = Timer::new(board.TIMER1);
    info!("Initializing EPD3in7");
    let mut epd3in7 = EPD3in7::new(&mut spi, cs, busy, dc, rst, &mut delay).unwrap();

    info!("EPD3in7 initialized - {:?}x{:?}", epd3in7.width(), epd3in7.height());
    delay.delay_ms(4000u32);

    info!("Clearing frame");
    epd3in7.clear_frame(&mut spi).unwrap();
    epd3in7.display_frame(&mut spi).unwrap();

    nrf52_air_quality::exit()
}

[Alexx-G]

Ok. So I was using wrong LUT. For some reason RPi vs STM samples use different LUT for clearing the screen.
Now it works fine for B/W setup. I'll focus on tests and getting PR closer to completion.
@caemor What's the approach for displays that support B/W and Grayscale? 2 different modules or just one with Grayscale (which is a technically a superset of B/W).
Although I haven't checked whether partial update is supported for B/W or both.

[caemor]

Its great to hear that it is finally running! 🎉

I think we only had display until now who support only one of these modes at all. So we don't have an defined option on this already. Are two seperate inits (one additional one with only b/w) + two seperate graphics impls enough for it work?
If yes then I think this would be a preferred solution with a doc comment about it so one could go for the smaller (and maybe faster?) b/w variant if needed, else the default grayscale one is taken.

[avlec]

I've tested off of what's in main with displaying a line and text on the Raspberry Pi Pico WH and the B/W epd with the embassy HAL and it seems to be working without a hitch after figuring out the pin configuration.