It's really quite a nice little piece of gear: 240x64 pixel resolution. It's about 6" wide. Nice and visible, even in direct sunlight. And only cost about $15 for the part.
It was originally going to become a digital dashboard for my race car, but I've since given up on designing and building my own digital dash-board.
The interface to the display is a 30-pin flat-flex connector. It's probably the tiniest multi-pin connector that I've ever contemplated working with. The pins are 0.1mm wide, and the pitch is only 0.2mm. It's so tiny I can't directly photograph the pins with my smart phone.
The challenge: to make a break-out board so that we could interface this display to the 3.3v our micro-controller of choice. In my case, this will eventually be a Teensy 3.1.
I recently found myself with some time on my hands, and so I went down to visit my friend, Mike, who can basically do anything. But even he agreed that making a break-out for this connector would be a challenge. For something this tiny, a PCB would have to be etched. And we were concerned that this pitch might be too small for DIY etching techniques, especially the photo-resist method. Mike had some scrap copper-clad lying around, so we decided to try the laser-paint method.
We did some trial runs on the laser cutter with some regular white printer paper. It took a few tries to get the settings right on the drawing with auto-cad. There's a little confusion about white being black, and black being white. If you're not careful, the printer tries to use a stipple pattern when you want a solid color. Anyways, we did two boards, at two different intensities. They both "came out", but the one at the default power level came out the best in terms of having thicker traces. We realized right away that we had made the long traces too thin, and because of the limited raster resolution on the laser cutter, the fine curve of the traces was interrupted in places.
We decided to etch both boards anyways, without attempting to touch up the traces before-hand. This is as much about pushing the limits of the technique as it was about getting the job done.
What you can see is that the pad area for the flat-flex connector etched cleanly on both boards. The traces, on the other hand ,were a little thin and broken in places as we expected. But it at least looks workable.
We then proceeded to develop a CNC program to route our copper-clad boards into panels, and to drill out the through-hole pins for the in-line headers we planned to add next. This was done with bob-cad, and the resulting program was routed on a proper CNC mill. It's nice when you have the proper tooling at your disposal.
The challenge of soldering was divided between us, but I let Mike takle the delicate job of hand-soldering the surface-mount flat-flex. Once he got it lined up, he was able to drag-solder the pins and got it right on the first try.
I did the power connector (my first time ever trying to do a surface-mount job). It turned out to be easier than I had expected. A little more difficult was top-side soldering the the in-line headers onto the PCB. In hindsight, it would probably have been better to flip it over, but you live and learn.Now I could finally prototype an interface. There were two challenges here: the first is that, while the documentation was comprehensive, it did take some time to comprehend. The controller, a U1608, is quite capable. It contains an internal charge pump, which is capable of driving the LCD segments, but you do need to add some external capacitors. This we did, but powering the display on resulted in a whole lot of nothing.
Based on reading the documentation, it seems that the charge pump isn't activated until you send the "ENABLE" command to the controller
The controller can operate in 3-wire SPI, 4-wire SPI, 4-bit parallel, or 8-bit parallel. And these latter two can be done in either an "8080" style bus or a "6800" style bus. The distinction was not entirely clear to me, but in the end I finally figured it out and decided to go with 6800 8-bit parallel to start off with. The 8-bit mode is easier to get going, if you have enough pins for it. I will probably drop it down to 4-bit to save pins in the future. But you want to stick with parallel so that you can read back from display memory, rather than having to buffer all 240x64 pixels.
After a bit of fiddling, I was able to get the display to respond to the ENABLE command. I was worried that perhaps the display would appear too faint with the default contrast settings. But it turned out we had the opposite problem, and the display wasn't quite legible until I was able to turn the contrast down in software. The data sheet has detailed info on how to tune the contrast circuitry, but I decided to forego this for the time being. Probably I should have measured voltage bias, but at this point, I was just happy to have something working.
The next task was to figure how how to write arbitrary pixels to the display. This is done by writing directly to the display's internal memory through the bus. The display contains two registers Page Address, and Column address, which determine which byte in display memory will be written too, but this will auto-increment by default. So if you just write bytes in sequence, you'll eventually write to the whole display. But there were some gotchas.
The biggest one is that while the Column Addresses map directly to each of the 240 horizontal pixels, the Page Address space starts off screen. It turns out that Page Address 4 is the first visible page address. One thing to understand about monochrome displays is that while they are byte-addressable, each byte is used to represent 8 pixels.
In any case, once I had worked out the starting addresses, I decided to write a program to cover the screen in that 1-bit gray pattern which is beloved of the Nintendo Game Boy and the original Macintosh.
The next task would be to write an Adafruit-GFX driver for the chip -- assuming it needs it. It's possible that the KS1608 display they sell is actually compatible with this display at the software-level, in which case it would save me a lot of trouble. I'll have to go over the command set to be sure. If not, it would not be hard to port this display to the Adafruit-GFX library.