Emulating LCD 16x2 HD44780 !

Hay guys,
I have and old device that is using a regular HD44780 16*2 LCD and a key pad. I want to change these two with touchscreen tft lcd. Meaning that I'm going to connect the datapins that goes into the lcd to the arduino and decode the data and show them on the tft lcd. Now my problem is with reading the input data ( that comes from the device controller and was supposed to go HD44780) and converting the ascii code to string . As far as i'm concerned it's using 8 bit mode . My question is , has somebody else done this before?! Is there a library for emulating the lcd ? The confusing part for me is the busy flag and responding back to the device!
It would be great if someone could give me some advice! :roll_eyes: :blush:

It would be great if someone could give me some advice!

If the 16x2 LCD that you will be replacing is running in 8-bit mode then what you are attempting should be relatively straightforward.

You do not have to be concerned with the busy flag since it is merely used to determine when to send information to the 16x2, and has nothing to do with what is sent. (see edit below)

You can monitor the 'E' line and each time it goes high and then low there should be new information on the data lines.

You can monitor the RS line to determine what sort of information is on the data lines. If RS is low you have non-ASCII commands going to the LCD controller. If RS is high you have ASCII codes (except for any user defined characters) going to the display itself.

Don

Edit: If the original program is indeed using the busy flag then you may not be able to 'replace' the 16x2 since the original program may require it's presence to run correctly. You could, however, bury the display out of sight somewhere.

Thank you very much for your respond!

Edit: If the original program is indeed using the busy flag then you may not be able to ‘replace’ the 16x2 since the original program may require it’s presence to run correctly. You could, however, bury the display out of sight somewhere.

what do you mean?!

if it is using the busy flag it means that the controller is asking the lcd to sendback the data in a memory address in the lcd’s dram, right? if yes, why is not possible to change it?!
also I have another question which is more likely weak programming skills that I have! My question is how to convert Binary (that I get from one port which is 8 bits) to ASCII and string?
Thank you guys again .

avrmp:
Thank you very much for your respond!

Edit: If the original program is indeed using the busy flag then you may not be able to 'replace' the 16x2 since the original program may require it's presence to run correctly. You could, however, bury the display out of sight somewhere.

what do you mean?!

if it is using the busy flag it means that the controller is asking the lcd to sendback the data in a memory address in the lcd's dram, right? if yes, why is not possible to change it?!
also I have another question which is more likely weak programming skills that I have! My question is how to convert Binary (that I get from one port which is 8 bits) to ASCII and string?
Thank you guys again .

I can't see any reason why you couldn't mimic the busy flag if necessary. You could probably just hold it low whenever RS=0 and R/W=1 and everything would be fine, as long as your arduino can process the incoming data fast enough. If not, then yeah, you'd have to set it high while processing the input data, assuming the busy pin was being used as a busy pin.

I don't know what you mean by "convert Binary to ASCII and string". ASCII is binary. Strings are groups of ASCII. The character data coming into your LCD is ASCII data. If you look at the datasheet, the binary data coming in for the character '0' is 0x30, which is the same as the ASCII code for the character '0'. So, whatever characters you get in, just display them (except for possibly some characters below 0x20 or above 0x7F).

Beyond that you have to worry about control mode, as well as programmed characters. Basically, you might have to emulate most of the things in the datasheet.

if it is using the busy flag it means that the controller is asking the lcd to sendback the data in a memory address in the lcd's dram, right?

No. Any time the controller (microprocessor) sends some data to the display it must then wait, while the display controller processes that data, before it sends any more data. The microprocessor can either wait a fixed amount of time, possibly longer than really necessary, or it can monitor the busy flag provided by the display until the display is no longer busy.

In a properly written program controller will 'time-out' waiting for a busy flag and then continue even if one was not detected. In a more simple program it will just hang if no busy flag is detected.

If pin 5 (R/W) of the LCD is connected to GND then the busy flag is not being used. If pin 5 is connected to the microprocessor then the busy flag may or may not be utilized by the program.

Don

I haven’t tried to do this, but a while back I did have a very long discussion with CrossRoads (another forum member)
about doing this on a ks0108 graphic LCD.
The command/data interface is nearly identical to the hd44780.

The biggest potential issue is the worst case timing, and the BUSY signal is of no help with respect to this.
The BUSY signal from the LCD that you might be emulating can only be used
to hold off the other end from sending another command or writing another character.
Once the BUSY signal is removed, there is no way to slow down or alter the expected timing
of the actual command or data transfer operation.

The timing issue for writes (command or data) is that the data lines must be sampled as the
E signal drops.
After E is low, the data lines are only guaranteed to be stable for tH (data hold time).
tH is only 10ns
So worst case scenario the data lines change 10 nanoseconds after E drops.

The timing for reads (status or data) is that the requested status/data must be presented on the bus
tDDR (data delay time) after E is raised.
tDDR is 160ns
There is no way for the LCD (or the AVR if emulating)
to indicate that the data is now “available”. It must be ready after tDDR
since the other end is free to sample the data any time after E is raised and tDDR has elapsed.
So worst case scenario the other end wants to read the status/data 160ns after it raises E.

For writes there is absolute no way the AVR can read the data lines within 10ns after
it “sees” E drop.
For reads it is probabaly also not possible to present the requested data in time,
since 160ns is only 2 AVR machine instructions at 16Mhz.


All that said, there is usually a big difference between the worst case scenario
of timing and the actual timing of the device driving the LCD.

The only way to know for sure would be to hook a logic analyzer and
look at the signals. WIth a signal trace you would be able to see
the timing of the E signal and how fast the device changes its signals
and come up with the needed reponse timing.

Depending on that timing, you may or may not be able to do it with directly
connected lines to the AVR.
If the timing is slow enough the AVR could read the signals directly,
if not, additional hardware will be needed between the device and the AVR
to latch the data signals to hold the data until the AVR gets around to reading it.

— bill