PaPiRus display

A utility for RISC OS to control an electronic ink display (a PaPiRus Zero) may be downloaded from my web site . The display is connected via the 40 pin header and uses the SPI interface and many of the GPIO pins. The driver takes a 200×96 1bpp sprite as its input and now appears to work although there is some slight ghosting on every fourth line (likely to be a feature of my driver, as driven from Linux it is pin sharp). It is written in BASIC and requires the PiSPI module version 0.04 and the GPIO module version 1.00. I don’t know what speed the SPI bus is running at as the documentation with the PiSPI module does not say what the value of the clock divider should be for a particular speed. The PaPiRus display will run at SPI transfers up to 20MHz.

The display uses GPIO pins 4, 14 and 15 (as well as 16, 17, 18, 19, 20, 21, 23, 24, 25, 26 and the SPI pins 7-11) and so the utility restores 14 (TXDATA), 15 (RXDATA) to UART status and restores 4 (Witty Pi power off) to output high on exiting and sets GPIO 22 low (to disable an attached GPS module which otherwise uses RXDATA and TXDATA) while running. The PaPiRus Zero version does not include a RTC and temperature sensor so does not use the IIC pins 2 and 3.

Electronic ink displays have the advantage of retaining their display even with no power applied, at least for a few days. They take a few seconds to update and a frame rate of perhaps 0.2Hz is not suitable for some purposes!

If you find improvements to the software, please let me know.

Very interesting!

and so the utility restores 14 (TXDATA), 15 (RXDATA) to UART status

Does this mean we can use it as a serial slave and pass data from another machine via RS232?

An idea would be to have a case for the PaPiRus. You connect it to the Pi to get the list of your meetings for the day. Then you disconnect it and keep it in your pocket.

The PaPiRus display has the TXDATA and RXDATA lines (amongst many other GPIO pins) connected to control various hardware bits and uses them as GPIO pins so you can’t use them for serial while you are updating the display.

This is interesting, but is there a cheaper option? I can buy a new 800×600 eink panel for my ereader for about €28…?

I’m not sure the price reduces much as the display gets smaller – the 200×96 display is £26 (the 264×176 display is £35, but again this includes the driver board plus real time clock, temperature sensor and EEPROM) and most of the cost is probably the driver board rather than the display itself (they are separate items, just sold together). Just the eink panel on its own (which is a tiny piece of work with a ribbon connector) is probably a lot cheaper.

Conversely, does the price not increase much as the display gets bigger? How about a 4K eink panel? Or even bigger than that?

I suspect that the Kindle-sized display is the one where large production runs have kept the cost down. I can’t see what a 4k e-ink display would be used for – it would have a refresh rate measured in mHz (that is milli Hertz).

Ah, okay. I don’t know enough about eink – in particular, obviously, how the refresh mechanism works. Presumably if it’s that slow it’s because you can only do a single pixel at a time?

Seems it depends on what kind of module you’re using. With a TFT backplane you could drive the whole display as fast as a single pixel could update – about 120ms (8.3Hz). See http://www.eink.com/faq_matrix.html – and they don’t seem to give a maximum size, but do say “Displays can be very small or very large.”

They also do colour, which makes it quite interesting.

Presumably if it’s that slow it’s because you can only do a single pixel at a time?

The update process for this particular display involves sending an inverse image a few lines at a time, overlapping so that the screen gets perhaps three ‘coats’ (equal in time to three screenfuls of data) then a second stage where the whole screen is painted black then white, repeated if necessary depending on temperature (another two screenfuls of data) then the true image is sent a few lines at a time, overlapping so that the screen gets perhaps three ‘coats’ (equal in time to three screenfuls of data). That is eight screenfulls of data which the data sheet suggests that it will typically take a few seconds, about 4.5s for the 264×176 display.

Sending a single line of data involves sending odd pixels (25 bytes) as 2bpp with the MS bit indicating whether ‘no change’ or ‘set white/black’, then a 2-bit nibble for each line present on the display with only the relevant nibble set to %11, followed by even pixels.

Blimey. What a palaver! I wonder what others are like? There’s a paucity of detail on the company’s website 8~( – I suppose there are loads of possibilities, and not many particular options (yet?) implemented.

I suspect that the crowd sourced driver board for the PaPiRus is fairly basic leaving the difficult bit for the software…

Yup, that sounds like the size of it. Obviously having a backplane with an active circuit (with memory) for each pixel would up the cost of the display a great deal, which would be how you’d get a display that could update the whole image in the time taken for each pixel. Looking at the Wikipedia page, it looks as though some of the units actually available or in the pipeline can do a whole row like that, but have to do columns sequentially (or vice versa), with only as many active circuits as the number of rows (or possibly columns). That would still leave a 4K display pretty slow…

But then, my 4K display has active circuitry for every pixel. A lot more than £26, but not our of this world (£299).

It’s the fact that the eink display is reflective rather than light emitting that I like especially – and of course the much lower power consumption. Active circuitry for every pixel, but only active when the pixel is changing colour.

Between you and me, I like to think of eink displays as an electronic etch-a-sketch. It’s closer to the truth than traditional video methods.
Namely, a “pixel” is a clever chemical suspension and when it is “updated”, it is placed into a state of being a black dot, or a state of being a reflective dot.
I don’t know how the RISC OS code works, but from observing my ereader, it seems that it is quicker to update only that which has changed, but the side effect of doing that is that there is a sort of ghosting effect visible. In order to clear that up, the display must be fully refreshed (set entirely to black, then to the desired content). The side effect of this is a black flash. My ereader let’s me choose how many pages to display before doing this, as it is a trade off between power requirement and crap-on-the-screen.

As it isn’t anything like a traditional display, a 4K screen would be pointless. My ereader has a mouse cursor that can appear when using the built-in browser and it is a horrible mess of ghost trails. Don’t even talk about the time I hit it with an animated GIF…

One of the interesting things for eink is that it only consumes power when updating, so one can leave all sorts of content on a “dormant” display. My ereader has a cute little “off” logo. I believe some versions of the Kindle advertise at you…

I believe that colour eink is currently fairly poor. The typical arrangement is red and black, and it is not as good a contrast because, like the display on the old Psion organiser, the red plane and black plane are not the same, they’re stacked one on top of the other.

Best to think of eink as a display for content that is expected to be mostly static. Nothing animated, nothing “live” (as in videos or moving things). While it can be done, it is akin to buttering bread with a gun. Possible, but not even slightly recommended… ;-)

For us geeks – there’s some interesting mileage in having some code hooked to abort/crash vectors to dump system state to the eink panel. The system may entirely trash itself, but all the juicy information will be right there, even after power-down. ;-)

I like to think of eink displays as an electronic etch-a-sketch.

That’s clearly how it’s mostly being implemented at the moment, but having had a look at the technology, it’s pretty clear it doesn’t have to be like that – it’s just that with individual pixels not requiring power to maintain state, etch-a-sketch is (relatively) easy to implement. It’s also clear that some implementations are more sophisticated, albeit not exactly wonderful.

No, you wouldn’t want to display video or games, but for text or bit image editing, or vector graphic work a TFT-controlled eink display would be perfectly feasible – and the low power consumption could make it pretty attractive for a laptop. If there’s enough market for a laptop that’s not usable for video or games…

That is eight screenfulls of data which the data sheet suggests that it will typically take a few seconds, about 4.5s for the 264×176 display.

Yikes.

Is all that really necessary? From observations of my ereader, it would appear to “erase” the page by setting all the set pixels to white prior to setting the new pixels you black. I’m not sure how the screen is addressed – I say this because moving the mouse pointer only appears to update that which has changed rather than the entire screen. So it might be that the page redraw can break the screen area into zones and skip clearing whitespace, leave the static toolbars alone (if visible), that sort of thing.
Taking 4.5s for a small display refresh seems rather slow. That resolution is only about 46.5KiB of data. Four and a half seconds ought to be plenty for eight refreshes at IIC speeds, so why is an SPI device so slow?
Look at any ereader, a full refresh (screen-flashes-black) typically takes <= a second at resolutions in the order of 800×600 or more.

Just trying to get my head around the slowness and the need for so many refreshes…

Clive – an eink based text editor?
You’re Clive Sinclair and I claim my five pounds.

8~) You’re not the first to suspect that, but deny it most forcefully. I have even less business sense that he has.

I want my eink display in full colour, and with a refresh rate for the whole screen of at least 8Hz, preferably 20Hz. I want to be able to do DTP, not just text editing; I want to be able to use The GIMP (or Photoshop); some vector graphics program (!Draw for preference…); surf the Web (but I don’t care if videos don’t work).

After all, that’s all I’m using my LED monitor for. And my Mac mini can only drive it at 30Hz, and the Pi only at 24Hz, and for my purposes that’s more than fast enough.

The big attraction of the eink is the low power consumption, and the fact that it works in ambient light.

I want my eink display in full colour, and with a refresh rate for the whole screen of at least 8Hz, preferably 20Hz. I want to be able to do DTP, not just text editing; I want to be able to use The GIMP…

Add in “okay pal?” a few times, could be the beginnings of a Denis Leary style trip into insanity. ;-)

[that said, if you never watched MTV in the eighties/early nineties you might not know what I’m talking about…]

I never watched MTV at any time. What was/is it?

But I’ve heard people saying “Okay pal?” as if it was someone’s catchphrase, so they probably had. Or knew someone who had.

I should add that having looked at the eink technology, I don’t see why all that shouldn’t ultimately be possible. Whether it could also have respectable life expectancy is less obvious, nor whether the market for it would justify the development costs. My 4K LED monitor probably wouldn’t exist if it weren’t for the TV market.

There was an e-ink phone prototype knocking about a few years ago. Looked promising…especially for battery life…but I don’t think it ever made it to market.

What could a small e-ink display on a RISC OS computer be used for? Hand-held GPS?

There is a company out there at the moment selling a cloud-enabled typewriter for something like £450. People will probably buy it as well.

A YouTube video now shows the prototype running.

The prototype comprises a Raspberry Pi with a Witty Pi stacked above it (via which power is supplied), then a ProtoPal breakout board with a GPS module connected to TXDATA, RXDATA (and GPIO 22 to enable/disable it) and an OLED display connected to the IIC pins. Above that is a PaPiRus Zero display. It is running RISC OS 5.23 7-Mar-2017, !SatNav version 1.40, GPIO module version 1.00, OLED module version 0.03 and PiSPI module version 0.04.

Leary – https://www.youtube.com/watch?v=t-QTJuQhnMU

Audio is horrid, but it makes the point. Through I’m not sure what point… Something about cheese.

…

That junk on the right of the screen. Whoa, it’s been a long time since I last saw VideoCrypt.