More-or-less what it says on the tin, and especially for the Inky Frame where the work being waited on is a ~40-second operation happening on the display controller. Either something like
display.update(blocking = False)
or
display.set_blocking(False)
display.update()
Exposing a matching is_busy() and/or busy_wait() would help use this safely.
Reasoning: I have a thin-client which does two things that are interacting unfortunately here:
update()ing the image to blank before setting image data and update()ing again, to work around e-ink burn-in
That means the socket has to be held open, effectively buffering the image in the network, until that first update() has finished the e-ink dance---and makes having reasonable timeouts tougher. Ideally, the sequence would be:
Clear the framebuffer, and set the eink controller update()ing, non-blocking
(As far as I can tell, the earlier waitshouldn't be conditional, since if execution proceeds past that with the controller still busy, commands will just get ignored---or worse, some of them ignored if it becomes ready midway.)
At this point the image data has already been sent to the controller, so start overwriting the PicoGraphics framebuffer with the streamed decode from the network, and close and finish that off.
Block for the first update() to have completed, then start a second to send and display the new framebuffer contents.
(Yes, the network contents could be buffered to system RAM, flash, or an SD card, but only the latter reliably has enough space, and the framebuffer is right there to save the writes and further power overhead if PicoGraphics wasn't busy-waiting. :) )
More-or-less what it says on the tin, and especially for the Inky Frame where the work being waited on is a ~40-second operation happening on the display controller. Either something like
or
Exposing a matching
is_busy()and/orbusy_wait()would help use this safely.Reasoning: I have a thin-client which does two things that are interacting unfortunately here:
update()ing the image to blank before setting image data andupdate()ing again, to work around e-ink burn-inThat means the socket has to be held open, effectively buffering the image in the network, until that first
update()has finished the e-ink dance---and makes having reasonable timeouts tougher. Ideally, the sequence would be:update()ing, non-blockingis_busy()/busy_wait().)update()to have completed, then start a second to send and display the new framebuffer contents.(Yes, the network contents could be buffered to system RAM, flash, or an SD card, but only the latter reliably has enough space, and the framebuffer is right there to save the writes and further power overhead if PicoGraphics wasn't busy-waiting. :) )