You are reading a single comment by @allObjects and its replies.
Click here to read the full conversation.
Espruino is a JavaScript interpreter for low-power Microcontrollers. This site is both a support community for Espruino and a place to share what you are working on.
@allObjects
There are some nice challenges in the implementation, I feel... and can think of right of the bat...
The synchronous and uninterrupted transmission of the screen triggered by the
.flip()is a great start. I do though not know about the side effects that keeps you BLOCKED / un-interruptable busy for 40% of the time assuming a.flip()happens (at least?) about every second... It does with the (implied) clock application, when seconds are in use...To stay responsive - to remote control commands - I'd separate the sync out from the flip with a snapshot buffer and frequency limiting timer, and also make the loop over the chunks javascript process interruptible. For the actual transmission, I would implement a (multi queue, queue, multi-priority) queued channel / time multiplex system so that each packet can transmit what ever is of highest priority. Load of the queue would slow down the frequency of the display sync events (delay the completion of the current one, up to the point with deferring the start of the next one)... For the screen streaming, it become then like a flip-flip or double-flip / multi-flip pattern when looking from start to finish of one complete screen update.
A simple setup with only a few things but very interesting and sufficient to study the many issues communication w/ band limitation faces... and visualize what actually is going on.
Side note: Version 2v00 celebration w/ my 2k-th post... ;-)