Palm Pilot LCD screen pinout in progress

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.

If it helps, while displaying the first attached image, the waveforms on pins 11-14 are respectively shown in the next 4 attached images. No matter what the image displayed on the screen, each waveform remains constant while the image is still up.

I really have no idea what I’m looking at, so if you recognize any of this, it would be a great help. Of course, the waveform patterns change when the screen changes.

Palm Pilot LCD.JPG

Palm Pilot LCD.JPG

Thank you to Evgeny who contacted me with a link to someone who has done this before! Here is the wiring diagram:

And here is a programming example:

(Also, again, this is not my code, but it is on Olimex, and is therefore public domain). Happy hacking!

I have a similar Palm Pilot type PDA screen - the circuit board is silkscreened with a Picvue PC1721WE legend. Purchased from

This also has a 20 pin connector, but appears to be different from the Picvue PC0919WE07 described in the Olimex page.

PC1721WE seems to have a built in EL driver with a H826 driver IC (compared to the H830 in the Olimex schematic which looks like it is external to the LCD module). PC1721WE also seems to have a built in contrast voltage supply circuit.

Playing with a multimeter, I am reasonably certain that pins 20…17 are data bus, 13 & 7 are GND, 4…1 are the touchscreen interface pins.

Pins 14,11,8 and 5 are also connected to the lcd glass traces - i assume they are control pins - clock, enable etc.

There is also a pad on the board that seems to be a testpad for the contrast voltage.

Just by supplying power 3.3V to the H830 EL driver VDD pin, and 3.3V to pin 11 and pin 14, I can see the display flash, and then a contrasty line on top, and the testpad voltage is 21.5V. When I set pin 11 to GND, the screen flashes, and then blanks, the test pad voltage is 15V. From this i assume there is no need for me to supply an external 18V VHH drive as per the PC0919WE interface in the Olimex schematic.

Any pointers to similar LCD interfaces / pinouts / datasheets would be much appreciated !! I got two of these for $5 each, would be great if I can get them up and running.

OK, after some experimentation I am reasonably sure of the following on my palm pda type lcd (Picvue PC1721WE).
I’m not sure if it is for a genuine Palm PDA as the icons on the 4 corners of the “graffiti” interface pad are different from the original Palm PDA panel.

  1. Its a 4bit monochrome panel
  2. Has onboard EL driver using HV826 driver chip
  3. Has onboard contrast voltage generation circuit


20 D3
19 D2
18 D1
17 D0
15 CONTRAST (pwm ? 0 =>15V, 3.3V => 21.5V)
13 GND
3 touchscreen
2 touchscreen
1 touchscreen
0 touchscreen

I’m not sure of the VCC pin on this pinout because it doesn’t seem to be directly connected to other chips on the
board or to the display lines. So I am powering
the panel by connecting 3.3V to the HV826 driver VCC pin.

I’m pretty sure of the DISP_EN, HSYNC, DCLK and D0 … D3 lines, because I can bring up the screen for one frame with contrasty lines, placed where I would expect them e.g. Writing 0x8 every data clock to D3…D0 makes the 1st,5th,9th pixels on a line black. Writing 0x1 makes the 4th,8th,12th pixels black…

For these experiments I have been using Daltore’s experimental data, driving the pixels with an approximate pixel clock period of 75uS.

However, the screen fades immediately after the first frame draw. So I have not yet been able to determine the VSYNC (FLM) pin (and perhaps a BIAS signal, though I don’t see it on the PC0919WE07 schematic) and timing.

Again, any pointers to useful info would be appreciated - i am close, but not yet there !! Am wary of doing damage as I only have a couple of these screens and could really make use of them.

Hey, I’m glad to see you’re getting results! I have had absolutely no time to work on this, and I’ve gotten side tracked into different projects when I do have time, but I do intend to eventually work on this, if for nothing else than hacker points. Keep us updated on any progress you make, and good work!

I was wondering how you are figuring out what all the pins do? What equipment are you using and what are you doing with it? And furthermore, how would I go about testing the function of electronic components (especially LCD displays) in the future?

Thanks :slight_smile:

Well, a multimeter to check continuity told me which pins were ground. Since there was an EL backlight driver chip with identifiable part markings, the datasheet told me which pin was VDD and which pin was the backlight enable.

The digitizer pins were easily traceable to the touchscreen.

There were 4 pins going to adjacent 4 traces close to the lcd glass, so guessed (correctly) they were the databus.

There was some circuitry and a test pin on the PCB that showed a high voltage (> 15V) so I figured the LCD contrast voltage was being generated onboard. One of the interface pins affected the voltage - setting it to 0 made the voltage 15V and setting it to 3.3V made it around 19V. So I guessed it was PWM control for the contrast.

Then, used a PIC32MX breakout board and soldered gpio pins and started experimenting, using the olimex code as a starting template.

The display enable pin was easy enough to find, not even an lcd flash happening until a particular pin was logic high.

Setting individual bits on the data bus told me the high-low order.

That left the timing signals and some possibly unknown control voltages.

Experimenting, I got as far as a very dim and flickering screen with my text in the right place. Pretty much unusable - something incorrect with the timing signals and/or driving voltages and I shelved the project last year.

And I am not sure if I damaged the lcd during the process or if the lcd was defective to start with. The EL backlight driver doesn’t seem to be generating the minimum 80V ac required voltage, i can only see about 40V at the output - this is on both the units I bought.

Here is the pinout for the PC1721WE type lcd, similar to a Palm Pilot pda,
160x160 resolution, monochrome, EL backlight, resistive touchscreen.


20 D3
19 D2
18 D1
17 D0
15 VO_EN
13 GND
12 3.3V
08 CLK
07 GND
04 touchscreen
03 touchscreen
02 touchscreen
01 touchscreen

All signals are 3.3V level.

The BIAS logic level needs to be inverted every frame. The VO_EN signal needs to be 3.3V for a legible screen. Tried PWM control of VO_EN but no luck, it wants a DC signal. I have not yet tried a separate supply for VO_EN with a higher voltage.

This LCD uses an onboard LCD drive voltage (15V - 19V generation system centered around an LM324 opamp,
and an EL backlight drive circuit using an H826 IC. The backlight drive does not appear to be functional, which may explain why this LCD display was available for $5.

I was able to use both the Olimex template code and the code here

as starting templates to get a working display. The Cafelogic code indicated the possibility of a frame inversion bias signal being required for my lcd, unlike the olimex lcd, and that turned out to be true.

Coincidentally enough, like the CafeLogic project, I was also using a PIC32MX mcu to drive the signals. So it was pretty easy to port his code to my MCU derivative and LCD.

I checked out the CafeLogic code generated signals with a usb logic analyzer. Interesting - an interrupt service routine is called periodically for each line, the previous line data is latched in with the line pulse, and then the following line data is written as fast as the C code can run. Thats how he gets the 93% idle time with an 80Mhz cpu clock, and the display seems to be OK with accepting this timing.

Not completely usable yet - still some flickering and streaking on the image. The attached snapshot is with the Cafelogic derived code which prints out the % free cpu cycles, i.e. cycles not used by the lcd driver code on the PIC32MX.

This is happening with my olimex derived code as well, possibly there is a sweet spot in the timing, also my ratsnest wiring to the tiny lcd connector is likely not helping with the high speed clock signals.

Its also possible i damaged the lcd in the course of my experiments. Still, at least I am sure of the pin functions above, have not tried the touchscreen yet.