So I was thinking that I would be able to modify my RF library to accept runtime configuration utilizing the FastSPI lib. Correct me if I am wrong (not a c++ programmer by day) but because of the template controllers I won’t be able to resolve references to change the led type or pins used based on over the air (runtime) configuration information. Right?
There’s a way to do it, but not with the top level interface, and you’d basically need to have a switch statement with invocations for all the possible chipset/pin combinations that you would possibly use, which would cause the compile size of the app to jump up. Also, you’d need to instantiate controller objects directly. Creating/destroying those on the fly isn’t something I’ve played a whole lot with yet with them.
This isn’t exactly a common use case - most people are using these in environments where either the hardware is getting soldered together, or at the very least they are uploading new code as they are swapping hardware around.
The performance kick of the compile time port information is important, and on avrs it almost required for chipsets like the ws2811 where I am dangerously close to out of clocks as it is.
RE: Common Use case… I totally agree. I Think i got carried away when I was trying to figure out Over the air configuration. I thought, hey why don’t I just send in ALL the configuration, that would make setup really easy. I got neck deep in instantiating with a switch statement for all of the controllers before I figured out that it wasn’t a good idea and wrote the post:)
A good learning exercise, they all are right ??? I think I will just limit the OTA configuration to the universe and channels within and be done with it 
Most of my boards are single string (50 pixel) and as you point out, while i am there soldering the wires onto it, I should be able to choose the appropriate code to run it and do a bench test before deploying it … I
wanted to have the Over the air configuration so that once I am done with the install and realize that i put controller #5 where controller #9 was supposed to go I don’t have to climb back up on the roof to fix it.
in retrospect, its probably a lot easier to climb on the roof and move some stuff around than write that code and do it right
I’ve been going down this same line of thought, Greg. If you want to dynamically assign pins, it may be best to use another library; you’ll still need a switch statement for chipset, tho.
My thought about config is not so much swapping two boards, but the convenience of pulling a stock controller out, plugging in one or multiple pixel strings of whatever sort, and then configuring it without needing to reload the firmware - and the same flexibility when fixing a problem outside. But I’m thinking that I can have pin conventions. Like first two wire control (2801/8806) on pins 7 and 8, second on 6 and 9, etc. And first single wire (2811/2812/180x) on pin 9, second on pin 6, etc. This still allows for some mix and match plugging of various types of strings.
Example use case: one of my 1804 based strings has problems; substitute 2801 based string with a bit of plug swapping and OTA configuration. No need to open the somewhat sealed case.
Daniel,
So you are probably dangerously close to running out of cycles for the 2811/180x chips on the AVR - probably in part due to the free multiplier?
Didn’t the old library, as well as Adafruit’s, handle 2811 with run time pin selection?
The old library’s timing was way off - and I"ve gotten reports that some mfg.'s ws2811’s are very sensitive to the timing, part of tightening up the timing cost me a couple of clocks.
The multiplier is done in two parts in the long block at the ends of two bits in the ws2811 timing, the tight timing is in the 350ish ns block at the beginning. With compiling down the pin selection, I can use a 1 clock cycle port register opcode on the avr to set the pin - there’s no good way to do that with run time pin selection short of playing a bunch of games with extra hand coded assembler.
Honestly - this is the first time in nearly 3 years of people using the library i’ve had anyone ask for the ability to dynamically swap chipsets being used without having to upload new firmware.
I’ll give some thought to implementing it - but given that it would require some major overhauling, again, of the library, and that I just got finished with doing that, it’s unlikely i’m going to do anything like that with this library in the next six months. The next major work on the plate is supporting 12 and 16 bit color chipsets.
Daniel, don’t worry about changing things on my account.
All i was trying to do was simplify the setup and deployment of my controllers. One side effect of that was this question and a really complicated Over the air configuration protocol.
After thinking about it its very reasonable to expect that I bench test the leds soldered to the board prior to waterproofing. Since my RF1 controllers are meant to only handle a single string and maybe a few other tasks, its not a big deal. I took the chipset and pin configuration out of my over the air protocol. Because my OTA stuff is using dmx512 mostly, I am still going to allow the OTA protocol to adjust the “start channel” so that I can move the data around if needed.
as a side note, I had only been using ws2801 pixels with this library until last night when i realized that the other three strings of pixels in my stash were 2811! So now I have verified both are working !@!! YAY Progress!
Unlike Greg, my controllers are not soldered to pixel strings/strips on the workbench - instead there is a connector between the controller and the pixels, so controllers can be swapped among strings (with the same voltage). 2801/8806 use data + clock, 2811/1804 use only data. So it could be useful to change chipsets without reflashing (ie: using EEPROM configuration), if swapping strings or controllers.
Is it possible to define both 2811 and 2801 pointing to the same leds array, but dynamically enable only one or the other?
Zeph you can do this if you use the raw controller objects, rather than using LEDS to manage your controllers/the led showing. It means you’d have to call show on individual led controllers, but this is basically how the library was structured before the RCs where I put the LEDS object in there to manage all of this stuff for people.
You can either get the controller objects returned by LEDS.addLeds and use those or instantiate them directly (look in FastSPI_LED.h to see how the different controllers get instantiated). An older version of the test app - https://code.google.com/p/fastspi/source/browse/branches/FastSPI_LED2/examples/Fast2Dev/Fast2Dev.ino?r=82 - shows doing some of this a bit more directly. Then you would only call show on the specific controller objects that you wanted to use.
(Tweaked off main use like this is part of why I left all of those interfaces/classes/etc… public - so that people who wanted to do stuff like this did have a path for going around the core interfaces - some of the documentation/example code will include discussion about how to directly use controllers like this vs. the centralized controller).
I also do the standard connector thing (4 pin, at the moment) when doing dev/testing work, so that I can swap strips out quickly - though in an ideal world, my standard connector would be five pin - 5v, 12v, ground, clock, and data. The number of times i’ve accidentally smoked something switching from a 5v setup to a 12v setup…
Of course, as new chipsets get added, you’d have to reflash to support them 
Right now, i’m trying to figure out how best to represent and configure block controllers (e.g. sets of 8, 16, or 32 strips that are on the same port for parallel writing (also will eventually act as an interface/frontend to octows2811 if that library is available)). Lots of ranting about how people export GPIO ports to hardware pins in that one Good thing is, the code works - makes for a nice way to drive ~3500 ws2811’s at high FPS. Bad thing is, it’s a bit hard coded for the due at the moment.
Also, be careful of this when the TM1829 support goes out - because it inverts hi and lo for its signaling, it is very easy to blow out the strip on full power hi! I think I need to cut my strip down to 1-3 leds so that I can more safely poke at it and get the protocol/timings/hi vs. los right.