Skip to content
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

Update rmt translator #3629

Merged
merged 6 commits into from
Feb 7, 2024
Merged

Conversation

docbacardi
Copy link

@docbacardi docbacardi commented Feb 4, 2024

Fixes #3628 .

  • This PR is for the dev-esp32 branch rather than for the release branch.
  • This PR is compliant with the other contributing guidelines as well (if not, please describe why).
  • I have thoroughly tested my contribution.
  • The code changes are reflected in the documentation at docs/*.

This set of patches adds optional parameters to the WS2812 module to set the duration of the reset signal and the duration for the high and low phase of the 0 and 1 symbols. This allows to control many other RGB LEDs besides the WS2812.
The main intention of this patch is to control the RGB LED of the ESP32-C3 dev kit.

The number of buffers required for optimal operation should be selected
by the ws2812 module, not the caller.
This patch adds compatibility for different RGB LEDS besides the WS2812.
ESP evaluation boards like the ESP32-C3-DevKitM-1 use an SK68XXMINI-HS
RGB LED which does not respond to the timings of this module.
The patch adds optional parameters for the bit timings to the write
function. If the new parameters are not supplied, the old values are used.
An example for the SK68XXMINI-HS is provided in the documentation.
The old RMT translator was not able to split the bits of the source
data into the size requested by the RMT transmitter. Either all 8 bits
of an input byte were translated or none.
The new routine removes the restriction by delivering exactly the
requested amount of data to the transmitter, which results in a more
balanced buffering of translated data under load.
This patch introduces a new optional parameter for the reset time
in the RGB LED communication. The default is 51.2 microseconds. A
value of 0 sends no reset signal, which allows a small optimisation
for consecutive write commands.

Please note that the reset time of the old code should be 50
microseconds, as the define WS2812_DURATION_RESET suggested. Due to the
restrictions of the old RMT translator routine, it was slightly
increased to 51.2 microseconds. This patch keeps the value of 51.2
microseconds to be as compatible as possible.
Place all RMT channels in a group to minimize the time drift between
the signals. Please note that this feature is not available on all
platforms.
@@ -44,6 +52,10 @@ ws2812.write({pin = 4, data = string.char(255, 0, 0, 255, 0, 0)},
{pin = 14, data = string.char(0, 255, 0, 0, 255, 0)}) -- turn the two first RGB leds to green on the first strip and red on the second strip
```

```lua
ws2812.write({pin = 8, reset = 800, t0h = 3, t0l = 9, t1h = 6, t1l = 6, data = string.char(1, 0, 0)}) -- turn the SK6812 RGB led on the ESP32-C3-DevKitM-1 to green
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does this work -- I would have thought that using 255 as the intensity rather than 1. Also, what is the color ordering for the SK6812? You set the first value to get green, which implies that it isn't RGB.

Copy link
Author

@docbacardi docbacardi Feb 7, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The SK6812 is a very bright LED. A value of 1 is clearly visible. Setting it to 255 was painful for my eyes.

You are correct, the color ordering is really green - red - blue, see end of page 6 in the data sheet here. Thanks, the patch is updated.

However the WS2812 has the same color ordering (see here, page 5). The APA104 is the only LED in the list using RGB color ordering (see here, page5). The current documentation uses the term "RGB" or "RGBW" for all of them:

Send data to up to 8 led strip using its native format which is generally Green,Red,Blue for RGB strips and Green,Red,Blue,White for RGBW strips.

If you agree that this is a bit confusing I will open a new ticket for it.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah -- that makes sense

The SK6812 expects the data for the green LED first, then red and
finally blue. It should be described as a GRB LED.
@pjsg pjsg merged commit 14cdff1 into nodemcu:dev-esp32 Feb 7, 2024
16 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants