Project Logs

Collapse

• Details about the waveform implementation

  Julien • 01/13/2019 at 12:48 • 0 comments

  Since multiple people ask me more details about the waveform format used with the FPGA, here is some information.

  
  Each line is one of the phase containing an array of the 4x4 transition possible in the form of 16x2 32bit value (0xFFFFFFFF):
  [white to white, white to light grey, white to dark grey, white to black,
  light grey to white, light grey to light grey, light grey to dark grey, light grey to black,
  dark grey to white, dark grey to light grey, dark grey to dark grey, dark grey to black,
  black to white, black to light grey, black to dark grey, black to black]

  Each entry take 2bits (0,1,2,3 3 never being used).

  For example, if you take line 5 of https://github.com/julbouln/ice40_eink_controller/blob/master/controller/waveform_gc4.hex
  0x4028a098 = 0b01000000001010001010000010011000
  [01,00,00,00,
  00,10,10,00,
  10,10,00,00,
  10,01,10,00]
  

  So to go from white to white, we will need to apply -V:
  [01,00,00,00,
  00,10,10,00,
  10,10,00,00,
  10,01,10,00]

  To go from black to white, we will need to apply +V:
  [01,00,00,00,
  00,10,10,00,
  10,10,00,00,
  10,01,10,00]
  You can see the algorithm there https://github.com/julbouln/ice40_eink_controller/blob/master/controller/waveform.v#L50
  waveform_phase[prev_pixel1 + pixel1 + 1],waveform_phase[prev_pixel1 + pixel1]
  

  If previous pixel is black and pixel is white, we would have array[3<<3+0+1:3<<3+0] = array[25:24] (https://github.com/julbouln/ice40_eink_controller/blob/master/controller/waveform.v#L42)

• Waveforms binary extract

  Julien • 04/21/2017 at 06:11 • 0 comments

  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.

  References
  

  • 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
    

• Ebook reader test video

  Julien • 04/15/2017 at 17:14 • 0 comments

  Test with a homemade WIP epub reader, using ifusb interface ~ 1 fps

• Waveforms table introduction

  Julien • 04/14/2017 at 16:14 • 1 comment

  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).
  

  Sources:

  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
  

View all 4 project logs