-
I simply invoke
process.memory()from the Web IDE console to get the current memory usage. The SN80 has about 2500 espruino memory variables in total - the change to the LCD driver frees up about 300. In general, real delays are a bad idea in Espruino, however, Timeout delays let other bits of code run which cause problems at system initialisation which is why I am using the real delays which stop anything else running while the LCD driver initialises the screen.A sweeping second hand would need to update the screen every 166ms and use a screen buffer as you say to avoid excessive flicker. I tried it as an experiment using a full screen 2 bit image buffer and it took 300ms for each update. It might work with @fanoush 's buffered driver....
jeffmer-
Maybe 'sweeping' was a poor choice... just a second hand would do. (Perhaps an 52840 could handle the former?...) what I've noticed is that the YFit firmware (for the SN80-Y) has a few watch faces with a second hand that updates pretty darn well -- likely uses an optimized algorithm to determine what part of the screen to update.
yngv126399
Fantastic job on the faces! Agreed that the display is not the speediest and a reminder to anyone wanting more speed to look into @fanoush's work for the P8 to have a buffered solution (with fewer colours perhaps, but capable of refreshing a sweeping second hand).
And thank you for pushing the driver forward.. it was just to get it off the ground and I haven't put more time into it since. Glad you freed up the memory (BTW: what are you using to profile the driver? I'm really not well versed in optimization, and I really need to be!) and cleaned up those timeouts. I think I'll just grab your baseline from here..