Smart LEDs util library sends incorrect data beyond 2nd pixel

[tschundler]

Using more than one LED color yields random-seeming output (see photos linked below). This in on an ESP32-S3 (examples below). I got slightly different and still incorrect behavior on a plain ESP32.

Using this code to generate a simple pattern:

    leds.write(std::iter::repeat(RGB::new(0,0,0)).take(64)).unwrap();
    leds.write((0..8_u8).map(|n| // only 8 to test
            match (n, n%4) {
                (_, 0) => RGB::new(n,0,63-n), // Blue->Red gradient
                (_, 1) => RGB::new(40,40,0), // Yellow
                (_, 2) => RGB::new(0,63,0), // Green
                (_, _) => RGB::new(0,40,40), // Cyan
            }
        ))

With esp-idf-sys

    let mut leds = Ws2812Esp32Rmt::new(0,17).unwrap();

using https://github.com/cat-in-136/ws2812-esp32-rmt-driver:

yields https://photos.app.goo.gl/fZh9Lh9fwJUy3wMk8 (what I expect)

With esp-hal

    let peripherals = Peripherals::take();
    let mut system = peripherals.SYSTEM.split();
    let clocks = ClockControl::boot_defaults(system.clock_control).freeze();

    let mut rtc = Rtc::new(peripherals.RTC_CNTL);
    let timer_group0 = TimerGroup::new(peripherals.TIMG0, &clocks);
    let mut wdt = timer_group0.wdt;
    let io = IO::new(peripherals.GPIO, peripherals.IO_MUX);

    // Disable MWDT and RWDT (Watchdog) flash boot protection
    wdt.disable();
    rtc.rwdt.disable();

    let pulse = PulseControl::new(
        peripherals.RMT,
        &mut system.peripheral_clock_control,
        ClockSource::APB,
        0,
        0,
        0,
    )
    .unwrap();
    let mut leds = <smartLedAdapter!(64)>::new(pulse.channel0, io.pins.gpio17);

...copied from https://github.com/esp-rs/esp-hal/blob/main/esp32s3-hal/examples/hello_rgb.rs

yields https://photos.app.goo.gl/CePVYZvMFgJtBtCH6

almost all LEDs are lit, and except the first two, the colors aren't even in the correct order.)

Debugging

I started debugging setting a pin high. I noticed...

• in esp-hal
  • there's a 4.2-4.3ms delay before data is sent out.
  • The data out is ~1.9ms total (full 64px?)
  • each bit is ~1.2us from rising-edge to rising-edge
  • changing buffer to only 8px instead of 64, the delay to output is the same, and the length of the data out is the same (~1.9ms)
  • changing the buffer to 256px increases delay to 109ms and the burst to 78ms (this seems crazy - 4x pixels=>40x time to transmit??)
• in esp-idf
  • 72us delay before data is sent
  • data is 240us total (just the provided 8px)
  • also ~1.2us per bit

...will report more if I find more. The first pixel in esp-hal is right, but afterwards things get odd.

[tschundler]

@jessebraham seems like the primary contributor to https://github.com/esp-rs/esp-hal/blob/main/esp-hal-common/src/utils/smart_leds_adapter.rs

This is using esp-hal version from github master ...
ad38650

Also tested with released 0.4.0 -- same behavior

[bjoernQ]

You need to compile that code in release mode - then it should work as expected

[tschundler]

It does! Since it is working, I don't want to take too much of your time, but do you mind sharing briefly why?

I'd expect things like the much slower delay before output because of debug vs release. It looks like it completely fills a buffer of the pulse-widths from the input data, so when when handing that buffer to a peripheral, I'd expect no difference. (Something deeper inside RMT feeds a smaller buffer?)

I tried adding opt-level = "z" to [profile.dev] in Cargo.toml, and it works better (first 8 px are correct, but then the next 6 are a repeat of the first 6) ... so there's something more than the opt-level needed? Oh, but opt-level = "s" works... more inlining is needed? It must be a pretty tight deadline.

[bjoernQ]

Good to hear it's working for you

So why doesn't it work in dev mode?

The thing is that the FIFO buffer for the RMT peripheral is just 48 words (64 on ESP32, ESP32-S2) (per channel by default) and every bit we send to the LEDs already takes up one word. One LED needs 3 bytes - so 3 * 8 = 24. That would mean we could address two LEDs without refilling the buffer. But since there is also an end-marker needed at the end this reduces to one LED

Since the addressable LEDs don't have a clock line, they are very sensitive to timing issues which causes funny colors etc.

We might be able to improve this a little bit in future. Alternatively, you could also try using SPI to drive the addressable LEDs (https://crates.io/crates/ws2812-spi) if you don't need the SPI for something else

[bjoernQ]

I guess we can close this issue

[tschundler]

With 48 bits at 1.2uS / bit -> 57uS / two LEDs, there should be over 10k instructions between pairs of pixels. I'm surprised that isn't enough to refill even in a debug build.

Based on https://wp.josh.com/2014/05/13/ws2812-neopixels-are-not-so-finicky-once-you-get-to-know-them/ it seems if the pulse were one-shot, as long as they stay low while refilling, as long as its less than 50uS, that gives another > 10k instructions. It seems the pattern repeats, instead of stopping after one.

Might be worth added a comment in the library and/or demo file, but otherwise fine to close this.