esp-hal-smartled does not support multiple LED's correctly

[cmumford]

There appears to be an incorrect delay on the GPIO line when writing more than one LED. I am fairly naive about the WS2812B spec, but I believe that there should be no time delay between pin data when writing a string of LED's. I've modified the hello_rgb_async demo, in https://github.com/cmumford/esp-hal-community/tree/bug, to repeatedly write a [RED, GREEN] sequence. There is an approximately 850 usec gap in between the RED and GREEN sequences. Here is a logic probe capture:

I believe this is interpreted as always being for LED index 0, which alternates between RED and GREEN, which shows up as ORANGE.

A capture from a C program, which uses esp-idf, shows no gap at all between these two color sequences.

Note: The application is writing different colors, but still accurately depicts the problem.

I'm not sure if this problem is with this project, or possibly esp-hal-smartled, but felt this is a good place to start.

I am using the Waveshare ESP32-C6-LCD-1.9 development board and have modified the demo app to use GPIO3 for that board.

[jamessizeland]

Thanks for this analysis!

[MabezDev]

smartleds are timing sensitive. Whilst this delay could be an implementation issue, it could also be the program is halted whilst new instructions are pulled from FLASH (where the code is stored) into the the cpu cache where it can be executed.

One way to ensure RMT operations are readily available in an O(1) executable place, is to place the driver (and related code in RAM). We already have ESP_HAL_CONFIG_PLACE_SPI_MASTER_DRIVER_IN_RAM from https://docs.espressif.com/projects/rust/esp-hal/1.0.0-beta.1/esp32c6/esp_hal/index.html#additional-configuration, a PR adding something similar for RMT would be welcome.

[cmumford]

Thanks @MabezDev. I just ran the test built for --release and the LED's lighted correctly. Another (larger) program of mine still misbehaves as a release build. Both of these facts support your theory above. I'll get my board back on a logic probe tomorrow and see if I can learn more and report it back here. I'll also look at ESP_HAL_CONFIG_PLACE_SPI_MASTER_DRIVER_IN_RAM and see if I can put together a PR.

[cmumford]

I believe the cause of this issue is the fact that I'm wring to multiple LED's using the async API. SmartLedsAdapterAsync::write writes the color data in chunks and I'm pretty sure that this results in "daylight" in between each RMT transmission. The fact that the --release build of the hello_rgb_async worked was probably (my guess) because the delay in between the two writes was reduced to a tolerance that the WS2812B driver could handle. My larger app draws to the screen, etc. and therefore a much larger gap in between transfers. If I use the synchronous API then everything works just fine.

If my suspicion is correct then I'm wondering if SmartLedsAdapterAsync is suitable for chains of more than a single LED. I could probably modify SmartLedsAdapterAsync::write to write all colors in a single transfer, but that may result in poor cooperative multi-tasking. Ideas?

I started work on a branch to keep the RMT driver in RAM. If there is interest I can finish this work and post a PR. Any interest @MabezDev

[MabezDev]

I started work on a branch to keep the RMT driver in RAM. If there is interest I can finish this work and post a PR. Any interest @MabezDev

I think there is interest, definitely. I'd like to see it, and it is practically a requirement for longer chains of LEDs/ higher refresh rates.

If my suspicion is correct then I'm wondering if SmartLedsAdapterAsync is suitable for chains of more than a single LED. I could probably modify SmartLedsAdapterAsync::write to write all colors in a single transfer, but that may result in poor cooperative multi-tasking. Ideas?

I don't see any reason it can't work with async. Async does add some latency from bouncing from the wake source to the executor, then to the task, but this is small. The real crux is making sure the async impl is preparing the next chunk such that once the first one finishes the other can immediately start. You will run into this in a blocking application too, if the CPU needs to do other things, but you can get away with it for longer.

I don't know all the details, just loose context based on esp-idf and other smartled impls. You might have to trail blaze a bit here, but I hope it won't be too unwieldy.

[cmumford]

I made an experimental change to pipeline the writes in SmartLedsAdapterAsync::write in cmumford@7674643. This doesn't parallelize much as the RMT buffer is already chunked earlier in the function. In my modified hello_rgb_async app the gap between the RGB data channel writes only shrinks from an average of 20.17 µs to 20.10 µs.

I could alter the implementation to avoid the blocking call to self.prepare_rmt_buffer(iterator). That would improve memory use, but possibly make the problem worse depending on how long that takes. I think the WS2812B driver will tolerate a max of 50 µs between LED data chunks.

Yes, an app using the sync impl can get interrupted, but never during the RMT data writes, so it will always be able to write the pixel data correctly, just not necessarily be able to calculate the LED color data in a reliable way.

I still don't see how the async impl can be relied upon to work for more than a single LED. The daylight between RMT channel writes will always be at the mercy of the other Embassy tasks - at least as long as the Embassy executor is single core. Please LMK if I'm still not seeing the point.

[MabezDev]

I still don't see how the async impl can be relied upon to work for more than a single LED. The daylight between RMT channel writes will always be at the mercy of the other Embassy tasks - at least as long as the Embassy executor is single core. Please LMK if I'm still not seeing the point.

I see the point your getting at for sure. I was merely offering some suggestions. AFAIK, there are no other implementations for the async version of the trait (you can take a look here, maybe they do exist: https://crates.io/crates/smart-leds-trait/reverse_dependencies), hence why I mentioned you might need to do a bit of trail blazing. Maybe it's not possible, but we can try :D.

The daylight between RMT channel writes will always be at the mercy of the other Embassy tasks - at least as long as the Embassy executor is single core

This isn't true. You can use a higher priority interrupt executor which will preempt all other code/tasks/futures. See https://docs.espressif.com/projects/rust/esp-hal-embassy/0.8.1/esp32c6/esp_hal_embassy/struct.InterruptExecutor.html and https://github.com/esp-rs/esp-hal/blob/main/examples/src/bin/embassy_multiprio.rs.

[cmumford]

PR to keep esp-hal RMT driver in RAM: esp-rs/esp-hal#3778

[ahdinosaur]

From esp-rs/esp-hal#4049,

(Using this should also greatly help with esp-rs/esp-hal-community#32, if someone (not me) creates a PR to use async wrapping tx.)

Hi @wisp3rwind, would you be able to describe at a high-level how to approach an "async wrapping tx"? I'm interested for my LED library blinksy. I see esp-hal@1.0.0-rc.1 just got released with the pull request merged, but I'm not sure I understand the changes.

Do the changes mean you can use the async API to write a buffer larger than the RMT memory size, like you could previously do with the blocking API? If so, I think these docs are out-of-date: "The length of sequence cannot exceed the size of the allocated RMT RAM.". Or, are the changes something else?

If this does mean the async API can now do what the blocking API could do, there's still a challenge when you have more LEDs than you have memory to store a buffer of pulses. As I currently turn an entire frame of LED colors into an iterator of RMT pulses, I wonder if there's any recommended way to use these new changes to implement esp-rs/esp-hal#1768.

Thanks for any help, all good if you're too busy. 💜

[wisp3rwind]

From esp-rs/esp-hal#4049,

(Using this should also greatly help with esp-rs/esp-hal-community#32, if someone (not me) creates a PR to use async wrapping tx.)

Hi @wisp3rwind, would you be able to describe at a high-level how to approach an "async wrapping tx"? I'm interested for my LED library blinksy. I see esp-hal@1.0.0-rc.1 just got released with the pull request merged, but I'm not sure I understand the changes.

Do the changes mean you can use the async API to write a buffer larger than the RMT memory size, like you could previously do with the blocking API? If so, I think these docs are out-of-date: "The length of sequence cannot exceed the size of the allocated RMT RAM.". Or, are the changes something else?

Yes, exactly, blocking and async API should now have the same capabilities. That's an oversight in the docs, I'll remove that in one of my next PRs to esp-hal (still have a few things in the queue).

So, what one could do in esp-hal-community is to change the driver to work pretty much the same for async and blocking, i.e. remove the chunking that it currently does.

The one downside that might exist is that with the new design, it's even less well defined what happens when you're late in polling the tx future. (Currently, the gaps between pixels you see in ahdinosaur/blinksy#86)

If this does mean the async API can now do what the blocking API could do, there's still a challenge when you have more LEDs than you have memory to store a buffer of pulses. As I currently turn an entire frame of LED colors into an iterator of RMT pulses, I wonder if there's any recommended way to use these new changes to implement esp-rs/esp-hal#1768.

There's no way right now; you need to have explicit support in the HAL driver to push down the conversion into the very inner loop that writes to the hardware buffer. In fact, Iterators aren't that great, one can come up with a better interface that allows pushing out bits to the hardware in a much tighter loop (i.e that optimizes much better, without requiring unsafe in user code). I have a local prototype for that and will work to upstream it soon, but it's not quite ready. (It works without problems for driving large numbers of LEDs, I just need to rethink the error handling.)

In fact, my usecase is also driving LEDs. I have a crate locally (will push to Github at some point) which seems to share some of the ideas in blinksy (although yours seems to be much more capable and broader in scope). That would probably be a good example for using the upcoming API.

Thanks for any help, all good if you're too busy. 💜

[ahdinosaur]

Thanks @wisp3rwind for clarifying, also thanks for all the work you've done in the RMT driver. ☺️ I look forward to when you publish your LED prototypes, sounds like I can learn a thing or two about more efficient LED driving. If you ever wanted to include any of your ideas into blinksy, please reach out, would love to collaborate.

[Yona-Appletree]

If anyone is curious, I wrote a hacky-but-functional WS2811 RMT-driver for larger LED strips that runs on esp-hal based projects. I built it after running into the current limitations of this project. It would be awesome to get the needed support into esp-hal to do this "right" but that's not something I have the energy for right now.

Full disclosure: I am very new to rust, and my focus is elsewhere, but if anyone wants it, it does work, mostly.

You can find it here:

https://github.com/Yona-Appletree/lpmini2024/blob/main/apps/fw-esp32c3/src/rmt_ws2811_driver.rs

[clarkmcc]

Edit: after running in release mode as recommended here, the delay dropped from 50us to about 1us which resolves the issue.

---

Any update on this, or anything that I can do to help?

Just ran into this issue trying to drive 8 LEDs. You can see the last LED is sticky because the the timing delay in between the first two LEDs is right at the 50us threshold.

IMG_2917.mov

The oscilloscope capture also shows this. The yellow series is the original signal driver, the blue series is DOUT after the first LED and you can see that fairly frequently the first transmission is dropped causing only 7/8 LEDs to receive the signal.

When I switch to use the blocking API, the delay is removed.