pub struct SmartLedsAdapter<'d, const BUFFER_SIZE: usize, Mode, Order, Timing>{ /* private fields */ }Expand description
SmartLedsWrite driver implementation using the ESP32’s “remote control” (RMT) peripheral for hardware-offloaded, fast control of smart LEDs.
For usage examples and a general overview see the crate documentation.
This type supports many configurations of color order, LED timings, and LED count. For this reason, there are three main type parameters you have to choose:
- The buffer size. This determines how many RMT pulses can be sent by this driver, and allows it to function entirely without heap allocation. It is strongly recommended to use the
buffer_sizefunction with the desired number of LEDs to choose a correct buffer size, otherwiseSmartLedsWrite::writewill returnAdapterError::BufferSizeExceeded. - The
ColorOrder. This determines what order the LED expects the color values in. Almost all LEDs usecolor_order::Rgborcolor_order::Grb. - The
Timing. This determines the smart LED type in use; what kind of signal it expects. Several implementations for common LED types like WS2812 are provided. Note that many WS2812-like LEDs are at least almost compatible in their timing, even though the datasheets specify different amounts, the other LEDs’ values are within the tolerance range, and even exceeding these, many LEDs continue to work beyond their specified timing range. It is however recommended to use the corresponding LED type, or implement your own when needed.
When the driver move is Blocking, this type implements the blocking SmartLedsWrite interface. An async interface for esp_hal::Async may be added in the future. (You usually don’t need to choose this manually, Rust can deduce it from the passed-in RMT channel.)
Implementations§
Source§impl<'d, const BUFFER_SIZE: usize, Mode, Order, Timing> SmartLedsAdapter<'d, BUFFER_SIZE, Mode, Order, Timing>
impl<'d, const BUFFER_SIZE: usize, Mode, Order, Timing> SmartLedsAdapter<'d, BUFFER_SIZE, Mode, Order, Timing>
Sourcepub fn new<C, P>(channel: C, pin: P) -> Result<Self, RmtError>where
C: TxChannelCreator<'d, Mode>,
P: PeripheralOutput<'d>,
pub fn new<C, P>(channel: C, pin: P) -> Result<Self, RmtError>where
C: TxChannelCreator<'d, Mode>,
P: PeripheralOutput<'d>,
Creates a new SmartLedsAdapter that drives the provided output using the given RMT channel.
Note that calling this function usually requires you to specify the desired buffer size, ColorOrder and Timing. See the struct documentation for details.
If you want to reuse the channel afterwards, you can use esp_hal::rmt::ChannelCreator::reborrow to create a shorter-lived derived channel.
§Errors
If any configuration issue with the RMT Channel occurs, the error will be returned.
Sourcepub fn new_with_memsize<C, P>(
channel: C,
pin: P,
memsize: u8,
) -> Result<Self, RmtError>where
C: TxChannelCreator<'d, Mode>,
P: PeripheralOutput<'d>,
pub fn new_with_memsize<C, P>(
channel: C,
pin: P,
memsize: u8,
) -> Result<Self, RmtError>where
C: TxChannelCreator<'d, Mode>,
P: PeripheralOutput<'d>,
Creates a new SmartLedsAdapter that drives the provided output using the given RMT channel.
Note that calling this function usually requires you to specify the desired buffer size, ColorOrder and Timing. See the struct documentation for details.
If you want to reuse the channel afterwards, you can use esp_hal::rmt::ChannelCreator::reborrow to create a shorter-lived derived channel.
The memsize parameter determines how many RMT blocks this adapter will use.
If you use any value other than 1, other RMT channels will not be available, as their memory blocks will be used up by this driver.
However, this can allow you to control many more LEDs without issues.
§Errors
If any configuration issue with the RMT Channel occurs, the error will be returned.