One frame behind
I've been playing with BlinkyTape for two nights now, and I first noticed it with the PatternPaint demo application.
The LED state is one frame behind the last one sent and "rendered" with the 0xFF byte.
In my test app, I can also send 60 red tuplets followed by the FF, at which point, the current animation stops.
I then send 60 green tuplets with their FF and the strip will change to red.
The next full frame I send causes it to render green, etc.
Sending two FF bytes does not help, nor do delays between each tuplet/byte.
Only sending another full frame causes it to render.
So far, I've worked around this by sending each full frame twice if it's only being rendered temporarily.
When running an animation this is less obvious, but still exists.
Has anyone else noticed this or is it known or already fixed?
Thanks
--
Deanna
The LED state is one frame behind the last one sent and "rendered" with the 0xFF byte.
In my test app, I can also send 60 red tuplets followed by the FF, at which point, the current animation stops.
I then send 60 green tuplets with their FF and the strip will change to red.
The next full frame I send causes it to render green, etc.
Sending two FF bytes does not help, nor do delays between each tuplet/byte.
Only sending another full frame causes it to render.
So far, I've worked around this by sending each full frame twice if it's only being rendered temporarily.
When running an animation this is less obvious, but still exists.
Has anyone else noticed this or is it known or already fixed?
Thanks
--
Deanna
Comments
If so, I'll update the docs to recommend that sequence instead. It's very likely a bug in the BlinkyTape firmware.
Edit: To be a little clearer, try sending 0x00 0x00 0xFF instead of 0xFF at the end of the frame.
https://github.com/Blinkinlabs/BlinkyTape/blob/master/ProductionSketch/SerialLoop.cpp#L11
Sending FF FF FF or any other combination of 3 bytes with an FF in works. (but 00 00 FF has the best result of just "rendering" once.