I’ll play with it some more, I may need to tweak the timing loop numbers a bit at lower clock speeds, as the loop for counting clocks may be swinging time too much.
Daniel, is that you that replied on my pjrc thread about the hanging teensy?
It’s likely. I try to follow what’s going on in the forum over there, but if fell out of the habit over the past few months.
Groovy, you gave me a good tip which I’ll look into when I get home.
Ok - I think I have the code running at 48Mhz - unclear why it was happy a week ago and isn’t now. Possible some code cleanup caused enough of a tweak. I’m still trying to figure out why it’s completely unhappy at 24Mhz, however. No good answers yet, though, and without my logic probe (i think it’s burnt out, I need to arrange a replacement, just haven’t had time yet) I can’t see what’s actually getting spit out, timing wise.
Also, while the pjrc page claims 72Mhz as the native speed for the teensy 3.1, teensyduino only gives me 24, 48, and 96 as options. I’ve posted a message to pjrc to find out what’s up with that (and if any of this could be throwing off my math anywhere)
Okay, I’ve found far more serious stuff. I posted it to the PJRC thread you replied in. Happy to discuss here too if you like. There’s code that causes the problem posted over there.
Basically FastLED hates delay()
I doubt that - I use delay in many places. The led problems at 24 and 48mhz are math/timing calculation issues which I will fix in the morning after I get some sleep.
I suspect never exiting setup contributed to your issues, but tomorrow I’ll play with the code you posted there and see if I can tease out what went wrong with it.
Note also, there is such a thing as showing to the LEDs too quickly. Another possible sort of problem may have been too much CPU time with interrupts disabled.
(I frequently use delay to slow frame/update rates way down so I can see what’s happening with each frame).
Well, one thing is for sure, having updated to the 2.1 branch beta 1, I’ve got heaps of problems with my first two strips not working right. Gah, why didn’t I back up the old one? 
Re-pull the branch - I just fixed the 48mhz code - 24 is going to be trickier.
(Or just run at 96mhz)
Can’t, the beta just doesn’t work for me. The first two strips are hosed. I restored the old version and everything is working well again. I don’t really mind the MHz thing so please don’t bother on my account!
And I’ve fixed 24mhz but the net connection my computer is on is down, so it won’t get pushed until tomorrow.
Also fixed a time correction issue that mark noticed (for those of you playing along at home, that’s issue #47 on the github issue tracker) - but won’t get pushed until morning.
and now it’s all pushed, and i should really sleep.
How does it go with the SparkCore porting?
Or does someone have a tip for getting a LPD8806 strip driven of it?
I am compiling from windows, so can add library-files easy. (i hope so) haven’t received my core yet.
We’re eager to get it ported! The STM32 chipset is pretty popular and we like the SparkCore in particular. (Dan and I each own one already!)
Realistically, though, we’re stuck like a lot of other developers of complex multi-file libraries, waiting for the SparkCore team to come up with a practical way of dealing with “external libraries”; we want FastLED to be totally supported for all SparkCore users, so we need them to provide a library solution.
Did I miss some news there, or are they still temporarily advocating pasting everything into one big file? I try to keep on top of this because, as I said, we’re eager to support the SparkCore, but I don’t read their forums every single day so I may have missed a new development there.
As you know they are working on a library solution.
As it is now, the Web IDE supports multiply files, you can manually add files (file.h and file.cpp), by clicking (+) in the Web IDE, but then you’ll have to add, name and copy-paste code for every single file in the library…
They are working on a GIT solution that will allow you to pull an fork you code and such, so working with external files will be much easier. Don’t know when that part are ready.
But right now i think it’s easier just to build locally, just like with the Arduino IDE. Actually i think you can build and upload code to Spark Core with the Arduino IDE.
Else here is a tutorial on how to install NetBeans and compile locally on windows.
Then adding multiply files isn’t a problem, just edit “http://build.mk” to include the files .
Witch IDE do you use to program your Spark Core? I don’t really find their IDE tempting yet…
Looking forward to the port! 
I don’t really have much experiens porting library’s yet, but for interest what would it take porting LPD8806 to Spark Core. Except adding “applications.h” instead of “wiring.h”?
Thanks for the pointers to the current approaches over there.
As for porting, part of what makes FastLED so fast is that basically all of the low-level hardware access is written in assembly language and is highly specialized for each chipset. The SparkCore uses an STM32 chip (with an ARM core), which we haven’t ported to yet. It’s on our hot list though.
We have ported to: numerous different ATmega’s, a couple of ATtinys, the K20 (ARM used in Teensy3/3.1), the SAM (ARM used in Arduino Due and Digistump DigiX.
The STM32, used in SparkCore and Maple, is probably up next.
Glad to hear that!
I am curious to see how fast i can update my pixels over TCP!! Hoping the frame rate is acceptable.
Hi,
No doubt I am doing something wrong but: If I compile using the Arduino IDE 1.0.5 I get lots of these messages:
impossible constraint in ‘asm’
I tried to compile for both the ATTiny85 and ATTiny84.
Thanks
Nico