So, I got myself a Palm Pilot at our local Goodwill Computer store for $5 a few months ago, and I love it! It makes my life so much easier, without the need to go out and buy an iPhone or some other new expensive gadget that can do the same things. So when a buddy of mine offered me a free tub of PDA’s he got a while back at the same store and had no use for, I gladly accepted. So now I’ve got a tub full of old monochrome palm pilots that are slightly underwhelming in comparison to my shiny color m505 (still old, but less so, and it doesn’t show it). With an Arduino hopefully coming for Christmas (thinking Seeeduino Mega, any thoughts? It’s down to $42, can’t refuse!), I thought I’d start working on some projects that are generally not possible with my VEX microcontroller.
After spending a few hours on SparkFun over the past week, I kept seeing all of these LCD touchscreens for $150 doing fantastic things on the Arduino, and I thought, you know, I think I can best that. Of course, I probably can’t, but I thought I’d try. I’ve searched the entire internet for pinouts of the Palm Pilot 20-pin LCD connector, and I’ve found none. It’s quite possibly one of the most common screen connectors around, but it’s ONLY used in the Palm, and therefore they kept the protocol quiet. So I thought one of the biggest collections of technology nerds and geeks (pick your title) on the internet might be able to help me out.
Here’s the pinout I’ve been able to determine so far, between hopefully clever use of my multimeter and an o-scope (Xoscope with a headphone cable plugged into the microphone port for probes, it’s really cool!):
1 - backlight power (+3.6v)
2 - general Vss (+3.6v)
3 - ground
4 - low-speed clock signal (6ms duty cycle)
5 - low-voltage high-speed clock (75us duty cycle)
6 - higher-voltage high-speed clock (75us duty cycle)
7 - Vcc (+3.3v) - linked to power supply smoothing capacitor by 140 Ohms
8 - Vcc (+3.3v) - linked to power supply smoothing capacitor by 70 Ohms
9 - ground
10 - LCD power - +17.5v for low contrast, up to +19.8v for high-contrast
11 - data
12 - data
13 - data
14 - data
15 - ground
16 - ground
17 - digitizer pin 4 (X right)
18 - digitizer pin 3 (Y upper)
19 - digitizer pin 2 (X left)
20 - digitizer pin 1 (Y lower)
I’m fairly confident on 3, 4, 6, and 9-20 as being correct, it’s the purpose of the redundant power lines and the low-voltage clock signal that I’m not sure of. The last 4 pins are for the digitizer, the resisitive touchpad above the screen. Basically, you apply a voltage across the screen, and when a stylus presses down on a point, it connects a top and bottom conductive layer, which is linearly resistive, and will give you a single-axis position. You then repeat very quickly with the other axis. I also know that the communication protocol is synchronous, and uses a 75us-period triangle wave to keep real-time. There’s a longer pulse train with a 6ms duty cycle that tells when it’s time to write the new line. Somewhere in there (I have no idea where), there’s a longer pause to tell the screen to go back up to the top. From what I’ve read, there might also be an intermediate pause used for multiplexing, so the screen only works on either the top or bottom half at a time so fewer pins are used.
But I don’t know how the 4-pin data lines work. It’s a 160x160 screen, and completely monochrome (black and white, no gradients). My only guess from what little documentation I have been able to find on a few of the controller chips and similar screen protocols is that it writes 4 pixels at a time, horizontally, then moves onto the next 4, 40 times per line, then it repeats on the next line. With a new-line clock signal at every 6ms, that means every tetrapixel is being written in 150us. Because of the 75us triangle wave, it could “simply” write a pixel on or off at every critical point on the wave. This may well be a little fast for the ATMega series processors, but I’d at least like to decode the communication protocol so I know. Any thoughts?
Edit: Upon reviewing the signals off the O-scope, it turns out I was wrong about the period of the line-refresh clock signal, it’s actually 12ms, not 6. This means that the screen would only have to update a bit at each PEAK of the high-speed clock signal, instead of both the peaks and the troughs. I think I had the screen scaled wrong the first time. The measurement of a 75us high-speed clock was correct.
