Enable drawing in three colors for epd2in13

[lrbalt]

Move from BinaryColor to TriColor: use one Display for drawing

• I use one buffer containing data for b/w and chromatic
• added two fn's to get slice for b/w buffer and slice for chromatic buffer for updating both buffers on the display
• you can still use just the b/w buffer if you want to use two colors
• updated the example to draw b/w and draw using three colors

[lrbalt]

I'd like to get your feedback @caemor before I update documentation

I'm wondering if you like to add a fn to WaveshareThreeColorDisplay which takes a buffer containing both b/w and chromatic data, i.e. fn update_bw_and_chromatic_frame(&mut self, spi: &mut SPI, bw_and_chromatic_buffer: &[u8]

and remove the individual update fn's for bw and chromatic from this trait. Or change the update_color_frrame to take one buffer. But that means that all tri-color screens need to use one big buffer for both b/w and chromatic. I.e. this exposes the internal data model in the api.

[lrbalt]

I've created a small application using both this patch and an emulator with one draw function. This way I can develop using emulator, knowing that it will work on the e-paper display too: https://github.com/lrbalt/epd-bootscreen

I needed to mock TriColor for using the emulator on my Mac (doesn't compile linux-embedded-hal), since it was defined in epd-waveshare, not embedded-graphics.

[caemor]

I'm wondering if you like to add a fn to WaveshareThreeColorDisplay which takes a buffer containing both b/w and chromatic data, i.e. fn update_bw_and_chromatic_frame(&mut self, spi: &mut SPI, bw_and_chromatic_buffer: &[u8]

and remove the individual update fn's for bw and chromatic from this trait. Or change the update_color_frrame to take one buffer. But that means that all tri-color screens need to use one big buffer for both b/w and chromatic. I.e. this exposes the internal data model in the api.

I don't think we should remove the option to just use a smaller buffer and update it in between sending b/w and chromatic. So allowing both options should be the best way to go forwards for now.

[lrbalt]

I'm wondering if you like to add a fn to WaveshareThreeColorDisplay which takes a buffer containing both b/w and chromatic data, i.e. fn update_bw_and_chromatic_frame(&mut self, spi: &mut SPI, bw_and_chromatic_buffer: &[u8]
and remove the individual update fn's for bw and chromatic from this trait. Or change the update_color_frrame to take one buffer. But that means that all tri-color screens need to use one big buffer for both b/w and chromatic. I.e. this exposes the internal data model in the api.

I don't think we should remove the option to just use a smaller buffer and update it in between sending b/w and chromatic. So allowing both options should be the best way to go forwards for now.

Ok, I'll add one new fn for updating both b/w and chromatic using the one buffer

[lrbalt]

I've updated the example in mod.rs so all tests now pass. I did not add the fn mainly because it would look like:

fn update_bw_and_chromatic_frame(&mut self, spi: &mut SPI, bw_and_chromatic_buffer: &[u8]) -> Result<(), SPI::Error>;

This would mean that the trait WaveshareThreeColorDisplay would need to have knowledge of Display2in13bc to split the buffer. And we thus expose the inner data type to a trait. It doesn't feel right. It also led to conflicts on other displays that use some magic in the buffer for the chromatic part (like here) so it would not really be generic.

[caemor]

Do you think this is ready or do you still want to add something here?

[lrbalt]

I think it is ready to merge.

[lrbalt]

cool, thanks!