Discovering E-Paper and connecting it to the network [english version]

E-Paper is a cutting edge technology. Short story of how it entered at Erasme and how I connected it to the LAN.

Warning

This project (schematic, programs, this doc) is released under GPL license (version 3 and following) is provided as is, without any guarantee. Nothing has been damaged during its creation but you should be careful and check everything for yourself before using it. We are not responsible of what could happen...

Now that the legal warning is done, here we go !

After my last article, summer 2007, about the sensors (Centrale interactive de capteurs) I’m back in july 2008 with a new project for Erasme center. This time I was given the chance to work on a epaper-type screen sold by the Nemoptic company.

This cutting-edge technology is very interesting, the main advantage is that the display is a "flip flop" type, ie it will not clear even if disconnected from power source. This allow some embedded usages (take away your screen with you like a sheet of paper) but more interesting : it could be used in a battery powered project because it doesn’t need too much energy.

This product is called Binem and the chosen one is in HVGA format size (480x320 pixels, white and black). This is a development kit with a prototyping board based on an ARM microcontroller. Pictures are saved during the compilation procedure. We can save 85 HVGA format pictures inside Binem own memory.

In a few words, my job was to replace this board by another with only the needed features : to be able to send a picture to the screen without any complicated procedure like compiling... This card is called in the following text : "carrier board". At first we thought about USB to connect the board with the computer, the schematic was made for this and I wrote the program on the AVR and the one for the computer. It was working great.

Here’s what the board look like :
Carrier board
A higher resolution version is available in the archive. Same for the corresponding schematic.

So we decided to take it to another step : ethernet. We bought the TuxGraphic’s AVRWebServer (called "server" in the following text) which is helpful to connect our card on the ethernet network. The software written by Guido Socher is open : I modified it (deleting TCP support not needed and adding serial-UART support) and then the server was able to receive commands over udp and transmit them back to the board over serial (serial was initially used for debugging).

How to transfer a picture from PC to screen

To send a new picture to the screen, we need to choose a picture number (between 1 and 85 included) in order to calculate the memory page number (1 picture = 3 memory pages, you do the math...). First we ask the server if it is already busy with another client or not (transferring a picture for example). If it isn’t busy we tell to him that we want to save a new picture at page number N. Then we send each block of picture. And to finish, we send a code meaning that the transfer is finished.

All commands are sent back to the "carrier board" over serial. That card receive the commands and translate it into something spoken by the screen.

Information flow
PC	<->	*server*	->	*carrier board*	->	Binem screen
compute pictures		network abstraction layer		hardware abstraction layer		save pictures
save them		convert UDP to serial				display them
send over UDP		state (busy/ready) manager
user interface

Protocol used to speak over UDP

A very simple protocol has been created. The data payload is :
[Command Code (1 byte)][Parameter, depends on the command]

General facts : we must have at least 2 bytes of data payload, so when we use a command code which doesn’t need any additional data : we add at least 1 byte of garbage which will be ignored...

UDP payload has a limited size, so we must cut the picture into chunks. For example, a HVGA picture is 19’200 bytes worth of data, cut into 80 chunks of 240 bytes because 240 is less than 255 which is the allowed max (without counting 1 byte of command code).

Command code = 1 : tells to the screen that we are about to send a new picture (Parameter : binem’s memory page where the picture’s start will be saved)

Command code = 2 : sends a new chunk (Parameter : chunk number (1 byte) followed by chunk data)
if the server has well received the chunk it sends back a Command Code 6 with "y" parameter

Command code = 3 : tells to the screen that the picture has been fully transferred (no Parameter)

Command code = 4 : show one picture (Parameter : binem’s memory page where the picture’s start is saved)

Command code = 5 : clear screen (no Parameter)

Command code = 6 : ask server if he is ready or not (no Parameter)
server sends back a Command Code = 6 with the parameter "y" if ready, or "n".

Protocol over serial

When we made the carrier board, we wired the three serial communication pins of the AtMega (Tx, Rx, Gnd) to use them for debugging purpose. I didn’t use them, but when we decided to add the server : it was easy to use this to connect the microcontrollers.

It is a classical serial connection, 38400 bauds speed (server has not a very reliable clock source, higher speeds are not usable).

All commands sent to the server are forwarded to the carrier board this way, without any change. Except that the garbage data is deleted, and the command code = 6 isn’t forwarded (useless).

Protocol to speak with the screen

We use a 30 pin ZIF connector. The protocol is explained in Nemoptic’s doc. There are a few control lines, and many data lines. For a more detailed review, refer to the BVGP official doc.

You could understand some of this, just by examining the carrier board’s program and the schematic.

Picture format

HVGA screen, white & black : white & black picture, 1bit/pixel. 480x320 pixels. BMP format. If all of these is respected, file size should be 19’262 octets (BMP headers included).