Go Down

Topic: Using HP Digital Entertainment Center VFD's (Read 15486 times) previous topic - next topic

Mar 25, 2011, 09:12 pm Last Edit: Mar 28, 2011, 12:49 am by TitaniumStudios Reason: 1
Introduction

My favorite hacking at the moment is to get surplus displays working. The displays from the HP Digital Entertainment Center PCs are available from numerous vendors for quite low prices and so caught my attention. A word of caution here, I tried multiple sources and it appears all "new" offerings were obvious pulls, carefully disguised pulls or new but of seconds quality. Anyway, even used they are a nice display: large 16x2 5x7 characters plus additional icons; a removable color filter; just low enough current draw to run the display+Arduino from USB; and, a compact physical size. There are also handy project components on the front also: a couple of LEDs, an LDR and an IR phototransistor. On the down side, the connector has an awkward pitch (2 of my displays came with the original cable attached fortunately), communication is quite slow and I haven't been able to find any user-defined character functionality.





Determining Pinout

My first step was to figure out the pinout of the connector. This wasn't too difficult - there aren't many components and most of the important traces are on the side not obscured by the display glass. A key step is figuring out power requirements. I do this as follows: locate a known IC on the board (in this case, a serial EEPROM), figure out where that IC gets its VCC and VDD from (2 pins on the connector in this case), then account for all other pins to ensure there is no secondary power line such as 12v. In this case there were no other power pins so since the EEPROM is limited to 5v and it would be a bit crazy for the on board VFD power supply to operate of 3.3v, I assumed power and all logic was 5v. At this point I hooked up power and the display powered up and displayed a scrolling marque, "WELCOME TO THE HP DIGITAL ENTERTAINMENT CENTER". Supply current was also measured, ~450ma.

The connector has 12 pins: 2 for power, 4 signal lines running to the large IC with custom markings and the other 6 connect to the LED, LDR and IR circuitry.

First Attempts at Communication

There are only two ICs on this display board: a 256 byte serial EEPROM and 44 pin controller labeled with custom part numbers. It is this simple because the usual high voltage driver chips with shift registers are actually embedded in the glass display. I have driven shift registers like this in the PrimeVfd library so I considered just breaking out these pins and driving the display glass directly from the Arduino. It seemed a little too dirty though so I continued on.

I hooked up the 4 signal lines mentioned above to the Arduino and started experimenting with code and a meter. I quickly discovered that 3 of the lines had pull-up resistors and the fourth was normally low. When the 4th was pulled high the display blanked, indicating that this was a reset pin. However I was not sure if instead it was an "inhibit marque and accept data" pin so I tried my next experiments with the pin both high and low.

With 3 possible communication pins, I made a sketch to test different possible communication protocols: serial at all standard data rates (even if you are close, garbage will usually display), scanning for i2c on 6 different possible wiring combinations, sequential and random SPI clocked serial data and brute forcing all possible ways of clocking data in with those three pins. None of these tests had any visible effect on the display, as it turns out because I was sending data too fast.

Identifying the Unknown IC



I decided it was time to figure out what chip was on the board. I was fairly certain it was some kind of microcontroller since using a CPLD or custom ASIC would be massive overkill. I picked up my loupe and started documenting which pins did what, such a where the crystal attached, power, i2c, etc. While doing this I noticed that there was still very faint evidence of the original markings on the chip. I was quite lucky here, my other examples of this display have no trace of the original markings. This was too enticing not to follow so I spent about half an hour experimenting with different lighting and viewing angles until I came up with 89S52. You can sort of make it out in the above image. Google matched that with the Atmel AT89S52 microcontroller. A quick check of the datasheet and the important pins matched up.

This is a flash memory based microcontroller. I don't know why all the effort was put into custom marking the microcontroller, it is not especially difficult to create this kind of functionality and this implementation as it turns out is not all that good. I'm tempted to have the chip decapsulated and unlocked just to see what was worth trying to hide. The 4 control lines actually connect to the 4 pins needed for in circuit programming: RST, SCK, MOSI and MISO. The 89S52 can be erased even after the lock bits have been set so at this point I now had the option of creating new firmware. The new firmware could even be embedded into an Arduino library and uploaded the first time the sketch was run. This still seemed a little clunky and I wanted to see if I could figure out how to use the original firmware.

I wrote a sketch to communicate with the in circuit programming interface of the 89S52 and read back what I could. Unfortunately the lock bits had been set so extracting the program that way was not a p option. At this point I clipped directly onto the communication pins of the EEPROM chip, pulled the 89S52 reset pin high and used a simple sketch to extract the EEPROM contents to see if there were any clues:

Code: [Select]

WELCOME TO THE   32 87 69 76 67 79 77 69 32 84 79 32 84 72 69 32
                32 32 32 32 32 32 32 32 32 32 32 32 32 32 32 32
                32 32 32 32 32 32 32 32 32 32 32 32 32 32 32 32
                32 32 32 32 32 32 32 32 32 32 32 32 32 32 32 32
                32 32 32 32 32 32 32 32 32 32 32 32 32 32 32 32
HP DIGITAL ENTER 72 80 32 68 73 71 73 84 65 76 32 69 78 84 69 82
TAINMENT CENTER  84 65 73 78 77 69 78 84 32 67 69 78 84 69 82 32
                32 32 32 32 32 32 32 32 32 32 32 32 32 32 32 32
@/?A????????     12 0 0 0 64 47 255 65 255 255 255 255 255 255 255 255
???????????????? 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255
???????????????? 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255
???????????????? 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255
???????????????? 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255
???????????????? 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255
???????????????? 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255
???????????????• 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 165


The EEPROM size is the same as the 89S52 RAM size and my guess is that the 89S52 copies the EEPROM contents into RAM at startup. This is all quite silly since the 89S52 has 8k of flash memory with probably more than enough space to fit in the marque text. However in our case it works out: if we don't like the HP marque text we can clip the EEPROM and create a sketch to overwrite the first 128 bytes of the EEPROM with our preferred text, or just spaces if we want a blank display. Good stuff, but I didn't see any other clues I could leverage.

#1
Mar 25, 2011, 09:13 pm Last Edit: Mar 28, 2011, 01:22 am by TitaniumStudios Reason: 1
Stuck, Time to Spend More Money

At this point I was committed to the challenge but pretty well stuck. While the programming interface on the 89S52 is hardware SPI, that hardware is not available to the user program. The pins are just general I/O, implying a slow, entirely custom communications protocol and trying to figure that out with experimentation seemed unlikely to succeed. I either needed to have the chip decapsulated and unlocked, or, spend even more money in buying an old, but still popular Digital Entertainment Center so I could sniff the communication protocol. There was actually a third option however: I'd already determined that to the PC, the display was a USB device but I was quite sure that the display did not implement USB. This means an intermediate circuit and I was able to find a picture of the board with the help of Google images. I was then able to locate a board on eBay for a reasonable price. This approach ended up working out.

So here is the setup:


It is quite the contraption. My laptop doesn't have enough USB ports and I couldn't find my USB hub. The only other thing I had to use as a hub was that Mac keyboard. The Mac keyboard can't supply enough power for the display at the back so that is powered by the old USB hard drive enclosure at the very back. The HP USB board is connected to one USB port. The second USB port has a Teensy (an Arduino compatible board) attached which is programmed to be a poor man's logic analyzer. In the front is an Ardunio hooked up to a second display so I can do experiments in reproducing what is displaying on the first display. Since I use Mac and the HP drivers are for Windows, the Mac is running Windows XP on a virtual machine. In the photo I am changing the time in Windows which will update the text on the rear display, which will then produce output in the Arduino serial monitor window.

A close up of the sniffing arrangement:

The Teensy is located bottom right. The black cable to the left is the USB cable I've used to connect to the HP board.

A better view of the HP board:


The board has numerous power and other connections and it was proving quite challenging to figure them all out. I determined that the display is driven by the large DIP IC, a Cypress semiconductor USB Microcontroller typically used for keyboards or other slow USB devices. It is then connected to a tiny USB HUB IC which in turn connects to the USB header on the board. I couldn't figure out how to power up the HUB IC so I decided to bypass it and just powered up the Cypress chip and the display. The black and white colored clips on pin 1 and 2 of the Cypress chip are connected directly to the USB cable. The green, yellow and blue clips go to the Teensy and are for sniffing the three signal lines running to the 89S52 on the display board. The HP board does not connect the display reset pin so I did not bother sniffing that one.

Interpreting the Logic Capture

Below is example output from the Teensy "Logic Analyzer" sketch. This sequence displays the characters for "PM":

Code: [Select]

00000010 15552
00000010 56
00000010 56
00000010 56
00000010 56
00000010 52
00000110 56
00000010 56
00000010 60
00000110 56
00000010 56
00000110 56
00000010 52
00000010 56
00000010 56
00000010 56
00000010 14528
00000010 56
00000010 56
00000010 52
00000010 56
00000010 56
00000110 56
00000010 56
00000010 56
00000110 56
00000010 56
00000010 60
00000110 52
00000110 56
00000010 56
00000110 56
Translation.
MOSI: 02h   MISO: FFh ?
MOSI: 50h P MISO: FFh ?
MOSI: 02h   MISO: FFh ?
MOSI: 4Dh M MISO: FFh ?


By this point I had tuned the sketch to just record on high to low clock transitions (bit 0) and to also translate the serial data into bytes. The right column is microsecond timing. The 56 microsecond clock period is very long, requiring about 1/2 a millisecond per byte of data. What was not obvious to me at first, but very important is that there are short byte sequences separated by 15ms delays. These long delays are actually part of the message, indicating "end of command". You can not send the next command without ending the previous one with a delay. This means that the display is slow to drive: A clear, set cursor and draw one character requires 3 long delays in addition to 3 ms to send the bytes. While the captured sequence is drawing one character per command I discovered that it is possible to send multiple characters per command, albeit without proper cursor updates. The Arduino library I'm working on is jumping through a lot of hoops to hide this complexity from the sketch.

Since I didn't have the Media Center edition of Windows, I could only get limited information to show on the display: the time, and "SHUTTING DOWN" when shutting down Windows. However the process of booting, displaying time and shutting down resulted in quite a bit of information. On startup and shutdown a clear text command is sent. A second command, which I figured out was intended to turn off any icons that were lit, can also be used to selectively set icons. Text drawing was preceded by a set cursor operation. At the end of shutdown a single byte command was sent which reset the display. Finally, every second a mystery command was being sent. When I sent it to my second display connected to the Arduino, the display got brighter than the power on default - a brightness command!

I found an extra pair of commands by sending experimental data to the display which were for blanking/unblanking display output. I am probably missing commands to scroll text and perhaps there is user defined character support  in there - there appears to be enough free RAM available in the 89S52 and character codes 0-31 currently draw a blank character.

Library and Documentation



I have created a library located here: http://arduino.cc/playground/Main/HpDecVfd

I have also put up some additional information about the module here: http://arduino.cc/playground/Main/H9150VFDData

cr0sh

This is an awesome writeup - I can't wait to see what else you do with this display; do you have any links to those suppliers you mention who carry it; are they common places like All Electronics and the like, or Ebay, or...?
I will not respond to Arduino help PM's from random forum users; if you have such a question, start a new topic thread.

#3
Mar 25, 2011, 10:59 pm Last Edit: Mar 29, 2011, 05:49 pm by TitaniumStudios Reason: 1
[Edit] In response to many requests for a source link, this eBay search will find them for you at <$10 including shipping. I have not dealt with all of these sellers. http://shop.ebay.com/?_from=R40&_trksid=p5197.m570.l1313&_nkw=%28H9150VFD%2C5187-8314%29&_sacat=See-All-Categories

Here are some other displays which I have written libraries for and am very happy with:


IeeFlip: http://arduino.cc/playground/Main/IeeFlip . The display shown and used for testing came from BG Micro. http://www.bgmicro.com/1x20vacuumflourescentdisplay.aspx . I like this display very much, I felt like I was opening a perfectly sealed time capsule from 1984.


PrimeVfd: http://arduino.cc/playground/Main/PrimeVfd . Prime Electronic Components have these for the crazy low price of $4 a piece. Base shipping was a little pricey so I bought more than one. The display isn't for every project, see the notes on the library page.  http://www.primelec.com/Electronic-Components/LCDs-Displays/NCR-Futaba-20-x-2-NA202MD13AA-p2594144.html

http://www.youtube.com/watch?v=D87qZISHIrA
Ncr4X20Vfd: http://arduino.cc/playground/Main/Ncr4X20Vfd . These are mine, I have more than I need. They come with a cable to make signal line hookup easier. http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&item=150559115610

#4
Mar 26, 2011, 08:08 pm Last Edit: Mar 28, 2011, 12:57 am by TitaniumStudios Reason: 1
I have uploaded a LiquidCrystal-like library for the above display: http://arduino.cc/playground/uploads/Main/HpDecVfd.zip

[Edit] Have added documentation and linked to it above.

Covered on Hack a Day: http://hackaday.com/2011/03/29/how-a-hp-vfd-module-was-reverse-engineered/

gigawatts

Congrats!  Welcome to the Hack-a-Day published club!  You deserve it!

LSDave

Does this library no longer work?  I've tried to load it, and i get error compiling on the hello world sketch.
I'm new to arduino, so i could be doing something wrong.
Here is the output i get when trying to verify.


In file included from HelloWorld.cpp:35:
C:\Users\LSDave\Documents\Arduino\libraries\HpDecVfd/HpDecVfd.h:62: error: conflicting return type specified for 'virtual void HpDecVfd::write(uint8_t)'
C:\Users\LSDave\Desktop\arduino-1.0\hardware\arduino\cores\arduino/Print.h:48: error:   overriding 'virtual size_t Print::write(uint8_t)'

Thanks in advance.

LSDave


Does this library no longer work?  I've tried to load it, and i get error compiling on the hello world sketch.
I'm new to arduino, so i could be doing something wrong.
Here is the output i get when trying to verify.


In file included from HelloWorld.cpp:35:
C:\Users\LSDave\Documents\Arduino\libraries\HpDecVfd/HpDecVfd.h:62: error: conflicting return type specified for 'virtual void HpDecVfd::write(uint8_t)'
C:\Users\LSDave\Desktop\arduino-1.0\hardware\arduino\cores\arduino/Print.h:48: error:   overriding 'virtual size_t Print::write(uint8_t)'

Thanks in advance.


Must use arduino 0023 to take advantage of this library. 1.0 doesnt seem to work.

Edmond

Hello,
The past days  i received a RM1-5059 HP control panel, i searched on the web for some solution to interface it with the arduino uno v3. Found some libraries for it http://playground.arduino.cc/Code/HpLaserJetLcd but it don't work. I have the IDE v1.5.5 if someone may help me with the correct libraries or some tip will be great.
Reply

Go Up