*Summary*
I'm going to make a quick fix to prevent your program from crashing and
work on a longer fix that prevents the root case.
Note... BP is on code freeze at the moment. No new releases will go out
till mid September. But you can always use the dev branch.
I see three questions in your email:
*Question 1: the exception!*
Fascinating! First time I have personally seen this error message, but
it's there for a reason...
What it means is that (you could have guessed this part) the computer sent
the AllPixel a packet of the wrong length.
The fact that you never see this in unthreaded mode, and only occasionally
in threaded mode, means that it's almost certainly a race condition
<https://stackoverflow.com/questions/34510/what-is-a-race-condition> due
to threading.
Threads allow you to do "two things at once". A race condition means that
two threads are trying to change the same variable at almost exactly the
same time.
In this case, I believe that BP is probably starting to send the next
packet before the previous one has completed - but only occasionally. :-/
Actually... no. What's happening here is that BP doesn't finish sending the
first packet fast enough because it got context switched off to something
else in the middle of the send. The AllPixel will wait up to 100 cycles
with no data before hard failing, but after that (around 200ms) it will
simply hard fail with that error because it never received all the data.
Now, with regards to your fix, Tom, ([PR #414](
https://github.com/ManiacalLabs/BiblioPixel/pull/414)) that actually will
probably fix this particular issue.
Daniel, as stated above, we are in master branch code freeze, but I'd be
happy to cut a beta release to PyPi so you could install that without
having to pull the code manually.
Race conditions are notoriously hard to figure out, though this is
something I have a lot of experience with. Still, I think we're going to
have to fix this in two ways - a lame bandaid first, and then a proper fix
later.
The "lame bandaid" is necessary anyway - we should just report that
problem and go on, not crash. It's likely the result will be a partial
frame, or even a missing frame, but it's better than dying.
Again... AllPixel is everything or nothing. There's no partial frame. If it
doesn't get the whole frame it throws it out and waits for another.
The proper fix is to figure out where the race condition is, and make sure
it cannot happen. Figuring it out might take a second or a month,
unfortunately.
Sadly, this is on the BP side, not the AllPixel side.
Also, Daniel, when you used a full computer instead of the Raspberry Pi,
what OS are you running. I hate to say this as I love open source and even
work for Red Hat but the Serial stack on Linux is kinda crap. On Windows,
if you send a serial packet instead of making the software wait for each
sub-packet to be sent, windows buffers it and takes care of it on it's own.
So this issue is largely fixed.
I'll immediately prepare the lame bandaid solution and get it out in both
master and dev sometime today (I'm going to wait until Adam wakes up to get
his approval for the results), so that will at least get you going, and
I'll also start to look at the race condition.
Again, note above. This is not going into master for a few weeks. Sorry,
but I just can't have it right now.
*Question 2: is there a way to do only partial updates to an AllPixel?*
I am not an expert on the AllPixel but I don't know of any way to do
that. Adam will answer this authoritatively.
No. The way FastLED works (which is what the firmware uses) I could
certainly only update part of the display but then you'd get half one
frame and half another. I mean, yes I could do this, but the firmware does
not support it now.
···
On Tue, Aug 29, 2017 at 4:22 AM, Tom Swirly <tom@swirly.com> wrote:
Basically, 75% of the names in BP2 used underscores_like_this and 25% used camelCaseLikeThis. Because we had a chance to change with 2->3 I changed, well, nearly all the camelCase to be underscores.