I bought a Presto right before christmas and have spent the first days of the new year days to create a little work desk companion that displays my working time, the date, time, and calendar week, room temperature and co2 levels, upcoming appointments, and weather stats.
The code is available here for anyone who is interested.
(If anyone can tell me how I can grab the screen buffer and write it to a file instead of doing “screenshots” like a caveman with a camera: feel free to tell me :D!)
I’m quite satisfied with the result. The only thing left to do is optimize performance. Right now I have about 140ms worth of draw calls which is about ~7fps and doesn’t feel very snappy. Around ~60ms are just for the little weather icon. Decoding it every frame seems very wasteful. I also wonder if there is a way to do partial screen updates, because I actually know when to update which tile (and therefore which specific region of the screen) on the display. Any tips, tricks or feedback is very much appreciated :).
Got partial screen updates to work! Now running at ~58 FPS. That’s more like it :).
It originally didn’t work when I started tinkering so I ignored it and used the full screen updates instead. The missing piece was setting layers=1 when instantiating the Presto class.
this is really cool work - I am inspired by your layout and stuff.
Pretty much appreciated you sharing your work here…
Also, your findings working with layers for partial updates is something I will keep in mind for my tinkering, as well. I read about this in the documentation already, but haven’t applied it to my work so far…
In my day job I’m a web application developer so I have a little design experience I can draw from :). Glad you like it!
The screenshot tool is just a few lines now, but it was quite the adventure… embedded development isn’t my usual playing field and the documentation has some room for improvement! It boils down to a few insights: firstly that I can access the framebuffer with the buffer attribute on the Presto instance and secondly how the data in the framebuffer is structured. The first was a lucky find when I looked at the implementation of the presto module. The second was a bit harder. At some point I read the Micropython framebuffer docs and noticed that RGB565 is the only framebuffer format with color support. So I reckoned that it must be that. Only that the bytes in the buffer are swapped compared to what imagemagick expects for the RGB565-format which I use to convert the data. The rest is “just” some basic python plumbing for running a little server on the Presto that accepts requests from a client, writes a single line with the image dimensions, and then the entire screen buffer as raw data. Transforming the data to a proper image format on the Presto itself crashed the little guy – I guess it ran out of RAM. I first wrote the image data to an SD card but soon realized that I am way to lazy to plug these in and out :).
…would you please be so kind as to share a meaningful code snippet with us to make our lives easier to no re-invent the wheel? ;)
a) read out the buffer
b) save as screenshot
I could also imagine, once you have read out the screen buffer, one could easily manipulate the values for partial screen updates and/or save portions for later usage…I am just wondering whether this fits into the memory or needs to be saved to card…
