Driving controller-less graphical LCD

Digging around through some old parts recently, I came across an old Epson graphical LCD display that had on-board drivers, but no controller. The LCD is an Epson EG2401, reflective, no backlight, 256×64 pixels. It has drivers…one SED1190 driving the rows and four SED1180s driving the columns…but no on-board controller. The LCD is *supposed* to be hooked up to a SED1330 controller and SRAM, but since I didn’t have such a thing, this LCD sat around in a junk box for years.

I still don’t have a SED1330 controller to hook up to the LCD, but I found more information this time around, including datasheets on the drivers. These things are essentially just serial load/parallel output shift registers, with output electronics for driving the LCD. Row select is performed by shifting a 1 in and clocking it along to each row in turn, the SED1190 can handle up to 64 rows. 4 adjacent columns are written at a time: each SED1180 has 4 16-bit shift registers with their outputs interleaved. Simple in theory, but the process of clocking data in is more complicated than you’d expect to be necessary, and rather poorly documented. There doesn’t seem to be anyone else foolish enough to try to hook these LCDs up without a controller, but after some trial and error I did finally succeed:

Caveats: you’ll need a fairly fast microcontroller. The display needs to be continually refreshed, or the image will fade to nothing, and if the frame clock is not kept changing while power is applied to the LCD, the LCD screen itself may be damaged. This will consume a notable amount of processor cycles, and if the display isn’t updated fast enough, there’s visible flicker. If the line refresh rate is not constant across the display, there will be visible glitches and artifacts, essentially varying contrast from differences in the periods the LCD is driven. If the display refresh rate is too slow, the display lifetime may also be reduced. You’ll also need lots of SRAM, bitmaps read from program memory, or graphics simple enough to rasterize on the fly (sprites/bitmap characters should be possible). Representing a 256x64x1 bit bitmap takes 2048 bytes, and the ATmega16 I used only has 1024 bytes of SRAM, so I wasn’t able to simply display from a frame buffer. It’s really a job far better suited to a FPGA, or at least a faster microcontroller with more memory (like a ATmega644 or an ARM).

On the other hand, you have relatively direct control over the LCD, and can do things unsupported by the controllers. By rapidly switching pixel states, the EG2401 can be made to display gray levels surprisingly well, though large areas of gray tend to flicker visibly, and the plot display with one half-gray trace flickered badly at 16 MHz. Overclocking the AVR helped a great deal, and with it running at 26 MHz(!), the dual sine wave plot was nice and smooth. Many of the ATmega16’s peripherals are probably non-functional at this speed, but all I need to drive the LCD was GPIO.

Source code will come in a later post, I hope to optimize it further and develop it into something of actual use.


  1. Cam MacDonald says:

    Hi, Yes, there is someone else foolish enough to try to hook these up without a controller. Did you ever get around to optimizing the code for this? I have a different Epson display (EW50107FLYU 320 x 240) that does not have a controller (seems to be something they do regularly) that I would like to mess with. I am thinking that I will attach an LCD controller, just for ease of use, but if I can do it with something that I have all the better. Thanks.

Leave a Reply

Your email address will not be published. Required fields are marked *