-
Yes. However I guess it is not the display itself that consumes that much power on update it is the CPU wakeup and activity to produce something drawable before sending the result to display, here it is also the JavaScript interpreter that takes milliseconds to execute even few lines of code
Interesting. That was one of the things that was specifically called out in Pebble development. The display was updated a horizontal row at a time, and a whole row had to be sent. So even if you were only updating a rectangle 10 px high by 3 px wide, you'd still have to send the entire 10 rows. And the display's power consumption increased dramatically when updating. Granted, waking the CPU to do that also took a bit of power, but that was one issue that was raised.
Regarding the second point, with many years of embedded work under my belt, I'm no stranger to keeping the code as simple and fast as possible. That's a necessity on really constrained devices like the Intel 8051 that I first used back in the 1980s. So keeping that mindset will certainly help writing code here.
dgnuff-
That was one of the things that was specifically called out in Pebble development. The display was updated a horizontal row at a time, and a whole row had to be sent. So even if you were only updating a rectangle 10 px high by 3 px wide, you'd still have to send the entire 10 rows
Yes, that is true also here, display is updated in whole lines. Framebuffer is in RAM, pixels are updated as needed, then at flip() time whole area between min and max modified Y coordinate is sent from RAM to the display (3 bits per pixel - 66 bytes per line).
And the display's power consumption increased dramatically when updating.
the watch has LPM013M126 display, found two datasheets for A and C versions, both have same table on page 9
https://www.j-display.com/product/pdf/Datasheet/4LPM013M126A_specification_Ver02.pdf#page=9
https://www.j-display.com/product/pdf/Datasheet/5LPM013M126C_specification_ver03.pdf#page=9Both values (no update vs data update) are very very low (116uW=~40uA at 3V absolute maximum or 10/3=3.3uA typical).
CPU draws 4mA when not in sleep, SPI DMA transfer draws about 1mA (CPU can sleep) so both drawing and sending data takes far more power on CPU side.
datasheet says max SPI frequency is 2MHz (page 10), we use 4 here https://github.com/espruino/Espruino/blob/master/libs/graphics/lcd_memlcd.c#L401
=500KB/s, whole display is 11.6KB so about 23ms (at ~1mA) to send over SPI (or 0.13ms per line)I'd guess the javascript code to compute and draw anything to framebuffer takes more than 23ms .
Maybe on Pebble if the drawing code is native then updating screen over SPI may take proportionally more time than producing the change as the SPI frequency is quite low. But in both cases it is the nrf52 chip that consumes most of the energy here, not the display.
But still for the whole watch it can be said that "power consumption increases dramatically when updating the screen" because otherwise everything sleeps most of the time. Well, unless you have backlight or GPS turned on :-) https://www.espruino.com/Bangle.js2#power-consumption
fanoush
button press is taken by first unlocking and second entering menu. Not sure you get touch event when input is locked but after pressing button to unlock you should get the touch event when screen is touched.
Yes. However I guess it is not the display itself that consumes that much power on update it is the CPU wakeup and activity to produce something drawable before sending the result to display, here it is also the JavaScript interpreter that takes milliseconds to execute even few lines of code.