Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Can I use another Arduino2 to read the data sent by Arduino1 to the LCD screen? #34

Open
acewei opened this issue Aug 16, 2022 · 4 comments

Comments

@acewei
Copy link

acewei commented Aug 16, 2022

hello Perry!
Your library is perfect, comprehensive and easy to use. Thank you for your efforts.
I have a technical need. The Arduino1 board sends the temperature data to the LCD 1602 for display in real time (using 8-bit data line). Now I have an arduino2 board, and I want to use it to read the information displayed on the LCD 1602.
I saw the readwrite example given by you, and I have the following questions?
1: Your program uses a 4-bit data line to read the LCD. Can we use an 8-bit data line to read it? It seems that no 8-bit interface is provided.
2: "The purpose of this library is to use Arduino to read data from a character based LCD display device and assume that Arduino is the only device connected to the display and has full control over it." Is my understanding correct? Can I use another Arduino to read the information on the LCD?
I hope to receive your reply. Thank you again.

@bperrybap
Copy link
Contributor

The library only supports 4 bit mode. Due to the way arduino developers wrote the digital i/o core library (digitalWrite(), etc) 8 bit mode will not be much faster than 4 bit mode. Also, using BUSY will be slower than not using busy.
because of this I chose to only support 4 bit mode and not use busy status.

You can't use more than one host (arduino boards in this case) to control the LCD directly with pins.
Only one entity can control the E signal, data pins, R/W, RS pins at time.
The library controls the E line by driving both ways it drives it high when necessary and drives it low after a transfer.
It also sets the data pins to output which drives the pins. They are always in output mode unless a read is done, where they will temporarily be set to input during the read and then set back to write mode.
If you were to hook up two arduinos to the LCD the data pins, RS, and RW pin would short out as both would be driving their respective pins to different levels.

You might be able to use an i2c backpack, as the Wire library is supposed to support multi master, I have not tested this.

@acewei
Copy link
Author

acewei commented Aug 16, 2022

I see. Thank you very much!

@pixelwaster
Copy link

pixelwaster commented Aug 16, 2022

I agree, this is one the best libraries out there.

This is similar to a problem back in the mid-90s, There was no way to know what the new processors were doing so that logging could be done. The newest chips had become all-in-one. The LCD pins were read and then decoded. You could use arduino2 to listen for the E line (INT0 ?), read the 4 data, RW, and RS lines. Is arduino1 reading, writing, sending commands, or sending data? The fancy term I think is "side channel attack" ? Just a thought.

@bperrybap
Copy link
Contributor

That wouldn't be a side channel attack as there is no attack going on.
Is is snoopng.
It would be using one arduino to snoop the lines being driven by the other arduino, decoding the lines, then emulating the hd44780 controller to essentially create a virtual display in local memory that you can then look at. It requires emulating the hd44780 instruction set based on the instructions decoded from snooping the lines.
This has comes up every few years on the Arduino forum.
It is actually more difficult than it seems given the potential timing.
To have a chance at working the code cannot use the Arduino APIs to read the pins and must use interrupts. i.e. use interrupts for E falling, then read the pins using raw port i/o (if on an AVR) then buffer the data in the ISR, and process it in the foreground.
Snooping the lines being driven by the hd44780 library will be more challenging than most other libraries, given hd44780 is quite a bit faster at driving the pins than other libraries like say LiquidCrystal. The most time critical part is between nibbles where there will only be a few microseconds between E falling and the data lines changing for the next nibble.

I have seen a few attempts at this and only one kind of worked. It would not work with the hd44780 library for a few reasons the main ones being it was not properly emulating the hd44780 instructions, and it didn't always keep up.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants