I’ve been trying to use fastled to drive leds from a Teensy 3.1 with a clock crystal soldered in to enable its real time clock but the time lib and fastled are not working together - the time runs super fast or jumps back in value. If i include fastled and use CRGB objects etc. it’s fine as well, as soon as i use “show()” then it messes up the timing. code example available if you want it, can dump it on pastebin or similar. From testing it out i’ve established that neopixel works but i much prefer fastled, is this something i can avoid somehow? presumably its related to the internal timers that fastled is using?
I don’t think Teensy 3.1 support is stable yet.
Teensy 3.1 support is fairly stable - at least on the non-SPI side (though a recent SPI-related issue ended up being more of an LPD8806 specific issue) - however FastLED includes code to attempt to adjust the timing values (because most arduino-style platforms use interrupts to advance the timing, since we disable interrupts, the library attempts to manually advance the timer by the number of clocks that have gone by). I suspect that this adjustment that the library is doing doesn’t play nicely with the time library that’s using an external crystal - but I don’t know for sure how the two will be interacting.
If you want to disable the time adjustment, for now, you can go into clockless_arm_k20.h and comment out the MS_COUNTER += lines, which will get rid of that adjustment.
The neopixel library makes no attempts to account for the time that interrupts are disabled or any such thing, which is why you likely aren’t running into problems with it.
that did the trick! thank goodness i don’t have to do a franken-version with half neopixel and half fastled. cheers! 
As Daniel says Teensy 3.1 support seems very stable - i’ve been using it with a few different light types and both teensy 3.0 and 3.1 in all sorts of configurations up to now and have seen no problems whatsoever since at least 3 or 4 months ago when the 2.1 branch was up.