Hey
I have a strange problem and running out of ideas to find the root cause.
I have already simplified my setup in order to get closer to the root cause.
I use the latest FastLED version together with LEDMatrix from AaronLiddiment.
In principle I draw a simple vertical line in the setup routine. Then in the loop you’ll find only this code :
************************************
if (longTimer.fire())
{
leds.ShiftRight();
Serial.println(“Shift”);
}
FastLED.show();
***********************************
Understand the function longTimer.fire() as a replacement for the “Blink without delay” example with 200ms. So nothing fancy.
This means every 200ms the if statement is true and all leds will be shifted to the right.
The Serial feedback tells me this always works.
I can see a moving vertical line as soon as I put the FastLED.show() function INTO the if block.
However, as soon as the FastLED.show() function is OUTSIDE the if block everything stays black.
Any ideas?
The controller is a Teensy 3.2
It is likely that longTimer.fire requires interrupts to function (at least to track the passage of time, adjusting time also requires interrupts) - you don’t mention what leds you are using, or what mcu you are working with - but my guess is that by basically calling FastLED.show nonstop, the time is never getting a chance increment. On some hardware platforms, FastLED attempts to adjust for this - but without knowing how your longTimer.fire is written, there’s no good way to know whether or not it will work with those adjustments.
@Daniel_Garcia
No it works without interrupts. Just replace the function with the solution from the “blink without delay” example and you’ll get the same. I’ve tried it 
I’m using the teensy 3.2 with Ws2812b LEDs.
I’ve basically just wrapped the “blink without delay” example into a separate library to make it easier to use for me. I’ve already used it in many different projects without any problems. And why not, it’s just a simple comparison of Millis everything it’s called
And by the way, I should see at least the starting line from the setup routine. But even this is not visible. And as I mentioned, the shift output on the serial monitor always works.
Blink without delay still depends on the clock/time - which still depends on interrupts running and/or the accuracy of the library’s time adjustments. It would also be really helpful if you posted your entire .ino to gist so I could see the entire code setup (there’s a reason the faq asks that folks do all of this when posting questions). That said, By calling FastLED.show constantly with no delay, which is what you’re doing when calling show outside of the if block you run the risk of creating a situation where the clock doesn’t advance, or if it is advancing, is advancing very slowly.
@Daniel_Garcia
You’re right, it’s better to post the code :
I’ve removed my own timer functions and used the “blink without delay” instead to avoid confusion. But as I said, the result stays the same.
I also don’t know exactly what you mean when you talk about “the clock”? Something inside the FastLED library? It can’t be the millis timer because the serial print happens exactly every 200ms. It’s just FastLED that doesn’t do anything.
Seeing the whole thing - my money is still on the led writing starving the interrupt handler for advancing time enough to keep millis from updating reliably. Don’t leave the FastLED.show out side like that in this case. Or throw something in like a delay(1) after the call to FastLED.show (might have to experiment with how much of a delay you need).
Funny sidenote, as soon as I add a simple “delay(1);” directly after the FastLED.show() everything works again. But FastLED.delay(xxx) doesn’t work.
Unfortunately I can’t accept real delays in my program.
Ah - you weren’t clear that you were still seeing the serial output every 200ms after you moved the call to show outside the if.
Older versions of FastLED.delay could get caught in this same kind of time blocking loop - I fixed it at some point to always do a delay(1) to prevent something like this from happening.
Then pick a frame rate and use the blink without delay technique to ensure you don’t write at a higher frame rate than that. Realistically speaking, with that many leds, you won’t want to try going above 100fps, give or take (it’ll take about 8ms to write out the led data).
After some testing I found out that I need a “delayMicrosecond(100)” as a minimum to make it work properly.
But again, delays are not ok for the main setup.
I’ve also tested the FastLED.delay(xxx). Doesn’t work.
@Daniel_Garcia
Thought about this framerate option as well. But it feels like a workaround.
And what about temporal dithering?
Had the hope to use this feature.
Again, all FastLED.delay does is call FastLED.show in a loop until the right amount of “time” has passed - of course, if the interrupts are being blocked and the time value is never advancing it can end up in an infinite loop. So - again, use the blink without delay technique to limit yourself to calling show, say, once every 50ms (or 20 or 10) - but don’t create a situation where FastLED.show is being called constantly, back to back, with no real gaps of time between calls to show.
Dithering requires a frame rate of above 100fps to be active, you have enough leds that it takes 8.5ms to write a frame out - 100fps would chew up 850ms per second (and maybe closer to 900) of time just writing out raw led data, not leaving much time for anything else.
And it is a workaround - it is a workaround for the fact that marking the passage of time on these chips is itself a workaround for the chips not having a real clock in them. If you don’t want to deal with this piece of it, switch to an led that doesn’t require disabled interrupts.
(Also make sure you have the most recent version of the FastLED library - which does allow interrupts on some arm platforms, including the teensy 3.2 - and should allow the clock to update)
After some testing with the “Blink without delay” version to limit the FastLED.show() calls I found out that I need to set it to 10ms. Otherwise it’s not working. A little bit strange because a real blocking delayMicroseconds(100) works as well.
You’re right, a real serial LED would have been the better option. But the now the hardware is already build and I don’t want to start from scratch
And Interrupts are not only needed for the timer in my case. So I need them. Also one of the reasons why I’ve choosen the teensy 3.2 because I expcted to have enough resources in order to realize everything properly. Turns out I’ll also invest in “better” LED’s the next time.
Indeed it takes 9435 microseconds to call FastLED.show() once.
Ok, the delayMicroseconds(100) doesn’t work anymore as soon as I overclock the teensy to 120MHz and change the compiler to fastest code. This will squeeze one FastLED.show() call down from 9435ms to 9000ms.
Anyway, I guess I’ll just continue with manually slowing down my FastLED.show() calls. But maybe this is interesting for other people in the future.
Thanks for your help @Daniel_Garcia !!!