v17.0.0-dev causing flickering 1 to 2 pixels at end of segment, v0.15.3 works fine

[gregcrago]

What happened?

Build 2605011 (v17) flickering 1 to 2 pixels at the end of segment (driving 283 pixels of 300 pixel strip and noticed 1 to 2 pixels flickering beyond end of segment. Re-flashed with build 2508020 (v0.15.3) and rock solid, no other changes. WS2812B (BTF-Lighting). Color sequence GRB. Processor is ESP32-C3. Driving with 2.4A powersupply with brightness failry low (not over driving). No power injection at enf of striip

To Reproduce Bug

See above

Expected Behavior

Build 2605011 should not cause pixels beyond end of segment to flicker. Build 2508020 does not cause flicker beyond end of segment

Install Method

Binary from WLED.me

What version of WLED?

Wled 17.0.0-dev (2605011)

Which microcontroller/board are you seeing the problem on?

ESP32-C3

Relevant log/trace output

Anything else?

No response

Code of Conduct

• I agree to follow this project's Code of Conduct

[softhack007]

driving 283 pixels of 300 pixel strip

@gregcrago

• how did you configure your strip in LEDs settings? 300 pixels total, or 283 ?
• if you add a second segment for the remaining LEDs (283 thru 300) and set the segment to solid black (not "off"), does that cure the flickering?

[gregcrago]

Total LED=300, Segment 0 (0-283)
Tested with Segment 0 (0-283) set to White (brightness low), Segment 1 (284-300) set to BLACK and still saw 1-2 pixels beyond still flickering. Then set Segment 1 (284-300) to BLUE and saw WHITE flicker 1 to 2 pixels into BLUE segment. Shifted Segment 0 to 0-273) and the Flicker FOLLOWED beyone the end of Segnemt 0, Set Segment 1 to (274-300) and could see Flicker at the Start of Segment 1 (274-300), No flicker with build (2508020)

[willmmiles]

Flickering with ESP32-C3 is most likely to caused by RMT interrupt latency. (Related issues: #4389 - fixed for all other platforms but C3, #5371). When a latency-related glitch occurs, the typical impact is that LED data is "shifted down", resulting in incorrect colors inside the segment and unexpected lighting of LEDs past the end as they now receive some of those shifted bits.

All releases are vulnerable, but the impact on any individual configuration is highly sensitive to specific timing of network event processing (the chief source of disturbing interrupts) and handler delays. (Or to put it another way: different builds affect users in unpredictable ways as the code ends up being laid out differently in the flash.)

Sorry - this one is a very deep issue that keeps getting pushed back in my queue as it's difficult to debug. Getting further needs custom builds of the underlying ESP-IDF software platform, which are a bit of a pain to set up. (The good news is that we're working on that as part of the "V5" migration #4838, as other features require it too but it's a complex process.)

[DedeHai]

@willmmiles it kind of raises the question, why the driver was never switched to I2S - I deliberately did not use that one in my new driver to have it available for mic input.
Would bit-banging the full output work on a C3? It is something I was wondering yesterday - if it's allwoed to block the CPU for a full frame to be pushed out it may be a viable option.

[willmmiles]

@willmmiles it kind of raises the question, why the driver was never switched to I2S - I deliberately did not use that one in my new driver to have it available for mic input.

I think that's why - the one I2S channel is reserved for AR.

Would bit-banging the full output work on a C3? It is something I was wondering yesterday - if it's allwoed to block the CPU for a full frame to be pushed out it may be a viable option.

I think bitbanging would be fine -- really we should offer it as a user choice on top of RMT and I2S. The big-banging driver is interrupt safe - it publishes each individual LED with interrupts disabled, then polls for interrupts in between LEDs, keeping both the latency down and automatically restarting at the beginning of the strip if an ISR blows the timing budget.

Certainly we can try it and see!

[DedeHai]

I think that's why - the one I2S channel is reserved for AR.

the S2 is using it for LED outputs. It does have 4 RMT channels though.

I only looked at the BB driver of NPB for ESP8266 and at the SPI BB drivers - both were not implemented as well as they could be - I need to check the C3 version and if it is any good in practice.

[willmmiles]

I only looked at the BB driver of NPB for ESP8266 and at the SPI BB drivers - both were not implemented as well as they could be - I need to check the C3 version and if it is any good in practice.

The CPU bitbang driver is the same code for all ESP32s and ESP8266. What did you find odd about it? The mask shift logic seemed backwards to me, but it works fine and I didn't think it was worth suggesting changing it as a newcomer to that repo.

[DedeHai]

What I find a bit lacking in the NPB implementation is that the BB driver does sequential processing of strips - they could be clocked out in parallel. I did such an implementation many years ago in assembly for a STM32 and it worked quite well. Apart from that the implementation is solid.
For the SPI BB however it uses digitalWrite() which is very slow. I implemented it using direct register writes making it much faster in my new driver.

[willmmiles]

What I find a bit lacking in the NPB implementation is that the BB driver does sequential processing of strips - they could be clocked out in parallel.

True but complex -- that can only be done between strips that have both identical timings and identical LED word lengths. The trick for flicker-free rendering is polling for interrupts in full knowledge of LED word boundaries, so each individual LED is guaranteed to be output uninterrupted. That way interrupt processing never causes visible corruption -- the worst that can happen is you miss the reset interval (which is much longer than a bit interval) and have to start over.

To be fair, though, most multi-strip cases do tend to use the same lights on all outputs. We might be able to do better in the new driver model with a back-end mapping pass. NPB doesn't have a good solution for organizing shared back-end contexts.

[DedeHai]

True but complex -- that can only be done between strips that have both identical timings and identical LED word lengths

that is true, I would even restrict it to "same type" just like the other parallel outs (I2S, LCD)