Currently the driver part of this library is hidden under the "unstable" feature. This makes sense since the current color channel design is being worked on. But what if we make the driver completely color channel count and order independent and stable?
It would be great if the Ws2812Esp32RmtDriver type could be available in this crate but without the write_colors method and no color submodule available by default. Just a simple ws2812_esp32_rmt_driver::Ws2812Esp32RmtDriver with only these methods:
/// /// Creates a Low-level WS2812 ESP32 RMT driver. ...
pub fn new(channel_num: u8, gpio_num: u32) -> Result<Self, Ws2812Esp32RmtDriverError> { ... }
/// Writes the data in `pixel_data` to the LED strip in the given order.
/// Byte count per pixel and channel order is not handled by this method, the data has to be correctly
/// laid out in the slice depending on the LED strip model
pub fn write(&mut self, pixel_data: &[u8]) -> Result<(), Ws2812Esp32RmtDriverError> { ... }
This would allow this library to be fully usable on ANY strip type instantly. And helpful abstractions for well known strip types can then be added on top without touching the actual driver. I think this would be a cleaner design. It would make the driver type focused on one thing and one thing only: Converting the pixel buffer data to the WS2812 RMT format and sending it out on the wire. Anything else can be on a higher abstraction level.
Currently the driver part of this library is hidden under the "unstable" feature. This makes sense since the current color channel design is being worked on. But what if we make the driver completely color channel count and order independent and stable?
It would be great if the
Ws2812Esp32RmtDrivertype could be available in this crate but without thewrite_colorsmethod and nocolorsubmodule available by default. Just a simplews2812_esp32_rmt_driver::Ws2812Esp32RmtDriverwith only these methods:This would allow this library to be fully usable on ANY strip type instantly. And helpful abstractions for well known strip types can then be added on top without touching the actual driver. I think this would be a cleaner design. It would make the driver type focused on one thing and one thing only: Converting the pixel buffer data to the WS2812 RMT format and sending it out on the wire. Anything else can be on a higher abstraction level.