Panic when driving larger matrixes (one long strip) on 32MB 8MB ESP32-S3-DevKitC1 #580
Comments
|
@GameTec-live The hastebin link at the end of your description leads to an empty page with a blinking cursor in my browser. |
oh, weird... ill reupload later... (when I'm home) |
|
crashlog.log |
|
Please build debug, as instructed, and be sure you're running the trace
decode filter. I think most o the flags are already present because I get
them by default.
https://docs.platformio.org/en/latest/core/userguide/device/cmd_monitor.html#filters
platformio/platform-espressif32#105 (comment)
I suspect you're just building opt and not debug.
…On Thu, Jan 4, 2024 at 1:39 PM GameTec-live ***@***.***> wrote:
crashlog.log
<https://github.com/PlummersSoftwareLLC/NightDriverStrip/files/13834734/crashlog.log>
Sorry for the late reply, but here you go...
—
Reply to this email directly, view it on GitHub
<#580 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ACCSD36TAZ5QBUHW5EBIVTTYM4APBAVCNFSM6AAAAABBFMSILWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQNZXGY3DAMJRGI>
.
You are receiving this because you are subscribed to this thread.Message
ID: ***@***.***
com>
|
|
changed heres the new log: |
|
That's indicating a problem in a library we use, somewher around:
https://github.com/FastLED/FastLED/blob/09c5fb8f74c43191974c09e1f31edda8281eab7e/src/platforms/esp/32/clockless_rmt_esp32.cpp#L503
You're going to have to get a debugger (or other stone-banging techniques)
in there to see if mCur is walking past the end of mPixelData[]
(questioning mSize corruption?) or some other zany behaviour.
I don't recognize it and don't see smoking guns on this topic in the
fastled buganizer.
https://github.com/FastLED/FastLED/issues?q=+ESP32RMTController%3A%3AfillNext+
…On Thu, Jan 4, 2024 at 5:00 PM GameTec-live ***@***.***> wrote:
changed build_type under base from release to debug and set monitor_filters
= esp32_exception_decoder under [env:demo]
heres the new
debug-log.log
<https://github.com/PlummersSoftwareLLC/NightDriverStrip/files/13836222/debug-log.log>
log:
—
Reply to this email directly, view it on GitHub
<#580 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ACCSD3YYAWV3WFOXS2FPSF3YM4YAPAVCNFSM6AAAAABBFMSILWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQNZXHA3TQMRXGU>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
|
probably the stupidiest thing youve heard in a while, but.... i do have a pico debug probe (SWD) and cant figure out where im supposed to hook it up... |
|
Dude, you can't imagine the stupid stuff I hear. That's not even on the
list. :-)
There is an embarrassment of debugging options on S3. Picking one may
actually be the hardest part. Espressif has this locked down. Even if you
don't follow all the steps, reading this chapter is worthwhile:
https://docs.espressif.com/projects/esp-idf/en/latest/esp32s3/api-guides/jtag-debugging/#
You could hook up wires for TDO, TDI, TMS, and TCK like a caveman and be
proud of your pico purchase. If you work with lots of micros and have a
good workflow around that, go for it.
https://docs.espressif.com/projects/esp-idf/en/latest/esp32s3/api-guides/jtag-debugging/configure-other-jtag.html
If you don't,
*don't do that.*
"The quickest and most convenient way to start with JTAG debugging is
through a USB cable connected to the D+/D- USB pins of ESP32-S3. No need
for an external JTAG adapter and extra wiring/cable to connect JTAG to
ESP32-S3."
So configure it for the built-in JTAG interface. This may require some
driver fiddling depending on yoru OS. The one downfall of this approach
over a "real" JTAG pod, IMO, is that it resets the connection when the
ESP32 resets, such as when you load new code. This has been fixed in newer
ESP parts like the H2 and C6.
Now here's where I'll get hand-wavy because you surely don't want to do it
the way I do it. (See also: working with dozens of micros.)
I try to use as little of platformio and visual studio as I can because I
want to use the SAME debuggers on as many of those micros as I can. I
understand, however, that Platformio has some pointy-clicky stuff that
automates some of the above like building the openocd config. (So why did I
tell you to read that? Because IMO, a developer should know these things
about our tools.)
This is very Windows-centric, but it gives you the needed debug_FOO and
build_type stuff and a nickel tour of GDB.
https://community.platformio.org/t/how-to-use-jtag-built-in-debugger-of-the-esp32-s3-in-platformio/36042/3
This talks about the platformio doc being wrong/misleading.
https://community.platformio.org/t/esp32-s3-jtag-debugging-over-usb/28182
Looks like the official doc is fixed:
https://docs.platformio.org/en/latest/boards/espressif32/esp32-s3-devkitc-1.html#debugging
The concepts you have to embrace are that OpenOCD is the middle-man. It
uses libusb (or Windows driver stuff) to actually open the debug interface
on the board. It creates a couple of network sockets. IIRC, port 3333 is
the one that GDB does the 'target extended remote:localhost:3333" to
connect to (look all this up...I may be typing crazy talk, but I have the
big picture right) and there's an additional port that you can telnet to
that is, I think, 4444. This lets you talk to the board directly, but you
can also confuse GDB if you, say, change a memory location that happens to
hold a variable and you change it without GDB knowing about it. Be careful.
Once you "get it", I think you really will find that the hardest part is
wading through the redundant documentation of expanations fo
rmanually setting up openocd (for both the SoC and the board) which may be
different for CLI use and Platformio use and the differences in the 'real'
jtag interface and the chip-resident jtag interface and all that. This is
why it's worth reading the whole thing - jumping around and copy-pasting
bits will surely get you in trouble.
There are a lot of moving parts, but the ability to single step, display
variables and stack traces, and set breakpoints is worth its weight in gold
and worth the finicky setup.
Good night, good luck and...
May the source be with you.
RJL
…On Fri, Jan 5, 2024 at 2:20 AM GameTec-live ***@***.***> wrote:
probably the stupidiest thing youve heard in a while, but.... i do have a
pico debug probe (SWD) and cant figure out where im supposed to hook it
up...
—
Reply to this email directly, view it on GitHub
<#580 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ACCSD35GVN36RNONZI6BR4LYM6ZWRAVCNFSM6AAAAABBFMSILWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQNZYGI4TCMZZG4>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
|
Okay, thanks for the help, i managed to get a debugger running (it was a driver issue...)... I don't know what the value of mCur is supposed to be, etc... I'll poke around a bit more and report back... |
|
cant really see anything unusal? (i mean; i also dont know what those values are supposed to be lol) |
|
@GameTec-live Glad to see you got the debugger working, and I appreciate the earlier upload of the debug log. As @robertlipe already indicated, it does show that the actual problem (which is a form of illegal memory access) takes place several levels below "our" code. In fact, the backtrace doesn't even include references to any code that's part of NightDriverStrip. Concerning your last comment, we're obviously not looking over your shoulder, so we can't see what you are looking at. Also, even if we could then figuring out what the cause of the invalid behavior is would effectively require us to debug the dependency libraries involved. Which isn't entirely impossible, but very difficult if we can't ourselves debug trace through the code just before the problem occurs. Without having the hardware and software setup that triggers these crashes available, I therefore think we won't be able to solve this. You could (still) consider raising a bug report in the dependent libraries (Espressif ESP-IDF and/or FastLED) and see if they are able to provide pointers to what's actually behind this. I'll leave this issue open in case someone else runs into the same problem, and may be able to provide additional information that can help get to the root of this. |
|
Yeah, kinda hard to replicate a issue without hardware... Ill open a issue over at FastLED... Thanks for the help though... |
|
hey GameTec-live 20240108_191857.mp4 |
thx for the info, ig ill try that... My matrix is just one long strip though... |
|
altough using the spectrum-elecrow project seems to work, it doesnt help me much as spectrum drives hub whatever its called matrixes and i just have one long strip snaking back and forth... |
|
All of the spectrum builds use a series of strips that zig-zag back and forth as you describe. They can be identified as there is only 1 pin used for output led_pino. The hub75 is currently only used for the Mesmerizer builds that require around 14 output pins depending on what you are doing. Dave does a great job of describing all of this here: https://www.youtube.com/watch?v=COJnlehBcKw&t=224s The video I posted is using a standard zig-zag strip as you describe at 16 pixels high by 48 pixels wide on spectrum build, using the chip you specified. |
|
ah, ok... so ig I will fumble a bit more with spectrum elecrow and try to use that... thanks... |
|
nvm, setting the matrix to the required size crashes elecrow too... |
|
Perhaps if you could articulate exactly what you are trying to accomplish, we might be able to help. As far as I am seeing, this chip is working without any crashes for the spectrum build. While there aren't a lot of spectrum effects here, intend to test it more thoroughly. |
drive my 50x30 matrix (being one long strip) with the new, more powerful ESP32-S3... It works fine with my current, not as powerful ESP32 (afaik its even singlecore?), had to disable nice to haves like the webserver though for it to run a stream from the computer at a decent framerate which im hoping to fix with this a lot more powerful variant... |
|
Stupid question, but can some of the devs or someone more competent than me try and compile demo with a 50x30 matrix? |
|
C3 is DOA for us. Not because it's RISC-V but because it's single core. S2
is LX7 like S3, but it's single core, so that's similarly dead to us.
I think there are configurations that probably could be made to work with
some engineering investment (like cleaning up the multiple threads that are
spin looping) but right now, unless you're willing to drive that effort, we
require the two core models. So no c2, c3,. C6, , h6, or such. P4 is a
contender, but they're not sampling yet and honestly, even when they do, I
expect work in esp-idf and probably all that Arduino code that was dragged
off an 8-bit CPU is going to burst into flames when faced with a 64-bit
system. My anxiousness to tackle that may be proportional to the dev board
price when they're announced.
You want to stay in the LX6 dual core parts like esp32 nothing (Those with
no suffix) but that appears in a ton of packages and modules or the dual
core LX6 like ESP32-S3 in about any id it's forms, but I'd lean to the
n8r16 though the n2r2 and other combinations of flash and ram are fine.
Actually,. You just inspired my local copy to make dual cores a hard
requirement at runtime and probably at compile time.
…On Sun, Feb 11, 2024, 11:52 PM GameTec-live ***@***.***> wrote:
Stupid question, but can some of the devs or someone more competent than
me try and compile demo with a 50x30 matrix?
I tried to compile elecrow, 50x30, similar error. Tried to compile demo
for a seeed studio esp32 c3 (ik, not officially supported) and it's still
the same error (from what it looks like)
Havnt tried a nodemcu (clone) yet as thats currently driving the matrix
and id rather not break it until my replacement mcu works... :/
—
Reply to this email directly, view it on GitHub
<#580 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ACCSD35CLTAYKBL3S6RFOILYTGU3NAVCNFSM6AAAAABBFMSILWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSMZYGA4TQMBVGQ>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
|
Ok, that makes sense then, was just the one I had laying around... Id still be interested if someone else can replicate this issue or if its just me or maybe even a defect MCU... And having a reproducable thing / minimum reproducable example might help speed things up here (or over at fastLED) |
|
Hello [GameTec-live], have looked at your situation a good bit over the last couple of weeks, and do get similar results. While I can approach your matrix size, cannot quite get there. Have a similar problem when trying to use this chip with 4 channel strip effects. Have tried different board define files as well as different memory tables, but still have not solved this problem. While an alternate led program makes both of our build problems work, I would like to get it working here. What I have learned is programs can make use of 16 mb, and the 32mb that these chips support is only useful for storage. Have tried both of our builds with unexpected maker s3 pro, wemos s3, and generic and official builds of esp32-s3 in various memories. Have a wemos d32 pro, and m5stack I'll try our build on next. M5 stack used to work on my build, but suspect that no longer works. Will let you know what I find. |
|
Ah, so it isn't just me XD |
|
@robertlipe while ordering other stuff, i threw in a N16R8, so the 16MB version you apperently use... I still get the same panic... |
|
Seems we're getting no traction with FastLED looking into this.
I'm about to be on the road through the end of the month, so I can't commit
to looking into this in the short term, though I know this has been
simmering a long time. Looks like I may have to debug FastLED. 😐
Is there a repro case for this here? Does it take a while to bonk or is it
close to immediate?
…On Wed, May 15, 2024, 2:20 PM GameTec-live ***@***.***> wrote:
@robertlipe <https://github.com/robertlipe> while ordering other stuff, i
threw in a N16R8, so the 16MB version you apperently use... I still get the
same panic...
—
Reply to this email directly, view it on GitHub
<#580 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ACCSD33WTSEGOIIFGP4PVHLZCOYRFAVCNFSM6AAAAABBFMSILWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCMJTGI4TQMBWGY>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
|
The S3 LEDSTRIP project with the onboard LED will fault out reliably. Only problem is the S3 reboots without showing a call stack or exception chain!
- Dave
… On May 15, 2024, at 12:43 PM, Robert Lipe ***@***.***> wrote:
Seems we're getting no traction with FastLED looking into this.
I'm about to be on the road through the end of the month, so I can't commit
to looking into this in the short term, though I know this has been
simmering a long time. Looks like I may have to debug FastLED. 😐
Is there a repro case for this here? Does it take a while to bonk or is it
close to immediate?
On Wed, May 15, 2024, 2:20 PM GameTec-live ***@***.***> wrote:
> @robertlipe <https://github.com/robertlipe> while ordering other stuff, i
> threw in a N16R8, so the 16MB version you apperently use... I still get the
> same panic...
>
> —
> Reply to this email directly, view it on GitHub
> <#580 (comment)>,
> or unsubscribe
> <https://github.com/notifications/unsubscribe-auth/ACCSD33WTSEGOIIFGP4PVHLZCOYRFAVCNFSM6AAAAABBFMSILWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCMJTGI4TQMBWGY>
> .
> You are receiving this because you were mentioned.Message ID:
> ***@***.***>
>
—
Reply to this email directly, view it on GitHub <#580 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AA4HCF4KWJ3YWMMBXNBPUQLZCO3FRAVCNFSM6AAAAABBFMSILWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCMJTGMZTCMZYGQ>.
You are receiving this because you are subscribed to this thread.
|
|
@rbergen you seem to be misremembering, as atleast for me on my 2 MCUs, with PSRAM enabled, driving a smaller matrix (eg 10x10) boots up perfectly, etc... |
|
No, I'm not - or at least not in that way. The point is that there are now 3 problems with (certain) S3 boards we know of. Your problem - that being the one this issue concerns primarily - is the second problem in @robertlipe's summary. There are two others, though. One is the first Robert mentions, the other the one I mentioned in my previous comment. |
|
Either we have a missing qualifier on #3 or it's behind us. I run S3's
almost exclusively, in a variety of configurations (not all), except for
Mesmerizer, and just don't see that. You just fixed #1 on my list. That
means we have only Gametec's still live and in play, right?
If we track problems we *used to have*, I'm sure we'll all lose our minds
even more quickly. Since we don't really do releases with version numbers
and git syntax of "git checkout `git rev-list -n 1 --first-parent
--before="2009-07-27 13:37" master`" is no fun to try to walk backward a
quarter or a month at a time and try to find a repro case and a time when
it was live, let's just take that out of play.
We have a moderate number of people using S3's in strip configurations.
Gametec's is special because it only shows up with 'lots' of LEDs involved
- even on a single controller, according to the title of this thread.
It was the posts from May 15 that muddied the water (at least my own mental
mud) that #1 (Dave's observed problem) and #2 (Gametec's) were related.
Problem #1 was just using a configuration for a different board that, at
best, was an unused pin on other boards that happens to be used for the
memory controller on S3. Maybe we could subclass/wrap the cases calling
gpio_pin_foo* and trap the cases of using the pins reserved for the
PSRAM/PSROM controller IF either filesystem or PSRAM_ENALBLED are set.
I'm soon on the road again, this time through the end of the month, but
will try to pick this one up sometime during my return. Prschguy has
replicated the results. Apparently a build of Spectrum effects on a board
with an S3 configuration with just the size run up to 50x30 (sidebar:
knowing that the frame rate will be terrible. That's too many bulbs on one
800khz bus...) is enough to crash it and it crashes almost immediately.
Right, guys?
…On Mon, May 20, 2024 at 4:24 AM Rutger van Bergen ***@***.***> wrote:
No, I'm not - or at least not in that way. The point is that there are now
3 problems with (certain) S3 boards we know of. Your problem - that being
the one this issue concerns primarily - is the second problem in
@robertlipe <https://github.com/robertlipe>'s summary. There are two
others, though. One is the first Robert mentions, the other the one I
mentioned in my previous comment.
—
Reply to this email directly, view it on GitHub
<#580 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ACCSD35IMJQPFNYXM7NSOBTZDG6NZAVCNFSM6AAAAABBFMSILWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCMRQGA2DINBSHA>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
Based on what you say in the rest of your comment, that's quite likely true.
That may be true for some, many or most, but not me. I need to keep some record of problems we used to have to retain my sanity. If only because some "solved" problems have the unpleasant habit of rearing their heads again sometime later. But, I can be quiet about it if that's generally preferred. :) |
|
We should certainly have a bug/issue to track this. If it never manifests again, we can close or ignore it, but shouldn’t forget about it!
- Dave
… On May 20, 2024, at 6:31 AM, Rutger van Bergen ***@***.***> wrote:
That means we have only Gametec's still live and in play, right?
Based on what you say in the rest of your comment, that's quite likely true.
If we track problems we used to have, I'm sure we'll all lose our minds even more quickly.
That may be true for some, many or most, but not me. I need to keep some record of problems we used to have to retain my sanity. If only because some "solved" problems have the unpleasant habit of rearing their heads again sometime later.
But, I can be quiet about it if that's generally preferred. :)
—
Reply to this email directly, view it on GitHub <#580 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AA4HCF3C36MZPO2NAWADHUTZDH3JNAVCNFSM6AAAAABBFMSILWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCMRQGQ3DQNRSGI>.
You are receiving this because you commented.
|
|
There has been one for months. It's
#580
...and it's the very one you're commenting on. (Like me, you're probably
reading this all through the email gateway and it can be difficult to see
the origins of long-running discussions sometimes.)
There's a sister issue open in FastLED because I'm willing to be moderate
money that this is _actually_ an issue inside FastLED, but FastLED has a
tough struggle in their issue queue and a preference for working on 8-bit
micros. :-/
Also, Dave, I'm not saying that we shouldn't have some institutional memory
of such things. (OTOH, we three main devs fix things all the time without
opening issues on the bugs we've fixed...) I'm just trying to focus this
specific list of things to things that actually need developer attention
instead of a bucket of problems that's ever been observed on an S3.
It was the mention of what we're now calling "#1/Dave's problem" on this
open issue (#580 - the one about "lots of leds" (LOL?)) that made me first
think it was thought to be the same issue and that took the whole
discussion a little off track. No harm now that we have it all refocused.
On Mon, May 20, 2024 at 8:36 AM David W Plummer ***@***.***>
wrote:
… We should certainly have a bug/issue to track this. If it never manifests
again, we can close or ignore it, but shouldn’t forget about it!
- Dave
> On May 20, 2024, at 6:31 AM, Rutger van Bergen ***@***.***> wrote:
>
>
> That means we have only Gametec's still live and in play, right?
>
> Based on what you say in the rest of your comment, that's quite likely
true.
>
> If we track problems we used to have, I'm sure we'll all lose our minds
even more quickly.
>
> That may be true for some, many or most, but not me. I need to keep some
record of problems we used to have to retain my sanity. If only because
some "solved" problems have the unpleasant habit of rearing their heads
again sometime later.
>
> But, I can be quiet about it if that's generally preferred. :)
>
> —
> Reply to this email directly, view it on GitHub <
#580 (comment)>,
or unsubscribe <
https://github.com/notifications/unsubscribe-auth/AA4HCF3C36MZPO2NAWADHUTZDH3JNAVCNFSM6AAAAABBFMSILWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCMRQGQ3DQNRSGI>.
> You are receiving this because you commented.
>
—
Reply to this email directly, view it on GitHub
<#580 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ACCSD354SIAZKKCCG4P73S3ZDH34DAVCNFSM6AAAAABBFMSILWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCMRQGQ3TONJQGM>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
|
Dont want to be annoying (greatly apprecite the work your doing here), but has there been any progress on this issue? |
|
Sorry, I’m not up to speed on this one, can someone refresh my memory?
… On Jun 30, 2024, at 11:41 AM, GameTec-live ***@***.***> wrote:
Dont want to be annoying (greatly apprecite the work your doing here), but has there been any progress on this issue?
—
Reply to this email directly, view it on GitHub <#580 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AA4HCF4HHST66JBSWGLE4FDZKBGNJAVCNFSM6AAAAABBFMSILWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCOJYGY2DOMBSHA>.
You are receiving this because you commented.
|
|
Earlier today, I meant to ping this thread. I can't find it right now, but
somewhere in recent reading of release notes (esp-idf?
espressif32-arduino?) I saw a commit that looked like it might have been
related to this.
I don't think it was espressif/arduino-esp32#9906
but maybe it was. (We're not neopixel, but the code path isn't totally
DISsimilar.)
I remember thinking that if something like an SPI read to the filesystem
happened while the RMT DMA was in progress (or vice versa) that the code
would trample itself when under heavy load and crash. It was more likely to
occur under heavy RMT/SPI use (check!) and it was more likely to happen on
the S3 (check!)
I don't remember if the fix was in arduino-espressif (and whether it was
2.x, which we use, or 3.x, which we currently can't) or in esp-idf. The
ecosystem is a bit messy right now as they work through updating the world
to the slightly incompatible arduino-espressif 3.x.
I recognize this is a bit incoherent (sorry) but sometime in the last 12
hours, I remember seeing a fix in upstream/related code that looked like it
MIGHT be related to this.
I'm about to crash, but there may be some recent progress in SOME upstream
something that might have helped.
Unfortunately, though, FastLED seems to have fundamental issues under load.
See, e.g., FastLED/FastLED#1438
On Sun, Jun 30, 2024 at 1:53 PM David W Plummer ***@***.***>
wrote:
… Sorry, I’m not up to speed on this one, can someone refresh my memory?
> On Jun 30, 2024, at 11:41 AM, GameTec-live ***@***.***> wrote:
>
>
> Dont want to be annoying (greatly apprecite the work your doing here),
but has there been any progress on this issue?
>
> —
> Reply to this email directly, view it on GitHub <
#580 (comment)>,
or unsubscribe <
https://github.com/notifications/unsubscribe-auth/AA4HCF4HHST66JBSWGLE4FDZKBGNJAVCNFSM6AAAAABBFMSILWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCOJYGY2DOMBSHA>.
> You are receiving this because you commented.
>
—
Reply to this email directly, view it on GitHub
<#580 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ACCSD32WQ3IMSPJ4JMI2OALZKBH3LAVCNFSM6AAAAABBFMSILWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCOJYGY2DSOJQGE>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
|
So progress but also not? fun Thanks for the update though |
|
As the FastLED issue has been closed unceremoniously last week, I decided to try it again. Cloned the repo again, made the required changes, built, uploaded aaaand... Panic... Yaaay... |
|
That's obviously disappointing. "Made the required changes" includes making sure PlatformIO pulls in the right version of FastLED? I don't have the code in front of me, but I half-remember the FastLED version was pinned. |
|
In the PIO logs it said that it pulled version 3.7.5 (or whatever the latest version is) |
|
Thanks for checking. Well, I guess that settles that then. In the sense that it doesn't. |
|
😂 yep, sadly lol |
|
You can reopen the issue. Zack's trying to burn down the list of ancient
bugreports that have been open for up to 8 years and apparently just cut
too deeply. Be prepared to build up a test case that repros this in "raw"
FastLED, though.
It's increasingly time to replace FastLED with with Makuna NeoPixel or
maybe I2SClocklessLedDriver. Maybe. I'm leaning toward the former.
But given the requirement of building and running every combination, I
cannot undertake that here. I'll probably eventually do it in a fork and
get "advanced" features like RGBWW, changing pin numbers and strip types
without recompiling, etc.
…On Thu, Sep 5, 2024 at 5:49 AM GameTec-live ***@***.***> wrote:
😂 yep, sadly lol
—
Reply to this email directly, view it on GitHub
<#580 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ACCSD3ZQNEEVRXOA6LPEMBDZVAZKJAVCNFSM6AAAAABBFMSILWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGMZRGIYDQMJWGY>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
|
Ig, but idk how id reproduce this in plain FastLED? |
I already tried to import the I2SClocklessDriver. Here's the bad news: Doesn't work in C3,S3,C6, only works on Esp32dev. The developer said he has a working version for s3 but I didn't see it, maybe I didn't look good enough. Additionally the readme states that the library works on Arduino/PlatformIO as a drop in for FastLED. Problem is: The developer forgot to put in a header include for the library.json file. I fixed the issue and issued a pull request. But it's been three days and the developer hasn't merged it in. I looked at the neopixel bus to see what they did and - yup, same problem, only works on ESP32DEV and all other platforms are compiled out. Major bummer. Though I like the thought of running 24 channels of I2S WS2812 data, the driver is about only 33% done, realistically for someone that is new and wants to come in and fix it. For the original developer, this is probably 90% done. I've reached out to the developers of this to help them get it in for the library but haven't heard back. Bummer, because this is a fantastic feature. But the ESP32DEV user base is just too small to justify me wrapping my head on all the crazy espressif headers to get this done. Our user base wants WS2812 RGBW and that's my top priority for the next release. |
|
While you have that can open, Zack, please add another W to that request.
Another project just went to the effort to add RGBW, then their top request
became RGBWW when the additional work from there is mostly mechanical. It's
a bummer that atruct Pixel no longer fits in a word which can be a drag on
low memory configurations.
This problem, though, is likely something that's just not pinned in IRAM.
Someone with a debugger just needs to repro it. I've tried to repro it
(when filed) and can't. Perhaps with a better repro case, Zach and/or I can
repro it in NightdriverLED context.
I do agree that there are a ton of packages out there that just haven't
kept up in the later silicon, but as existence proof, I have WLED running
on S3, son Makuna code must work there, though I have only run it to a few
hundred pixels.
Oh, one of the things that NightdriverLED had to work around is the
antiquated use of 'register'..I haven't looked lately but has that been
fixed in FastLED? It's a problem in the post c++2017 world.
P. S. Are you Zack or Zach? Over the lunch table I never noticed.
On Fri, Sep 6, 2024, 11:04 AM Zachary Vorhies ***@***.***>
wrote:
… You can reopen the issue. Zack's trying to burn down the list of ancient
bugreports that have been open for up to 8 years and apparently just cut
too deeply. Be prepared to build up a test case that repros this in "raw"
FastLED, though. It's increasingly time to replace FastLED with with Makuna
NeoPixel or maybe I2SClocklessLedDriver. Maybe. I'm leaning toward the
former. But given the requirement of building and running every
combination, I cannot undertake that here. I'll probably eventually do it
in a fork and get "advanced" features like RGBWW, changing pin numbers and
strip types without recompiling, etc.
… <#m_4762911349048884551_>
On Thu, Sep 5, 2024 at 5:49 AM GameTec-live *@*.*> wrote: 😂 yep, sadly
lol — Reply to this email directly, view it on GitHub <#580 (comment)
<#580 (comment)>>,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ACCSD3ZQNEEVRXOA6LPEMBDZVAZKJAVCNFSM6AAAAABBFMSILWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGMZRGIYDQMJWGY
<https://github.com/notifications/unsubscribe-auth/ACCSD3ZQNEEVRXOA6LPEMBDZVAZKJAVCNFSM6AAAAABBFMSILWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGMZRGIYDQMJWGY>
. You are receiving this because you were mentioned.Message ID: @.*>
I already tried to import the I2SClocklessDriver.
Here's the bad news: Doesn't work in C3,S3,C6, only works on Esp32dev.
The developer said he has a working version for s3 but I didn't see it,
maybe I didn't look good enough.
Additionally the readme states that the library works on
Arduino/PlatformIO as a drop in for FastLED.
Problem is: The developer forgot to put in a header include for the
library.json file. I fixed the issue and issued a pull request. But it's
been three days and the developer hasn't merged it in.
I looked at the neopixel bus to see what they did and - yup, same problem,
only works on ESP32DEV and all other platforms are compiled out.
Major bummer. Though I like the thought of running 24 channels of I2S
WS2812 data, the driver is about only 33% done, realistically for someone
that is new and wants to come in and fix it. For the original developer,
this is probably 90% done. I've reached out to the developers of this to
help them get it in for the library but haven't heard back.
Bummer, because this is a fantastic feature. But the ESP32DEV user base is
just too small to justify me wrapping my head on all the crazy espressif
headers to get this done. Our user base wants WS2812 RGBW and that's my top
priority for the next release.
—
Reply to this email directly, view it on GitHub
<#580 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ACCSD37UG2REUDFRXBQY2KDZVHHBPAVCNFSM6AAAAABBFMSILWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGMZUGM3TMMZWGE>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
|
Ill try and poke a bit more at nightdriver and fastled... for reference ill also drop the links to the exact 2 boards i have (incase someone is crazy enough and wants to try on the exact boards): |
I really don't understand why everyone wants to make the RGBW implementation so freaking difficult. This is my opinion, but Adafruit did it the completely wrong way. They said: there are 4 pixels being outputted so let's give the user 4 pixels to manipulate. Everyone that I've talked to about the RGBW issue seems to have the same opinion. I come from the games industry. We use RGB8 everywhere until HD became a thing, and that was only what, RGB10? Going beyond RGB8 on the client side seems like absolute madness. Are we going to partition our entire blending / fx code too? Are we going to do it again with RGBWW? Shoot me. RGB8 It's good enough for games, it's good enough for our users. So what's my approach?Convert RGB -> RGBW at the fastled driver level. Boom. Done, easy peezy. All the sketches that work today for the RGB pixel type now magically work on the RGBW output pixel type. Blending code stays the same. If RGBWW becomes the rage, then that's supported too very easily (well for non AVR chipsets unless someone wants to change all that asm code). RGB8 is fine, the problem is that the RGB8 on the pixel chipsets don't gamma correct. But future ones do or will give you 16 bit per channel brightness or maybe they'll get smart and realize we only need 5+ bits of global brightness per pixel. I've already done this for APA102HD mode. No gamma correction necessary by the user, it's automatic. Client still uses RGB8, it just looks fantastic. RGB8 is good enough for artists IF the pixels themselves are gamma corrected. This is what games do already and it works great. Will some insist on a W component? Maybe, but they are in the minority. Most users just want to plug in a strip and have it work well. What makes this even easier right now is that it appears that the WS2812 makers have so far standardized W as the last component. So 3-component ordering may stay the same. Though I suspect that the entire industry may just assume standardized ordering going forward since it's a major headache for them to support anything but the standard GRB ordering, which becomes the default for WS2812 on the next release, as god intended it. What's great about the RGBW types is that it seems to reduce power usage. Full blast white for RGB for 30 pixels is 3.8 watts. Full blast white for RGBW (using the white color stealing algorithm) reduces that to 2.6 watts. So it cuts the power down by a 1/3rd. Experimental support for RGBW will be released on Monday. Fun times. (btw it's Zach but you can use either spelling - i don't care) |
Use our clone-and=compile mode for best results. Just clone our repo, open it up in VSCode and hit compile. It's that easy. Your changes go in dev/dev.ino. It's already preset to the esp32-s3 using the open source platformio codebase and uses the new arduion 3+ framework which includes idf 5.1. Once you've repro'd the case, push it to your fork and send me a link and I can see if I can repro it with my XIAO esp32 s3. |
|
@zackees heres the fun part, I cant rly reproduce it with a simple fastled sketch alone, tried for ~1h now, so ig its the combination of smthng Nightdriver is doing and Fastled thats the problem? |
|
Can you package it all up into one repo? |
|
That's like this repo or what do you mean? All you need to do is change the config as ive shown already.I can generate a new patchfile for the current repo versions as the older ones dont apply anymore and youd have to modify the files by hand... I'll send them in a bit... |
|
I really don't understand why everyone wants to make the RGBW
implementation so freaking difficult.
Because not everyone has the same goal.
Category 1:
Some people want the W bulb as a way to "take the load off" the RGB bulbs
for power delivery.
W=std::mind(r, g, b)
r -= w
g -= w
b -= w
done[1].
The power is saved by using the white bulb (as malformed of color as it may
be because some people like "sickly orange" white light (~3K) and some
people like "cubicle nightmare soft blue" white light (~5K) to be "white".
Neither group calls them that. In fact, they tend to call the OTHER group
that. :-)
These users never want to see the fourth or fifth pixel. They're perfectly
happy to barf up RGB8 and take the savings on their power supplies. They
don't want to change their software At All.
Honestly, this group could have been well served by totally putting the
whole shebang inside the bulb, keeping 24-bits on the wire, changing NO
software, calling this a "power saving WS2812 mutant" and moving the hell
on. But that's not the hand we were dealt.
The other group actually wants to manage them like additional spots of
light in their effects and are prepared to manage them a tiny little spots
of light of ~3K or ~5K "pixel" of its own. They want another 16 bits of
color spectrum out there - admittedly all clumped together - and they're
willing to address and provide another eight (one W) or even sixteen (two
W's) bits to provide it at a per-pixel level in the scene. These people
want struct CRGBWW.
This is my opinion, but Adafruit did it the completely wrong way. They
said: there are 4 pixels being outputted so let's give the user 4 pixels to
manipulate.
Half the users agree with you. (Well, other than the ones in that half that
recognize there are two whites, not one and want to bias the whites
to match.)
Between all three of these halves and the others, their preferred "correct"
answer is 3, 4, or 5 pixels because that's the number of bulbs offering 8
bits of intensity.
I come from the games industry. We use RGB8 everywhere until HD became a
thing, and that was only what, RGB10?
RGB565 fought hard and has a place. But there ARE people designing effects
that use both whites independently in effects.
Going beyond RGB8 on the client side seems like absolute madness. Are we
going to partition our entire blending / fx code too? Are we going to do it
again with RGBWW? Shoot me.
That was exactly my request, yes. RGBWW is here and it's not UNcommon.
Convert RGB -> RGBW at the fastled driver level. Boom. Done, easy peezy.
All the sketches that work today for the RGB pixel type now magically work
on the RGBW output pixel type. Blending code stays the same.
That makes group one above happy enough. It doesn't help group 2a or 2b who
want to treat white as individually addressable pixels happy at all. Those
bits are still occupying space in the transmitted frame and chomping down
the total frame rate. Might as well expose them to animators trying to
highlight or emphasize something, for example.
If RGBWW becomes the rage, then that's supported too very easily (well for
non AVR chipsets unless someone wants to change all that asm code).
My evaluation of 8-bit processors like AVR here in 2010 is pretty clear,
but we disagree on that and that's OK. :-)
What makes this even easier right now is that it appears that the WS2812
makers have so far standardized W as the last component. So 3-component
ordering may stay the same. Though I suspect that the entire industry may
just assume standardized ordering going forward since it's a major headache
for them to support anything but the standard GRB ordering, which becomes
the default on the next release.
That's just not true. I have strips in my collection that use different
ordering for the white channels. At least one of them swaps a white with
Green. One of them swaps a white with Blue. I can't remember any putting
a/either white FIRST, but at least one of the whites always seems to be
last.
So we have the full RGB/BGR/RBG/ {I'm not typing all of those combinations
at this hour and then repeating it with W1 and W2 sprinkled throughout)
matrix to deal with. Lucky us.
From a users's view, I don't dig the way WLED handled it where they let you
pick GRB order and then let you pick which of the pixels to "swap". It
looks very afterthought-ish. Nobody wants to hand a, what, 32-option enum
of alphabet soup to the user. This is one of the few things I've seen I've
seen the "Balance X" (nee Banlan X) get really right. Try a Speril SP530E
or older 630 controller (or just look at the data sheet of the alphabet
soup they support) for motivation.
What's great about the RGBW types is that it seems to reduce power usage.
Full blast white for RGB for 30 pixels is 3.8 watts. Full blast white for
RGBW (using the white color stealing algorithm) reduces that to 2.6 watts.
So it cuts the power down by a 1/3rd.
That's exactly the hook for crowd 1 above, yes.
Experimental support for RGBW will be released on Monday. Fun times.
Groovy.
For all our sanity (including yours and mine since we talk to each other in
like eight different places) let's move the RGBWW discussion out of
Gametec's crash inside FastLED when he has LOL - lots of LEDs. I probably
shouldn't have mentioned it here. Sorry.
(btw it's Zach but you can use either spelling - i don't care)
Thanx. I try to respect a person's preference and I couldn't remember yours.
RJL
[1] Of course, it's not REALLY done. Depending upon the color temperature
of that W (which we rarely know), you want to bias it slightly more red or
blue depending upon the temperature of that W.
… Message ID: <PlummersSoftwareLLC/NightDriverStrip/issues/580/2334756266@
github.com>
|
|
Man. I've tried two different S3 boards (a YULC and the more traditional
YD-ESP32-S3, which is a DevKitC clone, but with "fixed" USB-C connectors,
like God Herself intended.
I get rainbows out of the port and it keeps on chugging. The frame rate
falls to about 20fps since we have 1500 pixels on this "strip" that's
running off into space.
But I can't get it to crash.
Ugh.
…On Sat, Sep 7, 2024 at 1:22 AM GameTec-live ***@***.***> wrote:
N32R8V-diff.patch
<https://github.com/user-attachments/files/16915104/N32R8V-diff.patch>
—
Reply to this email directly, view it on GitHub
<#580 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ACCSD3YUAK4YKWGPEKW37FLZVKLUDAVCNFSM6AAAAABBFMSILWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGMZVGA4DQNBWGQ>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
|
@robertlipe appreciate the effort, but then smthng must be different? Ive tried 2 different boards, from different sellers, so I doubt that both just happened to randomly be broken in the same way? |
Okay. This is exactly the real world information that i was looking for but couldn't find. Thank you. Looks like I have to define a total ordering for RGBW then. Luckily there is enough room in the EOrdering enum for one additional component. Cheers as always. |
Bug report
32MB FLASH 8MB PRAM ESP32-S3-DevKitC1(ESP32-S3-DevKitC-1-N32R8V)
Problem
Steps
Example
Notes
In this case a "Matrix" is just a bunch of daisychained LED strips going back and forth.
My globals.h
globals.h.txt
Same exact config file works fine on a generic, less powerful, esp32.
And reportedly running 1500 leds on one controller isnt optimal, but it works fine and i get a decent frame rate on my underpowered esp32. It shouldnt crash anyways ;)
Monitor Log:
https://hastebin.skyra.pw/wikevijele.yaml
The text was updated successfully, but these errors were encountered: