2X16 LCD Sniffer

[Sam_40]

Hello,
I am working on a project involving an older industrial control board that uses a standard 2x16 character LCD based on the HD44780 controller.
The issue I am facing is that the LCD is located in an inconvenient position, so I am considering removing it and instead capturing the LCD data signals and transmitting them to a remote display about 20 feet away.
The LCD interface has the typical 16-pin configuration (GND, VDD, VEE, RS, RW, E, and D0–D7, plus backlight pins A and K). All data lines D0–D7 are currently connected between the controller board and the LCD.
I have tried probing the signals with an oscilloscope, mainly focusing on RS, E, and the data lines, but it is difficult to clearly determine whether the system is operating in 4-bit or 8-bit mode. I do see valid square pulses on RS and E, but the data lines are not easy to interpret due to timing and overlap.
I also noticed if the LCD is plugged in after the system is already powered on, it displays solid blocks on the first line and nothing on the second line. However, if the system is reset with the LCD already connected, it works correctly. This makes me believe the initialization sequence is only executed at startup.

My main questions are:
What is the best practical method to reliably capture HD44780 LCD data in this type of system using PIC microcontroller?
Is there a recommended way to determine whether the interface is running in 4-bit or 8-bit mode without a logic analyzer?
For a 20-foot distance, would you recommend directly extending the LCD signals, or is it better to decode and retransmit the data using a microcontroller? I tried to use a shielded cables but will not work past 3 feet. I also prefer to get it on a PC monitor.
My goal is to reliably replicate the LCD output at a remote location without affecting the original system’s operation.

Thank you for your time and any guidance you can provide.

[newguy]

Have a look in the code library for PCM programmer's flex LCD driver. Understand that and you'll understand everything to do with your current predicament. Probe & examine the 8 data lines, RW and E lines. Nothing else has to do with the data/driver itself.

For your remote display issue, it all starts with decoding the lines first and foremost and then tying everything back to display commands (i.e. erase screen, cursor position, etc.) and actual data to display. Again, using the driver as a starting point you'll be able to interpret the commands. Once you've worked out the interpretation, it's up to you to come up with your own bespoke comm link to relay what's happening on the main display so that it can be copied on the remote display. 20' is a good distance and I recommend you implement some form of differential signalling between main display and remote display unit. The remote will require a microcontroller and your main display will likewise require some custom PCBA with micro running some sort of 'sniff & transmit' code. I recommend differential signalling due to the noise immunity such a format affords.

[temtronic]

to add to Newguy's post......
Be sure to get the HD44780 data sheet ! You'll need it to decode how the LCD module is setup and the tricky part, to 'sync' the PIC with the LCD data.

for the hardware...
Be sure to use 'buffers' between the 'industrial control board' and your 'sniffer' PIC. That way you won't destroy anything.
Probably best to use 'serial' and RS-485 chips between your PICs. Easy to do and allows a PC running a terminal program to display and confirm 'data' is correct.

[Ttelmah]

I think you are missing what he wants to do!!...
He wants to extend the data cables driving an existing Hitachi style
LCD controller 20'. He is talking about two possible routes:
1) transceivers to give the extended length.
or
2) 'sniff' the LCD transactions with a PIC, and then recreate these at
the other end. Obviously PCM Programmer's driver could help with
the 'recreation', but not with any of the other stuff.

Now the big question is how noisy the environment actually 'is'. TTL
signals can even ho this far in a low noise situation, but as distance goes
up you have increasing need for protection. It is 'borderline far'.

On sniffing with a scope, you should be able to turn off 'auto' on the scope
and sync to the 'E' signal, and then see what is going on. If all eight
data lines are connected, they are probably used.
Doing a PIC based sniffer would require using a fast chip, and handling
the sampling 'in line'. not using an interrupt, since the speed could easily
be faster than the PIC can easily sample. You need to work out if the
connection to the display is a simple 'output', or bidirectional. If the
latter, it makes all approaches much harder.
Find out how many lines are actually used, whether the data is bi-directional,
and the speed being used. We may then be able to suggest a way to go.

[temtronic]

hmm, thinking on this again..
..it's only 20'.

74LS244 buffer should do the trick as an 'extender'. It's a fast device with good current capability.

Might be a 'one chip' solution ??

[Sam_40]

Thank you for the reply.
I’m familiar with the PCM programmer's flex LCD driver and the 8-bit mode, as I’ve used both in the past. However, I’m not sure how they relate to my current project. The target board is running in 8-bit mode with all data pins connected. I also confirmed the 8 bit mode myself. The LCD datasheet indicates it uses the ST7066 processor, which I understand is compatible with the HD44780. I tried using a buffer, but even with an LCD at the other end, it failed because I couldn't change the direction of the busy flag, and the parallel data cable length is limited. My current plan is to use a PIC18F4685 to emulate the LCD, then send the captured data via a MAX232 to a PC terminal. Is this doable? If so, what would be the best approach?
Thanks in advance!

[Ttelmah]

Exactly.
I realised this was not really applicable for that you wanted.
The big question/problem, is whether the controller uses the R/W connection?.
If it doesn't, then as Jay says, I think the easiest way, would just be
to add a data buffer chip, and send the signals directly. I'd probably
suggest adding some trapping/suppression at the far end.
If however the unit does use the R/W connection, the problem appears
of the buffering having to be bi-directional, and the signalling will get a
lot more complex. In this case, trying to 'snoop' the LCD might be worth
trying. For this you would actually have to program the PIC to be a direct
emulation of the Hitachi controller. It'd need to support 4bit mode and 8 bit
mode (remember the controller wakes in 4 bit mode, and is then turned
up to 8 bit mode as part of the initialisation), and basically grab the
commands and data, then forward these to a second unit at the display.
This link will be relatively complex (since the data rate will need to be
quite high), so probably worth using something like RS485 at a high rate.
At this 'slave' you could then use PCM Programmer's code to actually
drive the display here.
So you need to find out is the R/W connection is used, and answer about
the noise.

[Sam_40]

Yes, The RW pin is used and I saw it toggling. what should be the sequence of operation in your opinion? I read both datasheets and I saw everything start at the rising edge of E, but i also noticed in the ST7066 that the data is valid from the rising edge of E to the second rising?

[Ttelmah]

The sniffer approach is going to be fairly complex. You'd need to have the
PIC give a software emulation of the display controller. Have E connect to the
interrupt input, but don't use an interrupt handler. Instead poll the
interrupt flag bit and as soon as it sets read the data. A lot will depend on
just how fast the data transfers are actually done. Ideally you would really
need to get access to a logic analyser, and see if the R/W is only used to
read from the controller, or is used to read from the display RAM. If the
latter, then I'd suggest you actually run a copy of the RAM in the PIC's
memory and return the data from this, rather than across the serial bus.
The timing of the latter might well make it too slow. You'd then have
a routine to send the display changes to the slave PIC. and have it send
these to the physical display. Some things can be ignored. for instance the
controller will send after boot the commands to switch the display to
the correct settings to handle the display, and switch the interface to
8bit. These can all be ignored, and you just handle these in the slave.