Just curious how hard would it be to port FastLED to a different family of processors? I know that the library runs on Teensy 3 and that is a 32 bit ARM rather than 8 bit AVR, so what parts of the library change when porting? Thanks for any info you can provide! 
There’s three major pieces of the library that need to be ported when moving to a new platform.
The first is the FastPin class - this is a templated class (and is why pin access is determined at compile time, not run time) that is used to get as close to the underlying hardware’s i/o port registers as possible (for example, on avr, we can use 1 cycle instructions to set a port value, or 2 cycle instructions to toggle a specific pin vs. the ~50-100 cycles digitalWrite takes :). This is important because it is the basis for pretty much all the led i/o writing. Sadly, there is no standard for the i/o registers and their configuration, so this needs to be platform dependent.
The next thing that needs to be ported are the clockless controllers. This is because the tight timing requirements often either require hand tuned asm (in the case of AVR) or the use of various timers/systems clocks (on the various ARM platforms). As each ARM manufacturer has a different set of timers and registers for accessing/controlling them this, once again, needs to be done on a per platform basis.
Finally, this needs to be done for the hardware SPI controller as well (and eventually, when I start (ab)using them, the UART controllers that have SPI modes).
Beyond that there’s little bits of asm code here and there that you’d need to sanity check there were C versions for (we’ve taken care of that it most places already, however).
If you grab the FastLED3.1 branch you can see this broken out better as I have split out all the platform specific code into various platforms directories (platforms/avr, platforms/arm/k20, platforms/arm/sam, platforms/arm/nrf51, platforms/arm/stm32).
I’ve been eyeing the ESP2866 - keeping an eye on how that’s coming along. Once the tool chain gets to a better point, and I’m caught up on my other platform projects (finishing nrf51822, doing stm32, and doing the LPC81x platform) I may add that one as well.
Which platform do you have in mind/curiosity about?
(I briefly entertained the idea of porting it to the MSP430 platform, but I’m not sure I want to spend a lot of time in 8-bit land again, but it might be possible to talk me into it. I’m also very very interested in eventually porting it to the XMOS hardware).
There’s also some more support work that I still need to do to make spinning up a new platform quicker, the big one is better laying out/documenting the pair of top-level header files that are responsible for selecting platforms/including the correct files. I’ve also throught about making a “dummy platform” that is basically full of empty versions of all the classes that would be needed for a new platform, to make starting that up go more easily.
The one thing I would caution before undertaking a completely new platform (or at least making sure to stay in touch with me about it) is the internals of the library are about to undergo another major overhaul that’s going to impact all of the controllers. This is cleanup work that’s being done in anticipation of some major features coming along in 2015 (16-bit RGB/HSV, support for allowing controllers to use palettes to write out data, etc…) to make that major feature work a little bit saner to do.
Awesome, I’ll definitely check out the 3.1 branch. Dummy classes sounds like a great idea.
Specifically I was wondering about porting to the Atmel UC3 family. I’m even considering trying to pipe the LED buffer over SPI to an atmega328 one row at a time just to get FastLED support lol
All I’ve ever done is Arduino programming and it feels like a big leap going from that environment to anything else. Like uc3 vs PIC32 vs ARM vs Coldfire, I have no idea what the consequences are of moving to a 32 bit platform other than losing all these nice libraries 
That would be one reason to dip your toes into 32-bit with the arduino due or the teensy 3.1 first - you get to keep most of your libraries, and play around with/explore what you get in the 32 bit world.
I’ve been skimming through the AVR32 docs - looks like a decent instruction set for the most part, and the hardware level seems pretty straight forward. I haven’t dug into what the i/o registers are like to work with yet (atmel had some irritating things in the SAM3X8 platform, they have another ARM platform, the D20 that I haven’t explored yet, but they did things differently over there for laughs). I like the way the UC3 appears to be doing GPIO. There’s some things they do that may make it easier to get more efficient code compiled in. The SPI hardware seems to be pretty run of the mill as well.
Sadly, no one seems to do I/O routing like Nordic. With the NRF51822 I can run things like hardware SPI on any set of pins that I want to, vs. the avr/atmega328 (and, from current reading, the uc3) which is locked to a single set of pins, or the k20 which gives me two pairs of pins to use.
i started a port of to the PSOC4 , most of the stuff i came across was just tidying up includes that were platform specific that weren’t under a config #define. it was fairly straightforward. cypress don’t support c++ off the bat, but i worked around it,.
Thanks for all the info Daniel!
@charlie_wallace a lot of that will improve even more when I merge the nrf51822 support back into the main tree. I did a port of FastLED to the NRF51822 for a project that was using that chip in its hardware, but this was all bare programming, there was no arduino environment. It let me do the last bits of stripping out arduino dependence from the library that I started with the transition from FastSPI_LED to FastLED2 (though if the bits are there, it will make use of them).
Sadly, the C++ stuff is unlikely to be removable, at least when it comes to the led control side of things, as I make pretty heavy use of templates to do a type of generic programming/optimization that’s nearly impossible to do with macros (without forcing people to use some strangely syntax’d macros).
Luckily, the PSOC4 is an ARM Cortex-M0 - so it can make use of the bits of arm asm that we have in the library. If someone shoots me a PSOC4 dev board I can see about adding that to the rash of arm platform ports that I’m working through this week
@Daniel_Garcia i have a custom board i made that ties into the ws2811b’s, i’m using a custom verilog to drive the LED’s so its a bit different on them, though obviously you can use the SPI too. drop me a note with an address and i’ll send you a board. my branch is really only driving the WS281x’s via the custom component, so it’d be wider usage to do it in SPI . It shouldn’t take long to finish. the C++ isn’t an issue, its just not normally supported so you have to override the compiler with a flag.
@charlie_wallace would you be willing to share? I’m playing with the Psoc 6 right now but I came from Arduino and the learning curve is a little steep right now