epaper with pyboard

[nordam]

I'm interested in using an epaper display from Embedded Artists (the 2.7" variant) with a pyboard. I have found epyper, a library to use it with the Raspberry Pi, but due to limited experience with GPIO and the like I don't find it immediately obvious how to translate the code to use the pyboard instead. I see that it is probably just a matter of changing the code which sets the pin addresses, as well as translating the calls to the SPI and I2C libraries, but I thought I'd save myself the trouble if possible, and ask if someone is aware of existing code (and instructions) to use this display with the pyboard.

[pythoncoder]

I've been experimenting with this, with somewhat mixed results. I based my work on the code from https://github.com/embeddedartists/grat ... r/Sketches. I first tried it on an Arduino Mega 2560 and achieved results similar to the demo https://www.youtube.com/watch?v=qPaNMrFXsqM#t=128 but with slower updates: about eight seconds to redraw the screen. I then translated the code to Python and can write text and limited graphics to the display. The good points:

• * The display is very clear with wide viewing angle and excellent visibility in bright light.
  * It maintains its contents with the power down.

But here is the bad news:

• * It's very slow to update. Slower than Arduino. 18.7 seconds to redraw the screen.
  * I'm seeing a lack of horizontal precision in the display. If you draw a vertical bar two pixels wide, its width on the screen varies from one to two pixels dependent on its horizontal position. This makes small fonts look messy.

I've tried to improve performance: the code spends 98.5% of its time in one method so it's clear where to target the effort. But I've dealt with the low hanging fruit including using the native code emitter and further optimisation could be tricky.

The lack of horizontal precision is puzzling: either the demo images are carefully crafted to hide this or there is a bug in my code. If the latter it's proving elusive: I've studied the bitmap going to the screen in binary and I can't see a problem. As an example see this image http://www.hinch.me.uk/epaper - the vertical lines at the bottom of the display should all be two pixels wide. It's a puzzling effect: if you consider the column to the right of one of the narrow vertical lines, its pixels can be darkened but only if the pixel to its right is also made black (as evidenced by the vertical bar immediately below it). This might point to a subtle problem in the driver itself, but if I present it with one of Embedded Artists' demo images it's rendered perfectly. Right now I'm stumped.

As a general point these displays are pigs to drive. They require much bit bashing on GPIO lines. Above all they need a ludicrous number of SPI commands simply to draw a bitmap to the screen which is the fundamental reason for the slow update. Presumably devices like the Kindle use better display modules.

I'd be interested to hear any comments, especially from anyone with experience of these displays. My guess is that unless I can solve the pixel problem and improve performance it's not worth the effort of tidying up and posting code.

EDIT:

I've found and fixed the pixel problem which was a bug in the driver. New image: http://hinch.me.uk/epaper1