More traditional watch faces look great on the SN80. Here are some new ones.
The first is based on @HughB 's Bold clock face. In general, the dial for these faces take some time to display and the watch looks terrible if you have to redraw the dial each time the hands move or the LCD turns on. The trick is to ensure that the hands do not overlap the dial markings and consequently as long as the screen is never completely cleared, you can leave the dial undisturbed in the LCD display memory so that it is instantly displayed on power on etc.
@yngv126399 I started on the SN80 using a version of your LCD driver and I noticed that it uses a lot of memory. I think the problem is that the memory used for the initialisation data ST7789_INIT_CODE is not released. I have programmed it as separate commands but you could just move the declaration into dispinit which should also work. In addition, my current version of the driver in the WatchApps repository uses real delays rather than timeouts. This reduces start up glitches and means you do not need the 500ms timeout delay at the start of apps.
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..
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....
© Espruino, powered by microcosm.
Report a problem