Document the heap allocation of Displayxxxx:default()

[mangelajo]

Some platforms (like ESP32) have a limited stack size, but a bigger heap which can range 2-4MBytes for spiram. In such platforms it's impossible to allocate most of the displays in the stack, but it's possible to get them heap allocated (as long as we are compiling with std).

This commit documents heap allocation of the display buffer.

[mangelajo]

ha, fmt is very unhappy, fixing that.

[mangelajo]

I am hearing suggestions on the esp-rs matrix:

• allow passing down a buffer instead to the display, i.e. :

#[link_section = ".ext_ram.bss.frame_buffer"]
static FRAME_BUFFER: StaticCell<[u8; N]> = StaticCell::new();

• using alloc instead of std::Box

extern crate alloc;
use alloc::boxed::Box;

[mangelajo]

ha... last minute changes... it doesn't work now:

error[E0599]: no function or associated item named `new` found for struct `epd_waveshare::epd5in65f::Display5in65f` in the current scope
   --> src/peripherals/display.rs:155:66
    |
155 |             let mut display: Box<Display5in65f> = Display5in65f::new();
    |                                                                  ^^^ function or associated item not found in `epd_waveshare::epd5in65f::Display5in65f`
    |
    = help: items from traits can only be used if the trait is in scope
help: the following trait is implemented but not in scope; perhaps add a `use` for it:
    |
1   | use epd_waveshare::traits::HeapAllocated;

[mangelajo]

A updated the implementation to only use alloc::boxed when enabled instead of std::boxed

[peckpeck]

If you look at #123 you can see that the Default display is #[inline(always)] which means that you can skip the stack allocation of a display by just doing Box::new(DisplayXX::default())

Without needing std in the library :-)

[mangelajo]

If you look at #123 you can see that the Default display is #[inline(always)] which means that you can skip the stack allocation of a display by just doing Box::new(DisplayXX::default())

Without needing std in the library :-)

Oh awesome, I like your approach much better then. I will give a try to your PR and report back :)

[caemor]

I finally hat time to merge Peckpecks PR, so if his idea already resolves your issue, we could change this pr/make a different one where we add it to the readme as an faq point or similar and maybe to the main doc comment as well.

[mangelajo]

I will do that @caemor !

[mangelajo]

Oh sorry, right it was on me to document this.

[mangelajo]

Ok, I converted it to documentation.

[caemor]

Suggested change

	///# use embedded_graphics_core::prelude::*;
	///# use embedded_graphics::prelude::*;