While a scenario of reading an LCD that was written by another host at first sounds possible and potentially simple, in practice, it is not really possible.
The issue is that the hd44780 physical interface (the pins) was not designed to be controlled by multiple hosts.
There are many issues that will arise with attempting to do this.
The first big issues is how to control the E signal.
How to arbitrate this control when there are multiple hosts attempting to control it.
There is also control of the r/w signal. The original circuit may ground this pin if only doing writes.
Also, one host may want 4 bit mode and the other 8 bit mode.
Then there is control of the data bus pins. The original host may set them to output mode and leave them which means that they are driven all the time, including when the host is not actively performing a write operation.
If this is the case, then when the 2nd host (the one trying to read the LCD) comes along and tries to read from the LCD, (assuming it could control the E and r/w signals) the LCD and the original host would have a bus collision creating shorts on the data pins since the LCD and the original host would both be driving the data pins.
And even if you added additional circuitry to isolate the E, r/w and data pins between the hosts, and ensured that both were using the same 4 vs 8 bit mode, (
like say using an i2c backpack which can allow multiple masters on a single i2c bus), there is the possibility of usage collisions.
I.e. the original host is attempting to write to the LCD as the 2nd host is attempting to read from the LCD or in the middle of reading the LCD.
There is no mechanism that can be used to tell a host to "wait a second" before controlling any of the signals.
Assuming that could be resolved - which is unlikely, there is the issue of timing between usage to account for instruction timing.
The reading host can't just immediately access the LCD after the first host finished sending something to it. This is because the LCD needs time to finish processing that instruction before it can be sent another instruction. In some cases it can be quite a bit of time.
For example, suppose the first host sent a clear or home instruction, those instructions can take several milliseconds to complete. If a host sends another instruction while this instruction is being processed it can create issues, including causing the LCD and host to lose nibble sync when using 4 bit mode.
The reading host would have to know what the last instruction sent was and when it was sent to account for the amount of time, but if the reading host is only reading DDRAM, (the contents of the display), it has no way of knowing what instructions are being sent or even when they were sent.
It is theoretically possible to snoop all the hd44780 signals E, R/W DB0 to DB7 and then internally emulating the hd44780 to determine what is on the display.
This would not interfere with the host that is controlling the LCD.
However, depending on the implementation of the host that is controlling that LCD, this can be difficult to impossible due to the minimum timing that is allowed.
For example, tcycE is only 500ns which means that the host can do a transfer to the LCD every 500 ns. That can be difficult to keep up another processor is polling the lines.
Even if using an ISR to trigger on E falling to monitor LCD writes, rather than polling,
the data hold time tH which is the amount of time the data (the data pis) are guaranteed to be valid for after E drops. tH is only 10ns
There is no way to respond to an ISR much less read the data pins in only 10ns.
That is the theoretically minimum timing/ maximum speed.
In practice it is not that fast on real-world implementations.
So in some cases it becomes possible to determine what is on the LCD by snooping all the signals, but it isn't a given that it is possible.
End even if it is possible, it requires fully emulating the entire hd44780 instruction set to be able to create virtual LCD screen to be able to see what is on actual LCD.
In the Arduino forum, I have seen several projects attempt this over the years, but the authors have abandoned them as it ends up being more complicated or more work than they anticipated.
Here are a few realistic real-world scenarios as to why you may want to read the LCD display.
None of these involved more than a single host.
Suppose you want to test the LCD memory.
In order to test the memory, you need to be able to write and read from it.
The I2CexpDiag sketch included in the hd44780 library uses this capability to test DDRAM.
Suppose you want to scroll each line of a display up to make room on the bottom line.
You could this by reading each line and writing on the line above.
This would not require any additional RAM - which can be precious on some processors and the scroll function would not have to know what was written to the LCD. It simply moves each line up by reading each line and re-writing it.
Note: scrolling can also be done using the LCD display shift capabilities.
The shift capabilities are more efficient since it does not involve any reading or re-writing of any data to the display.
It does require some tricky logic in the library to keep track of the shift offsets to re-map cursor positions but it can be managed.
In another scenario, the sketch really does not know what got written to the LCD but wants to get access to the characters.
Consider if the sketch used something that formats the output like the Print class to output a number to the display.
Something like lcd.print(var)
While the sketch can know the value of that number in the variable since it can look at the variable, it won't actually know what characters were written to the display since the Print class is formatting it. This can particularly be true when using floating point or non based 10 radix output.
This can be more complex than a simple variable particularly if using 3rd party Arduino cores and the printf method. i.e. you can do something like:
lcd.printf("sensor1: %d, sensor 2: %d", s1, s2)
In that case, the sketch does not know what was written.
Overall, in practice, reading LCD memory is of limited value given its narrow use cases.