Creating a "configurable" firmware

[simon-budig]

Hi all.

What would be the proper approach to make it possible to configure the strip type connected to a controller?

Right now the color ordering of the LEDs (RGB/GRB/GRBW etc.) is incorporated into the type of the NeoPixelBus via templates. This makes it quite hard to allow changing this "on the fly" without recompiling the firmware of your controller.

What is the suggested approach to tackle this problem?

Thank you,
Simon

[Makuna]

This library is not meant to solve that solution. It will be very difficult to support with lots of code bloat.

You the sketch author have to wrap each feature/method combo with its own class that derives from a base "interface" (abstract virtual class) and provide a "factory" that instances each combo and returns that base "interface". If you have ever heard of COM (old Windows term, often mentioned in relation to OLE) then this is what you would be doing.

Further, abstracting the whole RgbwColor and RgbColor is not going to be fun for you unless you accept comprises.

Its all doable, but not the goal of this library. 99.99% of users never need that and it will cause a huge code bloat and won't be very platform independent.

[simon-budig]

Hm. I am surprised that you consider a firmware for a generic led-strip controller that can handle both GRB and GRBW strips as out of scope for your library.

Wouldn't it make sense to put an abstract virtual base class below the NeoPixelBus-family of template based classes? Then you could create instances of different types e.g. in a switch/case statement, while still using the same pointer to access the strip in your effect functions. NeoPixelBus-API that deals with colors would need a bit of thinking, but it feels like a solvable problem.

And if you don't need that flexibility then you just use the specific template-based type in your sketch and the compiler can do away with all that method-resolving overhead...

[Makuna]

https://github.com/Makuna/NeoPixelBus/wiki/Smaller-Code

The goal of this library is smaller code, less RAM, but include support for more LED types and broader platform support.

Every virtual function adds a pointer member (hidden, VTable) to an instance of that class that does not get optimized out. There are platforms I support that the tradeoff of memory compare to a longer strip of pixels would make it useless. Its also the reason Sonof uses this library, with all the other functionality it supports, this library doesn't hog too much memory (code or ram) and thus limit what it can do; and they are very tight on code space.

Yup, there is a tradeoff; but again what you want is not my target; I target those who compile and flash which what most users do.