different LEDStripTypes ?

[fanno]

Taking a look at LEDStripGFX it is for WS2812B, and color order of COLOR_ORDER

or should one create a "clone" eg:
class LEDStrip_NEOPIXEL_GFX : public GFXBase
class LEDStrip_SK6812_GFX : public GFXBase

or could this be done so one could somehow pass it as a variable in to an aditional version of AddLEDsToFastLED, my c++ skills are still limited but i am trying to learn, i know that WS2812B is a template but i don't know the tearms to search for to know if this can be done.

class LEDStripGFX : public GFXBase
{
protected:
    static void AddLEDsToFastLED(std::vector<std::shared_ptr<GFXBase>>& devices)
    {
        // Macro to add LEDs to a channel

        #define ADD_CHANNEL(channel) \
            debugI("Adding %zu LEDs to pin %d from channel %d on FastLED.", devices[channel]->GetLEDCount(), LED_PIN ## channel, channel); \
            FastLED.addLeds<WS2812B, LED_PIN ## channel, COLOR_ORDER>(devices[channel]->leds, devices[channel]->GetLEDCount()); \
            pinMode(LED_PIN ## channel, OUTPUT)

it would also need to affect InitializeHardware

due to this:

    #if USE_HUB75
        // LEDMatrixGFX is used for HUB75 projects like the Mesmerizer
        LEDMatrixGFX::InitializeHardware(devices);
    #elif HEXAGON
        // Hexagon is for a PCB wtih 271 LEDss arranged in the face of a hexagon
        HexagonGFX::InitializeHardware(devices);
    #elif USE_WS281X
        // LEDStripGFX is used for simple strips or for matrices woven from strips
        LEDStripGFX::InitializeHardware(devices);
    #endif

IF it is is intended to do (class LEDStripGFX : public GFXBase ... class LEDStripGFXNEOPIXEL : public GFXBase)
Would the correct name for class LEDStripGFX : public GFXBase not be something like:
class LEDStrip_WS2812B_GFX : public GFXBase

A side node to this, am i correct to assume you can't have 2 different types of LED on the same NDS? 1 matrix and 1 strip ? or am i wrong in reading this ?

Again i am fairly new so i am properly missing quite a lot of content.

I am aware FastLED don't support RGBW but some "hacks" exist for it so my current goal to add and test support for this for NDS. (hacked and eventually none hacked if FastLED get the support.)

[robertlipe]

#if USE_HUB75 // LEDMatrixGFX is used for HUB75 projects like the Mesmerizer LEDMatrixGFX::InitializeHardware(devices); #elif HEXAGON // Hexagon is for a PCB wtih 271 LEDss arranged in the face of a hexagon HexagonGFX::InitializeHardware(devices); #elif USE_WS281X // LEDStripGFX is used for simple strips or for matrices woven from strips LEDStripGFX::InitializeHardware(devices); #endif

That's an unfortunate naming convention. The HEXAGON display is a 2D layout of 2812's. So the distinction there is physical, not electrical.

A side node to this, am i correct to assume you can't have 2 different types of LED on the same NDS? 1 matrix and 1 strip ? or am i wrong in reading

That's something I've been chipping away at since joining. Fundamentally, we are EITHER USE_HUB75 or we're USE_2812x. The square (or circular, in the case above, hexagonal) grids of pixels that you see such as in the SPECTRUM configurations are sometimes called a matrix, but those are not what THIS code calls a matrix. (USE_HUB75 used to be USE_MATRIX...) This project cannot be built to simultaneously support the SmartMatrix-style HUB75 displays that get fed from the parallel interface AND the 281x/NeoPixel style bubs, in any physical configuration.

I am aware FastLED don't support RGBW but some "hacks" exist for it so my current goal to add and test support for this for NDS. (hacked and eventually none hacked if FastLED get the support.)

I thought that Zach landed the code for at least some RGBW configurations. Perhaps there hasn't been a release since then.

…

Message ID: <PlummersSoftwareLLC/NightDriverStrip/repo-discussions/602@ github.com>

[fanno]

OK, so from this current method would be to create my own "LEDStripGFX" i assume and implement a separate "user_xyz"

If i can do anything to help implement multi device support. Let me know.

As to the RGBW in FASTLed it possible, the articles, i look quickly throw the code, i did not "see" anything and all the "docs" i saw said no RGBW. or could just not be implemented yet.

-Morten Hundevad

[robertlipe]

I don't remember hearing this start with an actual problem statement and following question. "I'd like to use X." "Y is a problem. How can I get past that?". In all my romping, I haven't needed to subclass GFXBase on my own. I've always been able to (ab)use what's there, but there are certainly cases where that falls down. If your question is that you're trying to support HUB75 and 281X in the same build on the same hardware at the same time, I'll just close the question with this being the wrong starting place. These controllers are dirt cheap and trying to do two computationally intensive tasks on a SoC platform that's already bursting at the seams is simply unwise. Then your thesis starts "I want to port NightDriver to Pi 5 and ...." If you're just trying a one-off custom project that needs a few strips that are supported by FastLED and aren't 2812's, you'll basically hack up the code that calls ADD_CHANNEL to instantiate different FastLED.addLed<> thingies. I've seen mixed messages in the source and project history about the reality of the effects codes drawing into multiple devices[n]->leds[] arrays and drawing them independently. I think that ATOM might actually do that, but I'd have to look. In THEORY, effects code scribbles into leds[] and FastLED blasts the pixelized representation out the controllers. I won't die of shock if reality is different than theory. Look through FastLED source and history on github that's not been released yet if it's been a while. I said it was recent and I even named the guy that was working on it. It's not likely in the released FastLED thats in the platformio packaging. On the power issue, I was recently workign with WLED and found its (quite similar) concept of LED power management so annoying that I just mounted a VA meter on my test bed and turned off the regulation. I found telling it that I was unplugging 5v LEDS and attaching 12V LEDS or 24V LEDS and that these were of a different type than those and so on to just be annoying. This also on my desk, so I'd notice voltage sag and/or overheating. RJL

…

On Sat, Jan 27, 2024 at 4:39 PM Morten Hundevad ***@***.***> wrote: OK, so from this current method would be to create my own "LEDStripGFX" i assume and implement a separate "user_xyz" If i can do anything to help implement multi device support. Let me know. As to the RGBW in FASTLed it possible, the articles, i look quickly throw the code, i did not "see" anything and all the "docs" i saw said no RGBW. or could just not be implemented yet. -Morten Hundevad — Reply to this email directly, view it on GitHub <#602 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACCSD35N2NJA4X2SHANJWLTYQV62HAVCNFSM6AAAAABCNUPOWKVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM4DENRXHE2DO> . You are receiving this because you commented.Message ID: <PlummersSoftwareLLC/NightDriverStrip/repo-discussions/602/comments/8267947 @github.com>

[fanno]

This a thought on the Manny types thing could something like this work:

                  -DCHANNEL1="\"LEDStripGFX\"" <--- there may be a different way to do this than a string
                  -DCHANNEL1_MATRIX_WIDTH=144
                  -DCHANNEL1_MATRIX_HEIGHT=1
                  -DCHANNEL1_................=1

        #ifdef CHANNEL1
                if (CHANNEL1 == "LEDStripGFX") {
                        LEDStripGFX::InitializeHardware(devices); <------------ would need to be different to only add 1 device
                } else if (.......) {

                }
        #endif
        #ifdef CHANNEL2
                ......
        #endif

would also need to check if you have:
CHANNEL1 > CHANNEL2 -> CHANNEL3
and not:
CHANNEL1 > CHANNEL3

[fanno]

Forgot to add you can close this.

[robertlipe]

I don't know who Manny is or why he gets a vote... Compile time constants for such things really work badly for non-trivial configuration. At some point, if you're building a Specific Thing, it's going to be easier to just go in and make the code do that you want it to do instead of trying to make it possible to generalize like you're doing. Unfortunately, FastLED was originally written for a super-wimpy CPU that used to have different opcodes and addressing modes for wiggling different pins. Some pins did DMA and some pins could do unaligned word loads and some couldn't and so on. It's for those historic reasons that FastLED really really wants the "arguments" to addLeds<> be constants - it's so it can instantiate exactly the right opcodes (I think it was even more than a bit of inline assembly) to plumb the data buffers through the controllers and out the bit-shifters. Of course, now that 8-bit AVRs are behind us and clock speeds have gone from 2Mhz to 240Mhz in our case and 2,000Mhz in others, the perceived "overhead" of changing a pin number or array size is noise, dwarfed by a single cache miss and a couple of well-predicated conditionals even inside a high-running path can be tough to even notice at "only" 800kHz. See discussion (one of many, many) at FastLED/FastLED#282 Most newer <https://blog.ja-ke.tech/2019/06/02/neopixel-performance.html> libraries are just less stubborn about this. Most newer micros have so many pins and so much flash that you can afford to have different code for, say, SPI vs. RMT implementations for use on different pins and the developer rarely even needs to notice below a few thousand blinking lights. Anyway, sounds like you've got what you need. Good luck. Only you or Rutger can close this.

…

On Sat, Jan 27, 2024 at 6:04 PM Morten Hundevad ***@***.***> wrote: Forgot to add you can close this. — Reply to this email directly, view it on GitHub <#602 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACCSD34Q254PZL3LI4ABIR3YQWI2VAVCNFSM6AAAAABCNUPOWKVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM4DENRYGIZDI> . You are receiving this because you commented.Message ID: <PlummersSoftwareLLC/NightDriverStrip/repo-discussions/602/comments/8268224 @github.com>

[fanno]

No problem =), thanks for the discussion.