Update2: all my FastLED problems went away when I stopped trying to C++ inherit from CFastLED / I’m pretty damn certain my code was fine, but was triggering a subtle C++ inheritance, maybe compiler bug.
Update: Dear FastLED devs, do you know if CFastLED::show(); when inheriting from FastLED and FastLED.show() are indeed supposed to be the same thing?
For me, I get one that works, and one that crashes/hangs teensy. See my last update in the comments.
@PaulStoffregen , I’m not sure if teensy 3.1+FastLED support is better here than on https://forum.pjrc.com/threads/ . Are you generally the maintainer of FastLED for teensy, or are the FastLED devs in charge of it, along with a few patches from you from time to time?
Update: while the problem is gone with ESP8266, I can reproduce the same behaviour on ESP32, so it’s likely that it’s not a teensy toolchain problem, but likely something not obvious with my code that is platform dependent.
Problem (also posted on https://forum.pjrc.com/threads/50526-Another-vexing-problem-with-FastLED-(lastest-version)-code-hangs-on-show()?p=172866#post172866 ):
FastLED show() seems to be super slow on teensy 3.1/3.2 (as in one second+ per show() or sometimes even 15mn per show() after power cycle).
Then, I don’t change my code at all, I upload another sketch that does neopixels some other way, that one works at full speed and unlocks something so that when I re-upload my same sketch that was super slow, it works at full speed, until power cycle again.
I then put the same code on ESP8266, and it just worked, no problems at all.
I can get other test FastLED code working on teensy, but clearly my code is causing a weird issue, and I’m not sure if I have a weird bug that only affects teensy.
Code: https://github.com/marcmerlin/FastLED_NeoMatrix/blob/master/examples/MatrixGFXDemo/MatrixGFXDemo.ino
You don’t need a matrix to run it, a simple neopixel strip should be enough, or even just looking at the serial output hanging or not hanging should do it.
Thanks for looking/suggestions.