A preview of what I’m thinking of (and relatedly, an explanation for why it’s been so long since the last preview release) for the final API. What people have been playing with on the preview releases has been direct access to the various LED controller objects. This isn’t exactly friendly to new developers, and requires a lot of juggling of options, and more thought/understanding of what’s going on at a low level than a lot of people starting out want.
One of my goals for the API is to get people started with making things work really really fast, while also making it easy for people (aka staying out of their way) to do more complex/dynamic things.
So - there’s going to be an API layer on top of the controllers that will look/work somewhat like the first API - but at once simplified and more powerful. At it’s simplest, let’s say you have a string of LPD8806’s hooked up to the standard hardware SPI pins for your device. This code will send a blinking red led down your strip:
#define NUM_LEDS 120
struct CRGB leds[120];
setup() {
FastLED.addController(leds, NUM_LEDS);
}
loop() {
for(int i = 0; i < NUM_LEDS; i++) {
// turn off all the leds on the strips (defaults to clearing led data as well)
FastLED.clear();
delay(100);
// set the current led to red
leds[i].r = 128;
// tell the library to update leds
FastLED.show();
delay(100);
}
}
And that’s it. Maybe in running this you realize that the RGB order is backwards! That’s easily fixed - change the line in setup to:
FastLED.addController<LPD8806, BGR>(leds, NUM_LEDS);
Or maybe you have a degenerate LPD8806 strip, and need to slow the speed way down:
FastLED.addController<LPD8806, DATA_RATE_MHZ(1)>(leds, NUM_LEDS);
Of course, you can also change the pins that are used, forcing software SPI:
FastLED.addController<LPD8806, 4, 5>(leds, NUM_LEDS);
Alas, clock-line-less chipsets will always need a pin defined:
FastLED.addController<WS2811, 3>(leds, NUM_LEDS);
You can add/define an arbitrary number of controllers - though I’m still refining how you go about the process of having multiple controllers on the same pins and using select pins to specify which ones get used. My goal is to make sure that the most likely options are setup as defaults (e.g. data/clock pins for hardware SPI, default data rates for the SPI chipsets, default RGB ordering for strips, etc…)
I’m also still nailing down how to do the mapping of controller objects to an array of RGB objects. In the original library, the library took care of allocating the array of leds, and you had to ask the library for it. Over time, i discovered multiple problems with being restricted in this way, and instead set it up so that I could tell the library which set of memory to use for led rgb data. Now i’m wondering if I ever want the library to manage that side of memory. Still thinking about that one.
Also - there are still more pieces to add on top of this. @Mark_Kriegsman and I have a fast HSV2RGB conversion library in place that will be going out with this library - and so I want the API to also support you defining CHSV arrays instead of CRGB arrays - but again, trying to do it in a way that’s quick, straightforward, easy to start working with, but flexible enough for whatever weird contortions people out there (i.e. me!) will want to do to squeeze performance/functionality out of the world.
With the APIs that people have been playing with in the preview releases so far, I feel perfectly ok playing fast and loose with them and changing them around (and even then, try not to - when the next release comes out with the new API, I will try to include notes on how to tweak existing code over to it - I have had to make some changes). With this final, public facing API - I feel fairly strongly about needing to get it very close to Right[tm] the first time.
