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....
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.
The red hand on the watch faces in the pictures are second hands which the NRF52832 handles fine with barely noticeable flicker. The problem with faster than one second is that the flicker caused by unbuffered update becomes very obvious which is why you need buffering. I tried it on the ROCK and because it has the double buffered lcd_spi_unbuf and the faster 32MHz SPI it can manage about 150ms for a complete screen rewrite of 240x280 pixels.
Don't worry about formatting, just type in the text and we'll take care of making sense of it. We will auto-convert links, and if you put asterisks around words we will make them bold.
For a full reference visit the Markdown syntax.
© Espruino, powered by microcosm.
Report a problem