I’m running into a strange situation where a fairly simple pattern runs for 30-60 seconds and then freezes for 5-15 seconds, and I can’t figure out why. I’ve tried it on two Pixelblazes (both V3s running firmware 3.20), with and without the web UI connected (to eliminate the webserver/websocket load), and get the same result.
When it freezes and I have the web UI open, I can see the FPS counter updating (the value stays in the same range as normal) and the free memory value stays the same, but the LEDs don’t update.
I’m not doing any array allocations in beforeRender() or render() and there’s no recursion so I don’t think I’m blowing up the stack frame, and the Pixelblaze interpreter doesn’t do garbage collection so I’m puzzled what could be causing it.
@pixie, it’s pausing when the variable accumDelta exceeds 32767 and goes negative. It stays paused until accumDelta wraps back to positive again. I’m sure it’s a typo or something like that – just a little hard to spot when it’s running!
Overflowing 32768, to -32767, is one of those things people easily miss. It’s a 16.16 math system the PB uses, so even though it’s 32 bit, it’s really just 16bit math and if you are counting millis, that’s really a short number of millis, just 32.768 seconds… So then it runs over…
That wouldn’t have occurred to me for at least another week! Partly because all my troubleshooting efforts were causing recompiles and so restarting the counter…
I used to use accumDelta = 0, but after seeing the accumDelta -= targetDelta idiom in one of @wizard’s posts I switched because I could see that it would keep the rhythm better – unless, as in this case, the renderer takes longer than targetDelta to complete. Now that I know what the cause is, %= works better.