I need to use an LCD I2c backpack to intercept the data between a circuit board and the display then send it through Particle. From everything I’ve read and through testing, the current liquid crystal i2c lib allows writing to, but not reading from, the LCD. Can someone take a look at this Arduino lib and see what it might take to make it work with Particle?
I found this via the Arduino forums where someone was wanting to do something similar and referenced this library as having the necessary read function in addition to write.
Not addressing your immediate point, but when you say …
… you’d not read from the display but rather “act as display” (man in the middle) for the original controller, interpret the incoming data and forward it either as received or tweaked as needed.
Can you elaborate what kind of data you need to read from the actual display?
I had a quick look over the main code and couldn’t immediately see anything preventing that library from working with Particle devices. Maybe just give it a try as is.
It would be a man in the middle type, but I would need the data to go to both the display, which is the user interface on site, and to the particle device for remote use simultaneously.
The data is information about the status of the board, programming information, voltage and amperage of the attached motor, etc. This is the only way I can see to get this information from this board.
Would using it as is be a matter of just copy/paste the files into the respective cpp and h files? I’ve never used a library that wasn’t already available in the IDE.
How are you building?
With Web IDE it’s a bit more effort, but CLI and Workbench won’t need much more than copying the files downloaded from the GitHub repo into the
lib folder of your project.
Im using the Web IDE, unfortunately I haven’t taken the time to be as familiar as i should with VS.
@Mjones, for a man-in-the-middle, aka a sniffer, the HD44780 library will only help you understand how data is sent to the display but it won’t help you capture the data in the first place. What you need is a “reverse” display driver.
Does the display you are trying to “sniff” have an I2C backpack or is it being driven directly? I suspect it is driven directly via a 4-bit or 8-bit bus. In addition, there are control pins to indicate a command or data are being sent, etc. The specific model or type of LCD would be useful. Sniffing would require using these signals to trigger interrupts that read the data lines at the correct time to “reconstruct” the data going to the display. That data would then need to be parsed to “extract” the desired data. The speed at which data is written to the display will dictate the rate at which it needs to be captured.
This is not trivial work but it is possible to do.
Hey Peekay, thanks for your help. The original display is just a simple 20x4 LCD, I ordered this: https://www.amazon.com/gp/product/B01GPUMP9C/ref=ppx_yo_dt_b_search_asin_title?ie=UTF8&psc=1 as a replacement specifically to gain access to the data, and to my surprise it plugged in and worked with zero modification needed. So I now have a functioning display with the I2c backpack, but the library I use doesn’t capture the data.
@Mjones, help me understand the setup. I am not sure what connects to what.
- What device drives the display and does it use I2C to do so?
- Where does the I2C backpack come in?
Perhaps a basic wiring diagram would help.
The current display is driven by the circuit board, it does not use i2c I believe the communication for these is parallel serial. The i2c backpack is something that I added; knowing that i2c is bidirectional, I thought this might be a simple way to catch the data.
This is a customer’s board, they wanted me to see if I could provide them with a remote diagnostic solution, unfortunately without a board redesign this is the only way to access the data.
A wiring diagram for this board isn’t easily available, they contracted with a company to build it based on a list of requirements for their gate system. The display does appear to be driven as a standard LCD since i was able to use an off the shelf unit as a direct replacement.
@Mjones, the PCF8574 supports quasi-bidirectional I/O:
A quasi-bidirectional I/O is an input or output port without using a direction control register.
Whenever the master reads the register, the value returned to master depends on the
actual voltage or status of the pin. At power on, all the ports are HIGH with a weak 100 A
internal pull-up to VDD, but can be driven LOW by an internal transistor, or an external
This may or may not interfere with the existing hardware. Also, the interrupt output of the PCF8574 is generated at any rising or falling edge of the port inputs. I don’t believe this is an ideal device for this application. Using a more programmable MCP23017 or MCP23008 I2C I/O expander may be better.
The real question is how is the display driven now:
- 4bits or 8bits?
- Speed of writes?
- LCD model number (HD44780U)?
This will dictate how many GPIO you will need to connect to the display. At 4bits, you will need 8 GPIO and at 8bits, you will need 12 GPIO. If the LCD display is an HD44780U, the write timing is shown below.
E pin is pulsed HIGH to indicate the start of a read or write and the data is latched on the falling edge of
E. Ideally, an interrupt is fired on either the rising or falling edge of
E so that the ISR can capture the data (DB0-DB4 or DB7) before it "disappears. With the MCP230xx, the interrupt will fire and it can capture the data on the port at the time the interrupt occurred. This allows you to read the value more “slowly” via I2C but it may still be too slow to capture a “stream” of data being written to the display.
This can be mitigated by connection the GPIO directly to the Particle device and sampling during the Interrupt Service Routine. Another approach would be to use a dedicate MCU (eg. Raspberry Pi Pico) to capture and buffer the data which can then be ready by the Particle via I2C or SPI.
I think this just took the project out. Not that it’s not possible, but the amount of information needed that isn’t readily available and the additional equipment, and recreating the speeds, and trying to catch all of this at the right time isn’t practical for the product they’re looking for.
They’ll be redesigning the board in the next year or so, I’ll have to work with them to make sure they have something that can be used in an easier manner.
@Mjones, if possible, sending data to a serial port would be simple to implement and capture data from.
I built a similar product for another board, but it had a UART built in so it was easy to connect. This one has a usb port on it, but they ran out of pins on the processor before doing anything with it, so now it only provides usb power, zero data.
You just need to invest in a digital analyzer, that will show you what you need, that or an o-scope. Both are extremely cheap for this frequency range these days.
I have an Oscope, but i dug more into it after peekays comment, it’s not an easy task at all. Many people in the Arduino forums and other places have tried, i didn’t find a single successful project.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.