-
Notifications
You must be signed in to change notification settings - Fork 898
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
First write to WS2812 Led 0 sets green to 0xff (seen on RP2040 boards) #4251
Comments
Note: This isn't about resetting the leds (since they are reset on powerup) but about being able to change them immediately after power on. |
How much delay do you need here to fix the problem?
I'm not sure what a correct fix would be: this sounds like a problem that depends on the exact system so I'm hesitant to put in a delay without understanding the problem. Also, usually these LEDs start up black? I've seen exceptions but most of them are black when powering on. |
The delay was for me to bodge it by resetting the leds after they have been switched on in error I have a version of the code below that may help - it switches the leds on and off. I then recorded the result on resetting it several times using the Waveshare RP2040 Zero (not the keyboard):
I then swapped the On and Off round and recorded the resets (i.e. On first then Off):
I then removed the first 1 second delay and ran again:
And then swapped back to Off then On (with no initial delay):
I tried a plain 1 second delay at the beginning of main - still incorrect led lit after startup beginning
I also tried a delay after configuring the Pin before write the leds - no joy - maybe the initialisation is incorrectly starting comms with the leds?
I know - so strange they are green/yellow/red more often than black. They are black if I don't access them?! |
Another experiment: Here's the code this time there's a half second delay before setting the leds Off. The result is that many resets show Green (then go off), less often the leds are off.
However, if second delay is removed, then the behaviour changes:
Now, resets get Green - and STAY GREEN, most of the time, sometimes they are black. This looks to me like the led write can't cope with the traffic... |
At least from what I can tell, this is something related to your specific hardware @andrewfstratton not TinyGo itself. Or perhaps related to the ws2812 driver implementation in https://github.com/tinygo-org/drivers/tree/release/ws2812 |
So I tried this with a There appear to be two issues here and therefore this issue may need splitting: Issue 1 : After a reset, the first write to leds, sets led 0 to green incorrectly Please see the code further down... I get the following behaviour:
If I uncomment the
|
I've discovered that the first WS2812 write after power off or reset writes green as 0xff (or a high value - it's hard to be sure) to led 0 instead of the green value given - red and blue values are still set. e.g. in the code below - both led 0 and led 1 should show blue after reset, but led 0 show turquoise and led 1 shows blue. Note: I didn't use 0xff to protect my eyes
|
This sounds like you have something wrong with your wiring.
See https://learn.adafruit.com/adafruit-neopixel-uberguide/basic-connections for a more extensive guide. I'm running a bunch of WS2812 LEDs every night in a project of mine, and they're powered using a rp2040. So that combination most certainly works for me. |
These are all onboard rgb leds - 4 different board types with two different manufacturers. Power might be an issue but seems unlikely with one RGB led and the issue occurring on reset and power on - and the arduino C code works fine... Please could you try my last listing and see what happens? |
I didn't read all the topics. |
Did a quick test and I can confirm that the first write results in some weird colors. Subsequent writes work fine however. This will need a bit more investigation to see what's going on. But a workaround would be something like this for the first write: led.WriteColors(colours[:])
time.Sleep(time.Millisecond * 20)
led.WriteColors(colours[:]) |
My best guess would be that the first time the code runs, not all the code has been loaded into the flash cache, slowing down the assembly and messing up the timing of the signal. I'm not sure what the best way would be to fix that. One solution would be to place the code in RAM, thereby taking up precious RAM (though not so precious on the rp2040). Another solution would be some sort of prefetch, but unfortunately the rp2040 doesn't support that. The easiest solution would probably to send data of a single pixel (or even a single byte), sleep for ~10ms, and then send the real data. Like this: led.Write([]byte{0x00})
time.Sleep(time.Millisecond * 10)
led.WriteColors(colours[:]) (This might still result in a flash sometimes and I'm not sure we should add this to the ws2812 driver because it's chip-specific). |
I'm facing the same problem. I use Pico W and WS2812. When trying to record colors I get the first green pixel. And the value itself is also written (if I write red, the first pixel will be yellow). The hack with a delay after the first writing of the zero bit works, but it has to be inserted before each update. During this pause, the pixel shines green, which turns any animation into a green strobe. Experimentally I found out that a 3ms delay is enough, but it's still not what I want to get. |
I have experienced the same phenomenon. I am using the xiao-rp2040 and an external WS2812 compatible SK6812MINI-E. I captured the waveform of the DIN. The first image shows the result of sending a single black command. The second image shows the result of sending two black commands. From this, it seems that the timing is not well controlled at the beginning of the first {black}{black, black} |
Heads up, latest commit in PIO repository has a working WS2812B implementation. I've tested it on a strip and it works pretty well, with or without DMA. https://github.com/tinygo-org/pio/blob/main/rp2-pio/examples/ws2812b/main.go |
I cannot get the WS2812 leds to be set correctly immediately following a reset - e.g. the code below should switch all the leds off.
The code is a cut down version of the problem, which can be run on Waveshare RP2040 Zero and One - the Zero shows a green led and the one shows a red led (other leds do not appear to be lit).
There is some delay needed before leds can be set. I have similar issues with the Waveshare RP2400 3 Key keyboard - and have put a delay in to fix (hack) the problem - please see https://github.com/andrewfstratton/rp3keys/tree/d834fcf139aed9b9c6121a47644f0b21a8ff2d0e
With this delay, the red led does briefly come on, but is then reset - it seems that setting the leds before this delay will set them incorrectly.
The text was updated successfully, but these errors were encountered: