Closed almindor closed 4 years ago
NOTE: do not merge yet this is a WIP
Here's a "problem overview" of this approach: rust playground
See comments, basically this design forces driver writers into having most of their code in the "width specific" implementation blocks, and only basic data construction that's internal can be put outside into the "generic width" driver parts.
I still haven't figured out a better way tho...
Bumped with a DisplayFormat<'a>
enum that lists each possible type and uses core::slice::Iter
for internal representation.
There's a runtime cost to this approach both in the as_slice
conversions (which probably can be removed if we optimize inside the DI implementations) as well as the match checks tho. It does remove the "duplication" in the driver tho, see assoc
branch on ST7789 here
Looks great to me on first glance. Let me try to convert a few drivers to it to check practicability.
For the iterator version I got blocked on https://github.com/rust-embedded/embedded-hal/issues/208
First attempted WIP for associated type usage to allow easier "any Sized + Copy" for data format.
NOTE: tested with
ST7789
anddisplay-interface-spi
usingu8
"hardcoded", didn't try to useu16
anywhere yet.