Read the value from LCD(LCD1602)

I have LCD1602.

I want to write unit test that will check what is written to LCD. Is there a way to read currently displayed value?

Yes, but not with the LiquidCrystal library that is supplied with the Arduino IDE.

The HD44780 library, available through the library manager, does have that capability.

Don

Is there an example for HD44780 lib?

I am using this lib and connect via I2C.

I think it would be a good idea to explain what it is you really want to achieve.

The amount of display data on a 1602 LCD really is less than the size of the code required to read it. Any competently written code knows what is on the display because the code itself put it there. If you do not understand the nexus between what is displayed and the commands used to display it, then reading it back is not going to make it more comprehensible. :roll_eyes:

The amount of time I need to spend every time to manually execute regression tests after changes I make in my application much bigger than amount of time I need to spend on writing code for the test.

The idea is simple - Test Driven Development and continuous integration. Once written tests always much faster to run than any other manual testing.

So coming back to the testing.

I want to have a test that checks that LCD shows expected text. I use LCD I2C with HD44780 lib

1 Like

afedorov:
Is there an example for HD44780 lib?

I am using this lib and connect via I2C.

The hd44780 library comes with many examples. Each i/o class has its own set of examples.
The i/o class for hd44780 displays using a PCF8574 i2c backpack is hd44780_I2Cexp.
The example that shows reading display memory is ReadWrite.
See the included documentation for more details.
It includes LOTS of information on the library, the supported API functions, i/o classes, and links to h/w documentation/datasheets for various LCD hardware and chips.

--- bill

Paul__B:
Any competently written code knows what is on the display because the code itself put it there.

This is not always the case.
Applications often call libraries to display things and the called library function may do output formatting that is not under the control of the main application.
A simple example is using the Print class to print a number. It can be complicated to know the specific characters output or in some cases the actually number of digits/characters output.

There also can be more complex cases where the output characters can come from external sources such a serial connection or a network or if fancy xxprintf() formatting is used for things like left/right adjustment or field width filling.

--- bill

1 Like

Paul__B:
I think it would be a good idea to explain what it is you really want to achieve.

I completely agree with this.
It could be that wanting/needing to read the display is a case of an XY Problem.

For me in particular, I'm not understanding how reading the display helps as it isn't' clear what these buzzwords really mean:

Test Driven Development and continuous integration. Once written tests always much faster to run than any other manual testing.

My take is that reading the display requires modifications to the code so the code running when testing is not really the same code that would be shipping.
But that is based on not having a full description of what is wanted or knowing how the reads from the display LCD will be used.

--- bill

Paul__B:
Any competently written code knows what is on the display because the code itself put it there.

bperrybap:
Applications often call libraries to display things and the called library function may do output formatting that is not under the control of the main application.

I rest my case. :grinning:

So, first of all thanks for guidance in docs, I will go and read them.

bperrybap:
My take is that reading the display requires modifications to the code so the code running when testing is not really the same code that would be shipping.
--- bill

I've been talking about Unit test, so I have a class MyCoolLCDDisplay. I wanted to test it(actually do TDD).

Regardless, of how internals of class work I want to check that physical LCD shows expected messages for specific use-cases. Unless testing will make to modify production code, I am perfectly fine to have simple test that will do

init(){
}
loop(){
MyCoolLCDDisplay myCoolLCDDisplay;

myCoolLCDDisplay.showMessage("Hello World");

ASSERT_THAT(comeCoolLibrary.readLCDMessage(),EQUALS_TO("Hello World"));

}

The code that is shipped is MyCoolLCDDisplay

afedorov:
So, first of all thanks for guidance in docs, I will go and read them.

I’ve been talking about Unit test, so I have a class MyCoolLCDDisplay. I wanted to test it(actually do TDD).

Regardless, of how internals of class work I want to check that physical LCD shows expected messages for specific use-cases. Unless testing will make to modify production code, I am perfectly fine to have simple test that will do

init(){

}
loop(){
MyCoolLCDDisplay myCoolLCDDisplay;

myCoolLCDDisplay.showMessage(“Hello World”);

ASSERT_THAT(comeCoolLibrary.readLCDMessage(),EQUALS_TO(“Hello World”));

}




The code that is shipped is MyCoolLCDDisplay

afedorov:
So, first of all thanks for guidance in docs, I will go and read them.

I’ve been talking about Unit test, so I have a class MyCoolLCDDisplay. I wanted to test it(actually do TDD).

Regardless, of how internals of class work I want to check that physical LCD shows expected messages for specific use-cases. Unless testing will make to modify production code, I am perfectly fine to have simple test that will do

init(){

}
loop(){
MyCoolLCDDisplay myCoolLCDDisplay;

myCoolLCDDisplay.showMessage(“Hello World”);

ASSERT_THAT(comeCoolLibrary.readLCDMessage(),EQUALS_TO(“Hello World”));

}




The code that is shipped is MyCoolLCDDisplay

I see the simple comparison that you have shown, but I’m still not really understanding what you really are trying to do.

If all you want to do is verify that certain specific characters were written to the display by reading them back and verifying them, you can definitely do that with the hd44780 API functions write() and read().
You will have to set cursor positions appropriately.
But that really doesn’t test or verify much.
If the h/w is working, you are pretty much assured that the string of characters sent to the display is what ends up on the display as requested.

If you are trying to verify the actual LCD h/w, then the included I2CexpDiag sketch does a far better job than that type of simple testing.

If you are trying to verify that production code produces specific messages in real-world use, then that is potentially a much more difficult task as often real-world applications tend to produce dynamic information on the display so it becomes much more difficult to verify what was written or what was supposed to be written to the display as the output could have been generated across a period of time through multiple sections of code reacting to external stimuli.

BTW, not a fan of the new TDD methodology as I think it tends to encourage poor repetitive trial and error type coding practices over better planning and more up front layered s/w design and product life cycle methodologies.

— bill