What’s good hardware to run FastLED on? I need to get some new controllers and they wont be Teensys this time around, since I never got the start hang thing fixed. Any other ARM-based solutions with a bit of grunt?
Start hang thing? Teensy 3.0/3.1 is still my primary platform that I do most of my dev with. The due is another supported arm platform - more pins but less performance. The rfduino will be coming soon but that is only a 16mhz arm chip.
Yeah, the hang on power up. Takes me maybe ten power cycles to get my code to run. Runs every time flawlessly if I just upload it from a PC. Me and some other guys reported it on Teensy forums. Never worked out what it was, decided life was too short…
Teensy 3.1 works great for me with WS2801s. I’d suspect your power supply.
Yes everyone says that. Its a 20a supply, its fine. It still does it on a lab PSU, I’ve been through this all at considerable length.
Was this with the 3, 3.1 or both?
Also, you know there were multiple bugs with FastLED.delay (and a couple of other minor things) that were on the 2.1 beta branch that got fixed as a part of releasing 3.0. That said, I have, easily, a half dozen things around here running FastLED 3.0 based projects on both teensy 3 and 3.1 running anywhere from a dozen to a few hundred leds. Though, even then, I never quite saw the behavior that you were seeing (specifically the multiple attempts to get it to start up).
As for other arm platforms, as I mentioned above, there’s the due (and the digix, which exposes even more pins), and eventually the rfduino (and by extension the nrf51822).
After that, for arm platforms, it will likely be the STM32 (I believe that’s what the SparkCore uses, no?) and then maybe the LPC810 series. That said, I don’t think there’s anything out there that approaches the power of the teensy 3.1 without getting into beaglebone black territory (the due comes close, but it’s still only a cortex M3 instead of an M4)
All that said, if you want to send me the latest version of the code you were trying I can take another swing at a) recreating the problem and if so, fixing it. (Something about the behavior you were having in that thread screamed software to me - just a matter of where)
Daniel, thanks for taking the time. I appreciate you giving me your thoughts on what I was asking as well as providing new insight on what might be the teensy issue. My code still uses 2.1, I wasn’t aware of relevant fixes. The whole delay issue seemed to be the most predictive if failure so I’m encouraged to rebuild with fastled 3.0. I really like the teensy hardware too so your thumbs up is very helpful.
I’ll send code after I drop it n fastled 3 and try some more testing. Some time after my utility company deigns to switch the power back on 