epd-waveshare: Error running 4.2" using an STM32F3

Are there any tricks on the 4.2" using an STM32F3? Getting no signs of life from the display, and the program crashing once I hit the let mut display = Display4in2::default(); line.

Then you most likely don’t have enough ram left over. It needs 15kB for the full default display buffer and the Display4in2::default() doesn’t do much besides making a 15kB framebuffer. You could look into the examples/epd4in2_variable_size.rs example which is using a smaller buffer to update only little parts of the display.

You could also check how much ram you have left and try to reduce your usage elsewhere.

Thank you. It also looks like this command: let mut epd = EPD4in2::new(&mut spi, cs_disp, busy, dc, rst, &mut delay).expect("eink initalize error"); is crashing it as well. I think I need to figure out how to set up panics to see what’s going on.

_Originally posted by @David-OConnor in https://github.com/caemor/epd-waveshare/issues/47#issuecomment-634609753_


edit: Given that you mentioned they updated the examples to v2, and I can get the arduino example to work on V1 but not V2, maybe I need to see what V1 looks look.

by David-OConnor


From my experience, the “original” version of this crate (without my modifications) worked well with this display except for quick refresh. I did also have the issues with RAM size, though. Given that the display protocol is write-only, errors during initialization should be limited to errors from your SPI/GPIO HAL implementation.

by mgottschlag

About this issue

  • Original URL
  • State: closed
  • Created 4 years ago
  • Comments: 29 (22 by maintainers)

Most upvoted comments

I found the information I needed to make progress and got it to compile. I have a 2.9" (d) e-paper module so I’ll need to add support for that, but I’ll open a new thread for that. Thanks!

I don’t have any open source repos using this, but I’ll say confidently that this library is the best generic Rust embedded driver I’ve used, and its official examples are quite good. What are you having problems with in particular?

Would it help if I PRed a STM32F3 example once I work through this more?

I think it would be better to add link to a working example in your repo, since I can’t support all the examples for each device in here.

Is there a recommended way of updating the Display/buffer on only a specific region, eg to erase something, or swap out a small piece of text or graphic without refreshing the whole screen? Ie something that would be described as display_partial_frame(). Or is this in the area of set_lut()?

Yes the refresh is defined through the sram data + LUT. So you can improve the time by doing small updates with update_partial_frame and use “dangerous” LUTs with faster refresh time (and no full b+w+b+w refreshs). Speeding up the clock to near its upper limit from the datasheet also helps.

The Display Refresh only does the following according to its description (and we only send a single command for this):

    /// While user sent this command, driver will refresh display (data/VCOM) according to SRAM data and LUT.
    ///
    /// After Display Refresh command, BUSY_N signal will become “0” and the refreshing of panel starts.
    DISPLAY_REFRESH = 0x12,

Here are some old timing I took how long different stuff takes on this epd: grafik