update only part of the screen?

[pootle]

Is it possible to update only part of the screen?

The inky interface only seems to allow entire screen refresh. Would it be possible to update only part of the screen - even if this meant not using deep sleep this might make small updates a lot faster.

[Gadgetoid]

There's no hardware support for partial refresh, so unfortunately this is impossible. On bi-colour displays it's basically useless anyway as the way the display works is fuzzy enough that it distorts pixels around the partial update area (we saw this on our original prototypes with a different display part).

[MattiJarvinen]

Damn... Thanks for the info.

[chrislast]

The mono version at https://www.china-epaper.com/uploads/soft/DEPG0420A01V3.0.pdf suggests that SPI command 0x22 0xC0 will do a partial update in Section 13.4 even though it doesn't show it as supported in the command table. The multicolour manual at https://www.china-epaper.com/uploads/soft/DEPG0420R01V3.0.pdf doesn't even suggest it although it does still support the partial ram address commands 0x44, 0x45, 0x4e, 0x4f as well so it would probably work, possibly badly for the reasons Gadgetoid mentioned.

It looks like you'd have to keep the EPD powered up between partial refreshes to work correctly so you'll sacrifice some current. Not sure whether gadgetoid kept it powered when testing...

Anyway I came here wondering the same thing so now I know thanks for the answer :)

[STrRedWolf]

Just saw this and wondering if the Inky Impression was able to partially update. Different hardware and all.

[Gadgetoid]

Impression also cannot do partial updates for largely the same reasons. Frustrating because the update cycle is so long that you lose a bunch of ambient information for almost half a minute.

[juj]

There's no hardware support for partial refresh, so unfortunately this is impossible. On bi-colour displays it's basically useless anyway as the way the display works is fuzzy enough that it distorts pixels around the partial update area

This statement seems a bit self-contradictory, no? First stating there is no partial refresh support, but then saying that when doing (such nonexistent?) partial refresh, it was observed to distort pixels around the partial update area? I wonder if the intent was to write "there's no software support for partial refresh", or I wonder if these statements were referring to different boards, or something like that?

Btw, even if partial update would be distorting pixels around the partial update area, maybe it could still be useful for some use cases? e.g. for UI HUDs that have distinct sections for different data, and blank white/black area between those sections?

It looks like in the library at least there is code that submits an update rectangle:

inky/library/inky/inky.py

Lines 301 to 308 in 6162b5f

	self._send_command(0x44, [0x00, (self.cols // 8) - 1]) # Set RAM X Start/End
	self._send_command(0x45, [0x00, 0x00] + packed_height) # Set RAM Y Start/End
	# 0x24 == RAM B/W, 0x26 == RAM Red/Yellow/etc
	for data in ((0x24, buf_a), (0x26, buf_b)):
	cmd, buf = data
	self._send_command(0x4e, 0x00) # Set RAM X Pointer Start
	self._send_command(0x4f, [0x00, 0x00]) # Set RAM Y Pointer Start

which is currently hardcoded to send a full update rectangle. Maybe changing that might be something to play with? Are those fields honored by any of the display controllers?

Thanks btw for diligently explaining the LUTs at

inky/library/inky/inky.py

Lines 111 to 157 in 6162b5f

	"""Inky Lookup Tables.
	These lookup tables comprise of two sets of values.
	The first set of values, formatted as binary, describe the voltages applied during the six update phases:
	Phase 0 Phase 1 Phase 2 Phase 3 Phase 4 Phase 5 Phase 6
	A B C D
	0b01001000, 0b10100000, 0b00010000, 0b00010000, 0b00010011, 0b00000000, 0b00000000, LUT0 - Black
	0b01001000, 0b10100000, 0b10000000, 0b00000000, 0b00000011, 0b00000000, 0b00000000, LUT1 - White
	0b00000000, 0b00000000, 0b00000000, 0b00000000, 0b00000000, 0b00000000, 0b00000000, NOT USED BY HARDWARE
	0b01001000, 0b10100101, 0b00000000, 0b10111011, 0b00000000, 0b00000000, 0b00000000, LUT3 - Yellow or Red
	0b00000000, 0b00000000, 0b00000000, 0b00000000, 0b00000000, 0b00000000, 0b00000000, LUT4 - VCOM
	There are seven possible phases, arranged horizontally, and only the phases with duration/repeat information
	(see below) are used during the update cycle.
	Each phase has four steps: A, B, C and D. Each step is represented by two binary bits and these bits can
	have one of four possible values representing the voltages to be applied. The default values follow:
	0b00: VSS or Ground
	0b01: VSH1 or 15V
	0b10: VSL or -15V
	0b11: VSH2 or 5.4V
	During each phase the Black, White and Yellow (or Red) stages are applied in turn, creating a voltage
	differential across each display pixel. This is what moves the physical ink particles in their suspension.
	The second set of values, formatted as hex, describe the duration of each step in a phase, and the number
	of times that phase should be repeated:
	Duration Repeat
	A B C D
	0x10, 0x04, 0x04, 0x04, 0x04, <-- Timings for Phase 0
	0x10, 0x04, 0x04, 0x04, 0x04, <-- Timings for Phase 1
	0x04, 0x08, 0x08, 0x10, 0x10, etc
	0x00, 0x00, 0x00, 0x00, 0x00,
	0x00, 0x00, 0x00, 0x00, 0x00,
	0x00, 0x00, 0x00, 0x00, 0x00,
	0x00, 0x00, 0x00, 0x00, 0x00,
	The duration and repeat parameters allow you to take a single sequence of A, B, C and D voltage values and
	transform them into a waveform that - effectively - wiggles the ink particles into the desired position.
	In all of our LUT definitions we use the first and second phases to flash/pulse and clear the display to
	mitigate image retention. The flashing effect is actually the ink particles being moved from the bottom to
	the top of the display repeatedly in an attempt to reset them back into a sensible resting position.

and #13 (comment) . That is very helpful information. (also good information at https://forums.pimoroni.com/t/my-inky-phat-clock-refresh-speed-question/6955/5 )

[Gadgetoid]

This statement seems a bit self-contradictory, no?

Not really, I can assert that cats can't fly but I still have a very thorough understanding of the drawbacks that might occur if they could 😆

The technology in e-ink is not especially varied, though I'll admit I haven't tried to perform a partial update since those underwhelming attempts with some of our first products- so maybe things have improved!

maybe it could still be useful for some use cases?

You'd be forgiven for thinking so, but it really does kinda suck. It's also a balancing act between usefulness and the time investment to get it up and running, update the libraries, do releases and so on for the - looks up at replies to this issue from 2018 - I think it's fair to say handful of people who might use it.

See also: #138

I welcome anyone to emphatically prove me wrong, invest the time and do something useful with it.

Here's a fantastic example of someone absolutely schooling me on the finer points of e-ink - https://github.com/antirez/uc8151_micropython