One of my recent hobbies has been pulling LCDs out of old devices and trying to get them to work. So far, I’ve gotten two B&W LCDs from old cell phones working.
I happen to like black and white LCDs. They’re a good compromise between being sunlight-readable, low-power, and updating fast. They consume mere milliwatts but unlike e-ink displays, can still display smooth graphics.
Most panels have a chip-on-glass (COG) integrated circuit of some kind. As the name suggests, it’s a silicon microchip epoxied directly on the same glass substrate as the LCD matrix. The chip acts as the interface between digital logic and the physical pixels on the LCD. The pixels themselves are analog things that require special driving signals with odd voltages and need to be refreshed several times a second or else the image fades; the driver chip takes care of all that. Depending on the application, the COG may have on-chip graphics memory (GRAM), so a microcontroller need not continuously resend image data.
Most B&W LCDs use an older pixel technology call super-twisted nematic that results in somewhat blurry motion. Essentially, it takes a non-zero amount of time for a pixel to change state, and for STN, that time is typically tens of milliseconds. The upshot of this, however, is that if you rapidly change a pixel between black and white, it never has time to finish switching to fully-dark or fully-light. Instead, it just oscillates at an in-between gray level. Based on some code by Wenting Zhang, I’ve managed to get grayscale working on my B&W LCDs.
The first LCD I got working was this 96×65 LCD from a Nokia 6340I. It’s the highest-resolution B&W panel I have. It appears to have a refresh rate of around 80 Hz, which is good for grayscale. Unfortunately, it also does not appear to have dual-ported GRAM, meaning that if you try to write to a pixel at the same time the driver is reading it during its refresh cycle, the read will be corrupted. This shows up on this display as a streak of black pixels.
The line moves over time because it depends on the precise microsecond-level timing between when LCD COG updates the pixels and when the microcontroller sends new pixels. Sometimes it goes off-screen entirely, and when the line isn't visible, the grayscale does look good. Unfortunately, there is no Vsync signal available to help synchronize writes to when the line would be off-screen.
On the other hand, this 96×32 module from a flip-phone does appear to have dual-ported GRAM. Not only that, but the driver appears to be a 96×64 matrix driver, meaning it has twice as much GRAM as it actually needs. Most drivers have a “scrolling” feature that lets you change which line of GRAM appears at the top of the screen. This means that whether or not it’s dual ported, you can send pixel data to the non-visible GRAM, and then instantaneously switch to the new frame.
The grayscale code tries to reduce how distracting the flicker is by applying a noise pattern, so that, instead of all pixels of a given gray level flipping at the same time, they flip at different times. This changes the flicker into more of a shimmer effect. Unfortunately, this LCD has both more responsive pixels and a slower refresh rate of about 40 Hz (which I can’t change), and I don’t think any algorithm can overcome those limitations.
welcome to my blog!!!! I am paul from China!!! Haha
Hi All, I am paul from china who is the boss of P&D Electronics which wholesale cell phone parts and mobile phone accessories all over the world with wholesale price. This is my new blog.Please focus on me !!!!! haha My website:http://www.phoneparts-accessories.com
