I’m working on converting a chunk of code to use the FastLED (v3.0.3) library rather than the Adafruit WS2801 library, however I’ve hit a problem that may be due to my limited experience with C++ templating.
In my code I’m storing the pins used to control the WS2801 LED strings in an EEPROM config structure (as this code runs on a few different custom PCBs that use different pin outs), so the pin values are not constants. The method of initializing the LEDs shown in the examples basically goes like this (this works in my code):
void PixelUtil::init(uint16_t num_pixels, uint8_t data_pin, uint8_t clock_pin) {
#define DATA_PIN 8
#define DATA_PIN 12
CRGB leds = new CRGB[num_pixels];
FastLED.addLeds<WS2801, DATA_PIN, CLOCK_PIN, RGB>(leds, num_pixels);
}
However if you replace that line with one using the variables:
FastLED.addLeds<WS2801, dataPin, clockPin, RGB>(leds, num_pixels);
it will throw these compile errors:
/Users/amp/Dropbox/Arduino/libraries/PixelUtil/PixelUtil.cpp:38: error: ‘dataPin’ cannot appear in a constant-expression
/Users/amp/Dropbox/Arduino/libraries/PixelUtil/PixelUtil.cpp:38: error: ‘clockPin’ cannot appear in a constant-expression
Is there an alternate means of adding LEDs that will work with non-constant pins?
No, there isn’t - the library does a fair bit of compile time optimizations based on the pins that are selected, and the goals of the library are flexibility on the code side (e.g. quickly/easily changing the type of leds by changing a single line of code, or the various library utilities produced) and maximum performance on the compiled code/installed code side especially when it comes to pushing out led data (required for some of the run time brightness/color correction code that’s run).
Hrmm, do you think forking the library and adding an additional initialization routine that accepts variable pin values would be an excessively major task? I’d started on some similar library code (at least for HSV routines) before being pointed at FastLED, so I’d be willing to spend a few hours on my own getting it working, but that would only really be useful in the long term if it would still be easy enough to merge in changes from the master repo.
The thing that some people have done is basically do an addLeds on every pin they’ll potentially want to use, save the LED controller objects that are returned, and just call show() on the relevant one(s) once the configuration is known. It makes the executable code larger, but it requires no library hacking. If the number of potential pins is not crazy large, and if you have the flash space available, this might be an easy option.
I don’t relish the thought of trying to de-template-ize the pin access optimization, but Dan is the author and mastermind there, and I’ll completely defer to his expertise.
Ok, so getting into some details: are your pin numbers all over the place, or are they all on the same port? How many different pin configurations are actually needed to make this project work the way you wish?
The other other thing is that you could potentially just use the Adafruit ‘device driver’ part of their code and everything else from FastLED. That’s a bit messy, but we’re sort of up to our armpits already on this one, so it’s worth mentioning for brainstorming.
The templated pin values drive down into the core of the output routines, it’d be pretty significant work to change to support it, it’s not just adding initialization routines. (and no, I don’t think it would be work that would allow you to continue to receive upstream changes, at least not for the LED driving routines. Certainly for the higher level math/color routines you could)
Ok, thanks for the info. I currently have two versions of a PCB with different pin values that have a few copies of each in use, so specifying each version in the code seems like it would probably be good enough. Its easy enough to make sure future versions of the boards stick to one of those two combinations.