-
-
Notifications
You must be signed in to change notification settings - Fork 261
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Alternative serial send encoding using a smaller send buffer #439
Comments
Test Sketch for timing and some results... A strip of 256 pixels of RGB will break even on memory for the large lookup table versus data saved in the output buffer. 128 pixels = 533us versus 97us lookup
|
Today, hardware is used in several methods that relies on using serial peripheral support, like UART, I2S, or SPI. These encode the pulse of a single data bit as four serial bits for the period. This requires a send buffer of 4x the size of the pixel data to send the data.
0b1000 => a 1 bit pulse
0b1110 => a 0 bit pulse
This allows the timing to define the total pulse period and then with 3 relative positions that would define the pulse width. These positions would be at 25%, 50%, and 75% of the period. We ignore 0% and 100% as they won't generate pulses.
This fits many of the NeoPixel pulse data protocol timing well.
But there are cases in newer LEDs that require more precise timing that is based on 1/3rd of the cycle rather than 1/4th.
An alternate to supplement but not replace the above is to use 3 serial bits. This would also require only 3x the buffer size for the pixels.
0b100 => a 1 bit pulse
0b110 => a 0 bit pulse
This allows the timing to define the total pulse period and then with 2 relative positions that would define the pulse width. These positions would be at 33% and 66% of the period. We ignore 0% and 100% as they won't generate pulses.
Encoding will either require a larger lookup table of 256 entries of 24bits; or a function that is run for each byte to encode it into 3 send buffer bytes.
That function would be like the following where the returned values lower 24 bits would then copied to the send buffer ...
The text was updated successfully, but these errors were encountered: