How to Make a Display for Several Lines of Text, a Lotta Text on a MCU Project

[SuzyC]

I have several HP Deskjest, HP ALL-IN-ONE printers that friends have given me for parts. They have nice VGA displays that work, but how to salvage them?

Can I hack them for my own use?  What I would like to do is interface them with a few wires, a simple 8-bit/16 bit or serial interface to a PIC processor. I know it can be done!..(if my best friend was an HP engineer that designed the circuit/code for the display!)

Should I've posted this under Projects and Designs?

If this is a dumb idea, what cheap choices are there for a multi-line display (>4 lines by 20 chars LCD) for a MCU project?

[SL4P]

Wrong forum?
Talk to your 'best friend'...
He can tell you far more than almost anyone else here.
(He developed the hardware and original SW)

And yes..l unless there is something specific to those displays, the interface is trivial, and requires you to explore the chipset and suitable supporting HW

Good luck.

[SuzyC]

Your reply offers no help!

I don't have that friend at HP.

[SL4P]

Sorry, I read that your best friend (was) the developer!...Not if

Post some pics, device numbers etc, I'm sure I/we can offer more specific help.
20x4 LCDs are cheap, and if you're nearby, I'd gladly give you one along with some code assistance!
cheers - my bad

[westfw]

They have nice VGA displays that work, but how to salvage them?

Probably not full VGA (QVGA, perhaps?)
You can check the wiring, but I think that usually, these will be raw LCD panels, and the printer will use a relatively complex microprocessor that has a built-in LCD interface.  Just like smart phones, laptops, GPS units, eBooks, and ... lots of other "video appliances."   This tends to make them really difficult to interface to from lesser microcontrollers :-(

[SL4P]

no location in your profile...
if you're in AUST I can send you a 20x4 white on blue.
As above if you can identify/pics - we can help a.lot more

[SuzyC]

Progress?

I completely took apart the HP All-In-One and now and all I've saved is the switching power supply, the main MCU board and the LCD/select-switch board. All cables were removed from the main board except the power supply connector and the 22-pin flat printed cable connecting to the front panel LCD/select-switch board.  There was an additional flat cable of about 16 pins that I discarded that also connected to the 20 or so front panel switches matrix but seems to not at all affect the TFT display.

The board lights up when power is applied, displays the normal  24-point size letters "HP" centered on a gray background and then below shows  an animated  multi-grayscale progress bar and then finally, after about 30-secs changes to the HP blue screen of death, with Errror 0x37E0 displayed in white letters on blue background.

I guess it noticed that nearly everything has been disconnected!

So, all I need to do is figure out the pinout of 22-pin connector from the ARM processor on the main board. This connector seems only to use 18 of the 22 pins, and obviously at least two are for power, leaving 16 to hack into other functions.

The LCD/select-switch board has a "black blob" unknown graphics controller that feeds a very low profile flat connector to the ultra high density umteeen-wire flexable hi-tech double-sided PCB on plastic film cable going to the graphics display itself.

[SuzyC]

Thanks, westfw,

BTW, the printer display was from a HP Photosmart 3300 combination Fax, Scanner, Inkjet now reduced to a pile of pieces on the floor.

Yeah, not a true VGA in the PC sense of 640x480, but maybe some sort of TFT QVGA, but looks to me like it has very fine definition and the display is nice and bright and colorful and has about a 3.5-in diag. display area size.

[SuzyC]

Thanks a million SL4P, but I am living in the land up-over and need more than a blue 4-line by 20 display for this project.

[SL4P]

Up & Over - oh well...  I lived there once too!

Without checking too deeply on models etc, the display looks like a colour bitmap (not character based...)  the good news is it still works, the bad news is that all the display data is probably burned into the uP on the main board. 

Nothing other than sensor status and buttons will be sent to that board - so displaying your own text etc will be somewhat less than easy.  The only other source will be reading images from the CF/SD card - to preview images on the display. I doubt you'll have access to strings/fonts or anything else at all.

Next?
There are some tear-downs to recover (Canon) printer control panels  - probably others as well...  If you have a scope, dig around to learn about the display signalling and other components before you break something(!)

In reality, the whole cpu & display probably costs HP a grand total of $5 ex-factory in huge quantities, so the effort needed to repurpose it for a one-off hobby solution is hardly there, when uP dev boards with ethernet, VGA LCD and other peripherals are available for under $50 all-in.   

Labor at $50-80 per hour x 30 hours (to get it roughly right) == $1500 to $2400 for a one-off gadget with very little flexibility or chance of future supply, but you will learn a lot !

[SuzyC]

SL4P, Thanks for the warning.

The TFT driver chip is for sure located on the front panel PCB(its a >=48pin) and it is a "black blob" of epoxy covered package-less  TFT display controller chip., but there are no sensors or this two-side PCB, so I am sure the mainboard ARM processor is only sending it high level graphic commands and data and also power via the 22-pin flat cabble connect.

Fortunately, the surface mount connector on the 22-pin flat cable connector has easy to probe large pins.

But your wisdom of my labor costs v. buying a new known datasheet supported display makes good sense.

I have a 4-channel Rigol 200MHz scope with 2meg of memory so I could monitor up to four signals at a time, a clock signal would be easy to find, the CS and Reset pins should also show very little going on, and the data pins should sing like a canary.

But even at that point, having clock, control and data lines isolated, hacking the display interface is a daunting Chinese Puzzle.

I would have , to go through a lotta permutations of data bus wiring bit0 to bitx order possibilitites to maybe someday correctly identify the order of  maybe 8-12 bits of data bits. The number of tries to do this is a big-big number.  I could assume that the data bins are in order on the connector, but PCB constraints may mean that bit6 follows bit 8 etc.

And even at that point, if I somehow manage by luck or fate to get the display to display some garbage, I still would not know the high-level commands and the syntax that are the libraries imbedded in the ARM processor code that feed the display processor on the front panel.

Also, I know that the display is obviously also a touch screen, so this adds to the complication, there is got to be bidirectiional communication back to the mainboard for display status and touch feedback.

Oh Dear!

On the other hand, the power supply is a very compact, metal shielded dual 31-V at 1.4 amp unit, could be great to power a dual tracking power supply or else could be used for my Hakko 888b soldering handle and the mainboard also has a lot of nice labeled switching inductors to be salvaged etc.

Ok, then, then perhaps there exits the software library supported Arduino display of choice as the answer. Has anyone found how to adapt a 3.5-in graphic or graphic-touch display that has a SPI or I2C serial interface?

With the Arduino TFT libraries, it might not be so hard to think that it would be a place to start to find an Arduino supported display whose TFT libraries can be adapted to become the display of choice for anyone's generic PIC project?

Anyone out there not  in the Arduino camp but has adapted an Arduino display for their MCU project,  or else could guide me to something else cheap or better?

Help! I have found a 3.5-in display on Ebay,  the libraries were open source C-code, but all the C-code had comments in Chinese!

[SL4P]

Nice scope...!
I think your reward factor will be a lot better going with off the shelf LCD goodies.

There are many Arduino compatible graphic LCDs... some better than others?

Search the forums for glcd, and you may get a direction to follow.
The issue I've seen as most 'variable' is the quality of the edge/back lighting.
SPI seems the most popular interface for hobby style displays.

[JacquesBBB]

the screen depends very much on your use.

I have several of these two lines
http://www.ebay.fr/itm/Green-green-backlight-LCD-1602-16x2-Characters-display-for-Arduino-/321705671798?pt=LH_DefaultDomain_0&hash=item4ae726fc76

But if you want  4x20,
You can get one of these

http://www.ebay.fr/itm/2004-204-20x4-Character-LCD-Display-Module-HD44780-Controller-Blue-Blacklight-/400448319287?pt=LH_DefaultDomain_0&hash=item5d3c946f37
with the  I2C interface
http://www.ebay.fr/itm/IIC-I2C-TWI-SPI-5V-Serial-Interface-Board-Module-for-Arduino-1602-LCD-Display-/181308046882?pt=LH_DefaultDomain_0&hash=item2a36cd3e22

Of course, these are basic  character screens, but very useful. You may then want to go to color bitmat screens.
There is a large choice of them. Consult the Adafruit website for a selection.
http://www.adafruit.com/category/63

The problem with all screens  is that they are power hungry. If you look to low power stuff,
what I like is the nokia 5110

http://www.ebay.fr/itm/84X48-Nokia-5110-LCD-Display-Module-blue-backlight-with-PCB-adapter-for-Arduino-/110950888604?pt=LH_DefaultDomain_0&hash=item19d530349c

I have not found  many that will beat it in term of power consumption.

[22swg]

I have played around with 0.96" OLED recently , This one I2C. 8 lines x 24 of very small chars if required ( firs pic) , did my own font thing (other pics.)
http://www.electro-tech-online.com/threads/that-hello-world-oled-moment.143878/#post-1212643

[PioB]

Hi,

here's one of the canon links:
http://hackaday.com/2014/09/11/re-using-the-lcd-button-assembly-from-a-broken-inkjet-printer/
There seems to be a wide range of libraries, maybe one has something:
http://playground.arduino.cc/code/LCD (HpLaserJetLcd?)

[SuzyC]

Thanks, JacquesBBB and 22swg.

However, I definitely want to have more than 8 lines of display with a display size of >=  3.5-in diag.

[22swg]

Hi SuzyC   .... My other display is a 4D systems , serial 3.5" as per link do loads with it has touch , SD slot and sound ... but not cheap... paid  60 GBP some time ago, Hows the robot doing ?

http://www.4dsystems.com.au/product/uLCD_32PTU/

[SuzyC]

PioB, Thanks, I browsed the Arduino LCD libraries but, although the list is long, there doesn't seem to be much of any value except for the usual dumb max 20 char x 8 line LCD display.

There doesn't seem to be a lot of useful knowledge for the latest known able, available and cheap for sale  >128x64 TFT display.

[SuzyC]

Thanks again for your help 22swg!

The robot is coming along fine.

It will be yet some while before I catch up with the Japanese.

As  you can see, I am now working on adding a display to expose variables, procedure states etc for testing/debugging/tuning of my code.

That display you've used seems to me 2 b 2 expensive. There has to be a cheaper alternative short of hacking this fine HP
display.

I wonder if they once told Turing,"Hey kid, forget about trying to break this Enigma Code, by the time you crack the code, Hitler will be mayor of New York!"

[SuzyC]

Has my mind been destroyed by too many diet sodas?

On second thought, looking at the prices of available displays, I am almost ready to go back to hacking the HP display.

Automate the hacking?

I could attach a photo transistor to the face of the display and have a MCU step trough random permutations on the data/control lines. If the display changes, it records the bytes sent. I can just sit back and watch "The Walking Dead"episodes until the display is hacked!

[22swg]

Can't you add a USB / serial FTDI 'bit'  and send info to a PC running terminal emulator ...

[SuzyC]

22swg, Thanks for advice,

I've been sending data hardwired to a pc via the serial port up to this point.

[westfw]

displays the normal  24-point size letters "HP"

If you're getting a display like that without the "display board" being connected to the "main cpu board", that implies that the display board has quite a bit of intelligence.  But I'm not sure whether that's a good thing overall.  On one hand, you wouldn't have to provide a continuous stream of lvds bits to a bare AMLCD "controller."  On the other hand, it probably means that you have a highly proprietary HP interface and communications protocol to figure out instead :-(

I've been a little surprised that the defacto high-res graphics display for small projects hasn't become an android app running on some cheap phone or tablet, with a simple communications link of some kind.  A re-invention of the "smart" ascii terminals from the mainframe days, with rather un-balanced processing power ("My main CPU is a 32MHz Xmega with 128k of flash; my display is a quad-core 700MHz ARM with 1GB")  I mean: two-year old phones are essentially free, new 7 inch android tablets sell for under $50 (comparable to bare displays of similar size and resolution), and you can scale up relatively arbitrarily.  The weak link is probably communications: no one wants to use WiFi to communicate with their internal display. (although given $3 ESP8266 units, it might not be as unthinkable as it used to be.  (but: security!))

[22swg]

22swg, Thanks for advice,

I've been sending data hardwired to a pc via the serial port up to this point.

http://www.tau.ac.il/~stoledo/lego/AVR-ir/

http://forum.arduino.cc/index.php?topic=10555.0

So you just want an un-hard wired link...  wireless would be overkill , how about an IR link like in TV remotes

[SuzyC]

westfw, Thanks for your input about my output problems!

I think you read it wrong. The main board(which has switching power supplies, the ARM chip, printer head drivers, etc.will send the "HP" message to the front panel without any other connections other than the single 22-pin connector connecting to the front panel. On the front panel their is an unknown "epoxy black blob"  display controller chip that feeds a connector to the TFT display.

The point is that the ARM chip is sending the "HP" message to the display chip that connects directly to the display.

But there might be a Rosetta Stone thing going on. The normal turn on display might be a simple or complex numerous set of commands, but after the ARM chip has realized it is really disconnected from everything except the display, it goes black, then displays a "blue screen of death" with only Error 0x7e0. And this final result may be the Rosetta Stone because it may only be created by a minimum of commands to initialize the display, set a background color, and position a single line of text.

Now if this display is a type of PAL or NTSC, this could be a difficult display to deal with, but the PAL or NTSC Vert and Horiz. sync lines would be identifiable.

However if it is not, I could assume:
If I could initialize the display, set background and text color, position the text, and send text to the display, this is all I need to make very good use of the display for my needs.

(for certain)I can see only 18 pins of the 22-pin connector from the front panel to the mainboard are being used.
This means at least two pins are being used for VDD and ground.
One pin must be a display chip reset.
One pin would likely be a CS pin.
One pin might be a "busy" output from the display chip.
One pin would likely be a Command/Data "E" bit.
One to 4 pins might be used for mode select for the display controller.
Depending on the above, this leaves maybe 8 wires for 8-bits for data.

(1) (I am just guessing but maybe..)Only a few commands result in the final error message display, but they describe initialization, background color, set text color and size, set text mode and text position and finally there is sent a command to display the error message string.
(2) The "epoxy black blob" is not a custom chip designed just for this printer but one of the not-so-many display controllers, meaning I could look for command sequences that matched these chips.
(3) The data lines will all switch states as a group and follow repetitive transitions of the clock line and thus can be identified.
(4) The clock line would be easily identified by its regular hi-lo-hi pattern.
(5) The reset pin could be easily found by just finding that pin that resets the display.
(6) The CS and Command/Data control lines must change states infrequently and mostly toggle infrequently and then hold their states.
(7) The data lines bit order bito--bitx could be identified by finding in the data stream the displayed text, most likely in ASCII.
I could slow the ARM chip (by switching its xtal from a 38MHz xtal to perhaps a 4MHz xtal) to change it from a rabbit to  a turtle. I could even feed the ARM chip xtal pins my own clock and turn it on and off and set its freq. at will so as to halt the ARM chip (assuming it has no lower limit to the clock freq.) to capture the function of the data stuff fed to the display chip.
Finally, ARM chip slowed down, the final events leading to the blue screen can be captured by input pins on a MCU and once recorded by a MCU, they can be played back and hacked to determine how these lines change to control the display.