The plausibility of an E-Ink Display


levi

Still fresh, damnit!
Joined
Oct 6, 2008
Messages
12,290
Location
Somewhere off the coast of the EU
Yes, he does seem to be storing character entries in SRAM then mapping them into a series out output bytes via an LUT, but VGA itself is still very much an analogue interface. It takes to top line of all of the characters in the top row before moving down to the second row and so on. I don't know off the top of my head what interfaces e-paper screens take, but I suspect they're digital, but probably expect a bitmap to display. Otherwise they'd need to support something like postscript (which we used to use to make printers layout pages like we wanted, using ASCII plus control sequences), and I might be behind the times, but I still class a postscript implementation as being quite a heavyweight kind of a thing (but then I remember having to upgrade printers with whopping - count 'em - 4MB RAM sticks to make them work better).

The thing you're thinking of is serial comms to old terminals like DECs VT220 series - that's ASCII+ANSI control codes, and kind of depends on a monospaced font, which you don't want on an e-paper screen normally.
 

JustSimon

Member
Joined
Apr 10, 2017
Messages
38
Location
Germany
@Grench Sadly, those displays don't speak VT220 or anything of the sort.

I've looked at > 20 datasheets of different eInk displays and almost all of thrm have one chip that speaks SPI or I2C and one chip that controls the pixels on the screen.
So when you write to it, the first chip translates your I2C instruction into a pixel modification and the second chip then toggles that pixel. Some have one chip that does both.
There are different ranges of commands you can execute. I have seen a display that allowed you to send multiple pixels in one I2C 'command' and some basic shapes...
But there are tons of displays out there and most of them only speak SPI natively, so thats another issue.
There are I2C-to-SPI translator boards, but I' prefer not to have any extra components.

My current plan is to just attatch the screen to the I2C bus on the circuit board of the screen and then write a program that keeps the state of the screen in mind and does a little optimisation (not setting pixels to white that are already white and grouping shapes where possible)
 

klapse

Central Scrutinizer
Joined
Aug 30, 2012
Messages
1,932
Location
Germany
Otherwise they'd need to support something like postscript (which we used to use to make printers layout pages like we wanted, using ASCII plus control sequences)...
I once did some postscript programming for scientific publications, and also wrote display postscript screensavers on the NeXTstation.

Remember the melting screen from Doom? I did that before iD, on the NeXT.

[ON-TOPIC]
Surprised nobody mentioned 'Memory-TFT' from Sharp. Very competitive to e-ink iirc: Low power, cheap mfgr, faster switching, colors possible, sunlight readability.
 

spud42

Very Active Member
Joined
Aug 22, 2009
Messages
664
Age
58
Location
Brisbane,Australia.
Utilizes the extremely common HD44780 parallel interface chipset. Interface code is freely available.
common as mud those displays. i remember back in 1998/99 we in the car MP3 scene used these to display what winamp was doing. very easily driven from a paralell port. 3 years or more before ipods came about. site got bought by a company who use the name to sell their products now and have shut down the forums last year... so much history and information lost..
 
Top