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)
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?
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.
Yes the refresh is defined through the sram data + LUT. So you can improve the time by doing small updates with
update_partial_frameand 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):
Here are some old timing I took how long different stuff takes on this epd: