04/14/2017 at 16:14 •
With eink display, you cannot just send "set pixel black", "set pixel white" or "set pixel grey", the brightness of display depend on a sequence of voltage applied for a certain time on pixel.
The table found in "Source driver" section on Essential Scrap site is incomplete, when you send 0b10, you do not actually set pixel white, you apply a voltage to set the pixel lighter, and 0b01 to set the pixel darker. It is why in his implementation, Petteri must apply multiple times the value to obtain the wanted color and apply the voltage longer than the screen can achieve. This approch will works, but the problem is it will be pretty slow when you want to update the screen.
To get around that and get better result, eink manufacturer introduce what they call "waveforms table". This table describes the transition you must apply to obtain the faster results to go from one color to another.
An example if you want to go from white to black, they can say that you will achieve that in 4 clock cycle in the form of 0b10 0b01 0b01 0b01, to go from grey to darker grey, the table can be something like 0b01 0b01 0b10 0b01, etc (it is an example, in general it is about 20 or 40 cycles).
These waveforms are very difficult to obtain, since each eink display will have his own table, and the table will depend on temperature as well ! It is why I took some times to reverse engineering E-Ink (PVI) and Freescale binary format to extract some of these table to use them in the FPGA.
Note there is multiple tables which correspond to different usage optimization : black and white, 2-bit/4 colors, 4-bit/16 colors (more on that later).
Finally, this technique give really fast results, but after some times, you will see some "ghosting", some pixel from previous images are lighter or darker than they should, so a complete refresh is needed (see the "Page refresh" config in your kindle : you can set how regulary your should apply this full refresh).
Petteri Aimonen's essential scrap waveform reverse engineering: http://essentialscrap.com/eink/waveforms.html
Petteri Aimonen's eink driver implementation : https://github.com/PetteriAimonen/ED060SC4_driver
My utils to extract waveform from binary : https://github.com/julbouln/ice40_eink_controller/tree/master/utils
Example 2-bit waveform for ED060SC7 : https://github.com/julbouln/ice40_eink_controller/blob/master/controller/waveform_gc4.hex
04/15/2017 at 17:14 •
Test with a homemade WIP epub reader, using ifusb interface ~ 1 fps
04/21/2017 at 06:11 •
In the Kindle 3 screen, the waveform is actually integrated into an SPI flash in the ribbon cable. In others e-reader, this can generaly be found in the firmware. E-Ink (PVI) created his own format, supported by custom controller, and some dedicated Epson chip. I think these controllers are obsoleted since CPU manufacturers does integrate the controller directly. Actually the main (only?) manufacturer which provide CPU supporting eink screen is Freescale (imx6 solo) and they created their format as well.
I did not integrate the SPI signal out of the ribbon, but somebody already dumped the data, so I used that for working on an "extractor" to convert this data for the FPGA. As the whole technology, there is very few information about this PVI format. You can find some information in linux kernel (about the header of the binary), the rest is mostly guess : I'm not completely sure of the dumper yet, but the data extrated does give some correct results.
- Epson EPDC chips: http://vdc.epson.com/index.php?option=com_docman&task=cat_view&gid=149&Itemid=
- SPI flash dump : http://www.electricstuff.co.uk/kindlehack.html
- PVI extractor from binary : https://github.com/julbouln/ice40_eink_controller/tree/master/utils/wbf_dump
- Freescale extractor from binary : https://github.com/julbouln/ice40_eink_controller/tree/master/utils/mxc_waveform_dump