Open MartinNohr opened 2 years ago
MartinNohr
commented
2 years ago I connected my 'scope to the data line. I can see that the data stops after about 5 LED's worth of data when using 3.5 version. When I switch back to 3.3 and compile again the data for all 144 LED's is sent again. No other software changes are made.
smurphyUSI
commented
2 years ago Version 3.3 was the first version to deal with some off the goofy esp32 behvaiours/bugs. I suspect that a neccessary code code for the esp32 between versions is what is cause the issue. @samguyer would likely know what this is about.
MartinNohr
commented
2 years ago I'd be glad to help in any way I can. I'm a fairly experienced software/hardware developer. I'm retired, but I still have my oscilloscope and experience in debugging! I haven't looked at any of the code yet, mostly because it has always worked flawlessly for me ever since I started using it. The TTGO is somewhat popular I think, so this issue should be resolved.
samguyer
commented
2 years ago @MartinNohr I have seen a few cases where people are calling FastLED.show() too fast, which causes the LEDs to get confused about when to "latch" and actually show the new color. Try adding a very short delay after each call to show() -- like 5ms is fine. And avoid using FastLED.delay(), which calls show under the hood. Let me know how it goes!
MartinNohr
commented
2 years ago I don't use FastLED.delay() anywhere in my code. I have several seconds between calls to .show(); I just did notice something strange though. I put a call to .show() in the setup code and it works. When I then call it later in my code it only write the first 5 or 6 LED's, I can see the short data burst on my 'scope. I tried again with 3.3 and it works. It stops working with 3.4. But now I'm suspicious that I'm doing something wrong somewhere. Any suggestions to check?
MartinNohr
commented
2 years ago Sorry, accidentally closed this. Trackpad...
RococoN8R
commented
2 years ago It's suggest sharing the code, or a shortened test version. Much easier to find issues versus throwing darts blindly.Sent from my phone... please excuse the topys.On Sep 24, 2022 1:41 PM, MartinNohr @.***> wrote: Sorry, accidentally closed this. Trackpad...
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you are subscribed to this thread.Message ID: @.***>
MartinNohr
commented
2 years ago I figured out what causes it, but I don't know why it would be a problem. I started a task during startup that was pinned to core0. This task terminates after running an LED test, just to make sure all the LED's light. The entire strip lights up during this test. After this the main code will only display the first 5 LED's. The main task is running on core1. I changed the startup task to use core1 and now it works. Does that make any sense at all given that v3.3 worked fine? Glad to share the code, but since it is running on my custom PCB it might not be that easy to test. The code is here: https://github.com/MartinNohr/MagicImageWand It's not trivial. I'd be glad to share a PCB if somebody really wants to get to the bottom of the issue, but it is working now that I pinned the start test code to core1. FastLED isn't doing anything with tasks and cores, is it? Note also that I delete that start test task after it lights all the LED's, there are not further writes to the LED's until a button is pressed.
RococoN8R
commented
2 years ago Core 0 is used for WiFi, Bluetooth, etc. FastLED has very challenging timing constraints during show(), and you're likely getting interrupted. Why are you pinning to a core?Sent from my phone... please excuse the topys.On Sep 24, 2022 4:09 PM, MartinNohr @.***> wrote: I figured out what causes it, but I don't know why it would be a problem. I started a task during startup that was pinned to core0. This task terminates after running an LED test, just to make sure all the LED's light. The entire strip lights up during this test. After this the main code will only display the first 5 LED's. The main task is running on core1. I changed the startup task to use core1 and now it works. Does that make any sense at all given that v3.3 worked fine? Glad to share the code, but since it is running on my custom PCB it might not be that easy to test. The code is here: https://github.com/MartinNohr/MagicImageWand It's not trivial. I'd be glad to share a PCB if somebody really wants to get to the bottom of the issue, but it is working now that I pinned the start test code to core1. FastLED isn't doing anything with tasks and cores, is it? Note also that I delete that start test task after it lights all the LED's, there are not further writes to the LED's until a button is pressed.
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you commented.Message ID: @.***>
MartinNohr
commented
2 years ago I didn't know WiFi was using core 0, thanks for the info. I do have a server running on WiFi for my system. But still, it is curious that version 3.3 worked. I have tested several times without any changes except the FastLED library version, so something must have changed to uncover this issue. The reason I pinned it to core 0 was because I was trying to speed things up during boot. I started the LED test task while the SD card and other things were being started, among them the WiFi server. I was just trying to make it look like it booted quicker by having the UI appear much faster. And it did do that!
samguyer
commented
1 year ago @MartinNohr Thanks for the new information. I have a syncing feeling that there is something in the driver that remembers which core was used the first time show() is called. I'm going to dig into it and see.
MartinNohr
commented
1 year ago Interesting, that might explain what I saw also, and it suggests a different approach to solve the problem I saw.
I updated to the latest library and now only the first 5 LEDs work. I was using version 3.3.3 before and it has worked perfectly for over a year. I loaded 3.3.3 again with no other changes and it works perfectly again. What should I do to try and figure out the problem? The memory array is being loaded correctly; it only fails on FastLED.show();. I'm running on esp32, a TTGO T-Display. The output goes through a level translator for 5V output, the TTGO is mounted on a custom designed PCB. I would be happy to send you one if that would help.