DEMO may be overachieving

[robertlipe]

This might be a bugreport or even a couple, but it's worth discussing the intended results. For demo itself, this is all probably actually fine, but I'm more concerned about it being 'heavy' for people that actually have large pixel counts and care about FPS because we may be over-computing.

I'm currently experimenting with a largely stock 'demo' configuration. It starts with lilygo-tdisplay-s3-demo, but I have tweaked it to reduce the brightness from the intensity of the sun (and require less power power supply - and welder's goggles) and to use PIN5, as it says in the documentation, instead of those that would have been set by:
+// #if M5STICKC || M5STICKCPLUS || M5STACKCORE2
+// #define LED_PIN0 32
+//` #elif LILYGOTDISPLAYS3
+// #define LED_PIN0 21

So maybe this point is something we could document better. I have a change pending that will add the pin number to the boot jibber jabber so a user has a better chance of finding which pin is getting the signal.
AI: revisit text "Connect PIN5 and GND and 5V of a WS2812B strip to the ESP32", suggested "Connect power and ground to an appropriate source capable of driving your strip. From the ESP32, connect the ground and the hardware pin associated with LED_PIN0 in include/globals.h with your hardware configuration to a WS2812B strip. Typically this is pin 5, but may be different, particularly on the LilyGo or M5Stack configurations." This also prepares people for the reality that an ESP32's own power rails are unlikely to drive 144 pins (Maybe the ECO devices...) and certainly not at our default brightness.

The demo configuration claims "DEMO, assumes you have a single meter strip of 144 LEDs ". Trying to find the end, expecting to run out of blinkage. I got to six panels and still can't quite make the math work[1] but I found it a long way after 144.

DEMO actually configures MATRIX_HEIGHT 8 and all the internals do MATRIX_WIDTH * MATRIX_HEIGHT. Confirmed thusly:

(processRemoteDebugCmd)(C1) Displaying statistics....
(processRemoteDebugCmd)(C1) v040:1x1152 73K
(processRemoteDebugCmd)(C1) 68dB:192.168.2.168
(processRemoteDebugCmd)(C1) BUFR:00/27 [16fps]
(processRemoteDebugCmd)(C1) DATA:+0.00-+0.00

This means we're doing 8x more work than advertised. That's free blinken per bit (8 and 1 have the same number of bits...) but we're overcharging. If you're Clark Griswold (cough, Dave) and our GPIO twiddlers (which are already working hard for that goofy 800kHz signal) are working 8x as hard as we claim they are, we'll run out of blinken before deserved since we're clocking out bits that'll fall right off the end of that cable. At the outer edges, our frames may be so long that the we tank frame rates, wasting 7/8ths of our frame.

AI: Should MATRIX_HEIGHT be 1 for DEMO or should the doc be tweaked?

Demo sets NUM_RINGS 5 and RING_SIZE_0 24, but not RING_SIZE_[1-4] - is that sensible? I have a bunch of effects in my queue that COULD look decent on rectangular (or even octagonal) grids of NeoPixels.

AI: What are rings anyway? We build g_aRingSizeTable[], but it's not actually used anywhere. Should that be dropped from at least a couple of our globals.h entries?

I think I've identified a foundational source of confusion in my earlier quest to understand the differences in the configs and now that I've read more code and conquered more configurations, I think there's a simple solution.

AI: In light of targets like SPECTRUM using MATRIX_HEIGHT and MATRIX_WIDTH, can I rename 'USE_MATRIX' to 'USE_HUB75' and (this one will be a tougher sell...) 'USE_STRIP' to be 'USE_NEOPIXEL"?

The struggle is that Neopixel is a trademark of one specific brand of device using World Semi LEDs, but USE_ANYTHING_THAT_SUPPORTS_WS28xx_PROTOCOL_LIKE_MAYBE_SK6812 is hard to type. IMO, Neopixel is a pretty well accepted term and maybe in danger of losing trademark status, but we need a term for things using the single-wire control protocol, even if they aren't actually strips. Personally, I'm fine with NEOPIXEL and that seems to be common use. Changing USE_MATRIX, though, seems like a slam-dunk as we use the term to mean "HUB75 devices" even though we have configurations, like Spectrum, that are a matrix.

As always, I'm willing to make the above changes after agreement upon direction. I think these few minor changes can help improve initial setup and learning curves.

Additionally, I'll also be working on additions to the telnet server (maybe once to the serial port on boot since we don't really document the telnet server, either) that will announce the hardware configuration that the board IS using as it's depressingly easy for that to not be quite what you thought you were using.

[1] bc: (8144) - ((832)2+256+(1616)+(8*8)+16+7) - my final 16 LED circle ran out of gas after 7 blinkies.
41

41 isn't particularly indicative of a power or two or fenceposting error, so I'd have to dig harder to find it if I actually cared.

[robertlipe]

41 isn't particularly indicative of a power or two or fenceposting error, so I'd have to dig harder to find it if I actually cared.

41 is the location of the defective LED in my neopixel ring. Nothing after that ever works. He gets sent to the end of the line...until I contact the mfr for replacement.

41 may not be a power of two, but it IS an off by one of "42", the universal answer. If try hard enough, there's numerology in everything - even hardware defects.

[robertlipe]

Mostly fixed in #394.

[robertlipe]

Combined, these three submits fix these issues. Marking as fixed.

551dcca
2c9b1df
bf37f82