Go Down

Topic: How to read HD44780 LCD programmatically (Read 4 times) previous topic - next topic

bperrybap


Quote
I would think a read function where you give it an address and length would be useful. What else?


primary functions would be

char lcd.readChar(row, col)        // reads 1 char
char * lcd.readStr(row, col, len)   // reads len chars - should it wrap around end of line?

some ideas:

char lcd.readChar(); // reads form last known (internal) row/col  e.g. gotoxy(r,c); x = lcd.readchar()

char lcd.readNext(); // reads a char and moves to next position?


For reading data from the lcd, I'd prefer that it work just like the write() interface.
A single read() function that returns a byte(s) starting
wherever the address pointer is and lets it increment so it it is consistent with the write() interface.
i.e. a dual function overload:
read()
read(*buffer, size);

Any other needed functionality to set the location can be done by the users sketch code
using the existing API functions like setCursor()
Also having a simple read() API interface doesn't affect any of the other existing code
in the library as well as keeps the new API interface to support it clean and simple.

Having to deal with things like line wrapping on the display gets messy particularly since the existing Arduino supplied
LiquidCrystal library doesn't have any support for wrapping.

--- bill



robtillaart

I also thought of a lcd.read(*buf); that reads into buffer until end of line OR until a non-ascii (e.g. space) is encountered.
and what to think of lcd.readFloat();

and yes, these are all "intelligent" wrappers around reading a single char.
Rob Tillaart

Nederlandse sectie - http://arduino.cc/forum/index.php/board,77.0.html -
(Please do not PM for private consultancy)

robtillaart

Another idea: (thinking out loud ;)
should there be a separate current position for read and one separate current position for write?
Or do they share one current position?

The latter is easier, less footprint, but the first one might have some extra value..
Rob Tillaart

Nederlandse sectie - http://arduino.cc/forum/index.php/board,77.0.html -
(Please do not PM for private consultancy)

Retroplayer

In the library, the set cursor position moves to a row and column. There would be no difference between that and read. The only advantage I could see to a separate read position function would be to remember the old location of write and put it back. But that could just be done in the users code. With the read function, you just read out the address counter.

I think it makes the most sense to keep out bells and whistles (not because I am lazy) but because adding functions that the user will not use just makes the code bigger. I know there are ways to do conditional compiling, but I am not that advanced yet otherwise I would modify a nice FAT library to allow changing features since FAT libraries are around 10-13K in size when I mainly would only use read only!

robtillaart

I agree, keep the lib small

the read functions could be conditional with a "simple" #define construct.

something like this is all you need (
Code: [Select]
// uncomment next line to support LCD read function
//#define SUPPORT_LCD_READ

...

#ifdef SUPPORT_LCD_READ
uint8_t readChar()
{
  uint8_t ch;
  digitalWrite(RWpin, HIGH);

  ...

  digitalWrite(RWpin, LOW); // set back to write mode
  return ch;
}
#endif
Rob Tillaart

Nederlandse sectie - http://arduino.cc/forum/index.php/board,77.0.html -
(Please do not PM for private consultancy)

Go Up