ESP32 & ESP8266 I2S timing changes saves memory

[Makuna]

#827

The encoding for the DMA buffer has changed from 4 step cadence to a 3 step cadence by default. So, from 25%/75% to 33%66% pulse to represent 1s and 0s. This saves 25% of the DMA memory.

On ESP32 this is with x1, x8, and x16 channel methods.
On ESP8266 it's just the default I2S (DMA) method that was upgraded. UART methods can't support it.

There is support to select either set, but on single hardware peripheral it can only support either one or the other.

[Makuna]

https://github.com/Makuna/NeoPixelBus/releases/tag/2.8.1

[Makuna]

If you want to use the original cadence, just put this define in before you include NeoPixelBus.h

#define NPB_CONF_4STEP_CADENCE
#include <NeoPixelBus.h>

[blazoncek]

Can you explain in layman's terms what are the caveats?

[Makuna]

I will try 8-)

The main issue is protocol timing of the PWM. Below are some examples to clarify this.

The second issue is complexity of encoding and the time it takes to do so. This is more of issue with larger pixel counts.

• 4 step (4 bits) easily divides into a nibble and thus also in 8bit/16bit/32bit, so some tricks to encode multiple bits in one operation can be done. But it does require 4 bits to represent one bit in the protocol.
• 3 step (3 bits) doesn't divide into 8bit/16bit/32bits. So extra operations are needed to span 8bit aligned elements. (note that this complexity or flexibility also proves that DMX512 could be encoded using this hardware method with minor tweaks). Since this only uses 3 bits to represent one bit in the protocol, it uses 25% less memory in the DMA buffer.

example of timing issue:

The normal period timing for a bit in is 1.25us or 1250ns.
The Pattern defines when the pin is high versus low within this period; and how many steps in the pattern is Cadence.

Old 4 Step Cadence: this period is divided by four to define the available time slices for a pattern, so 312.5ns each

	pattern	timing (h/l)
Bit 0:	1000	312ns / 938ns
Bit 1:	1110	938ns / 312ns

New 3 Step Cadence: the period is divided by three to define the available time slices for a pattern, so 416.666 ns each

	pattern	timing (h/l)
Bit 0:	100	417ns / 833ns
Bit 1:	110	833ns / 417ns

Compared to RMT (or spec) for WS2812x: ¹

	timing (h/l)
Bit 0:	400ns / 850ns
Bit 1:	800ns / 450ns

Compared to RMT (or spec) for WS2811: ²

	timing (h/l)
Bit 0:	300ns / 950ns
Bit 1:	900ns / 350ns

Footnotes

1. For the WS2812x the newer cadence is closer to the spec than the older one. ↩

2. For WS2811, the newer cadence is worse than the old one. ↩

[blazoncek]

Interesting. Thank you.
Are these inexact "cadences" possible cause for flicker? I.e. with 4 step WS2812 may be prone to flicker more than WS2811 but with 3 step it will be less prone to but WS2811 may be more prone to flicker.

As (normally) users do not change LED types "on the fly" why not choose best cadence on LED type? I know you support wide range of MCUs but some (constrained ones) are getting old and more and more people are using newer ones with enough RAM so choosing the optimum cadence may be worth the sacrifices of RAM. Just thinking out loud.

[Makuna]

I can support it, and not difficult. But just another set in the matrix of methods. The new ESP32S3 LCD parallel is the only one that doesn't have a 4 step cadence at all, as the pull only had 3 step. I would have to implement it.

The problem is the cadence also effects the speed of the peripheral. The 3 Step has to run slower to take the same time as 4 steps. So, you can't mix 4 & 3 on the same peripheral, like any of the parallel methods. Except RMT of course as that uses the specific RMT encoding.

You can add an issue to track supporting both without compilation flag.