Look again. If you define the pin then all they do is drive it low...PERIOD.

Well, obviously. That's because all of the functions in there are write functions. But the point is that pin is within control of the library if it is defined. In each writing function, they call it low again. So, for our read functions, we just drive it HIGH. How difficult is it to tell a signal to go high? Just one line of code added for that.

Unless you want to open a really big bucket of worms you should probably deal with the LCD memory as just that, 80 bytes of memory, almost always with an unusual gap in its addressing pattern that is handled automatically by the LCD controller.

Unless you want to open a really big bucket of worms you should probably deal with the LCD memory as just that, 80 bytes of memory, almost always with an unusual gap in its addressing pattern that is handled automatically by the LCD controller.

Don

At first I am writing it like that, just an absolute address. The user can handle any of that in code. I figured it would be more efficient that way since it would keep the code smaller for those that don't need all the bells and whistles. I will probably expand it further, though.

I don't think anyone has bothered doing this before because I can't really see a purpose for it, honestly. *shrug*

I don't think anyone has bothered doing this before because I can't really see a purpose for it, honestly. *shrug*

Nowadays there probably isn't any really useful purpose other than as an academic exercise. As I mentioned in reply #6 it could really be useful if you already were using an LCD in your design and you needed a few bytes of RAM for some purpose. If the LCD was memory mapped it was probably even easier do accomplish than it is now with our I/O approach. The Optrex manual (dmcman_full) has more on this aspect.

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 codeusing 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 suppliedLiquidCrystal library doesn't have any support for wrapping.

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!

I haven't finished the code yet. Well, actually finished it, but having some issues with timing and haven't had time to work on it again since last night.

I see another post like this in the forum, recently. I am really curious what the purpose would really be. I can't think of any use I would have for it. I was thinking maybe to support input by a user, but you have to white the character to be displayed for the input anyway, so you already know what it is.

Guys,keep in mind that the LiquidCrystal library that ships with Arduino today is pretty much stateless.It does not track any LCD state information like cursor position, memory addresses, scroll modes, etc...i.e. when you set a cursor position using setCursor() it sends a command to the LCD to set the memory address and that is it.Yes it does a quick sanity check on the values, butit does not keep track of the cursor position, nor any subsequent internal address changeswhen future writes are done.

Keeping track of the cursor position inside the LCD is not terribly difficult but the code to do that currentlyisn't there and isn't as easy as it would first seem.

To track things for line wrapping takes more than just knowing the geometry. You also have to keep and track state information for things the left-to-right vs right-to-left addressing.It also conflicts with the auto scroll modes, so that will potentially drag in the need for some othernew API calls to deal with that.

In my view, these libraries should be very small and simple and limited to uniquehardware functionality.Any other functionality like reading strings or parsing strings should not be donein a hardware library. That type of functionality should be handled by an upper layer since that functionalityis not unique to the hardware.

With respect to using ifdefs, issues with the Arduino IDEbuild methodology quickly arise. Library files are built separately from the sketch. So that means that a sketch cannot set defines to control conditional compilationof the library within the source code of the sketch.Also the way the IDE works, the IDE does not have a mechanism to set defines for a sketch.A library can have a separate configuration header file down its source directory which worksfor controlling conditional compilation options butthen the defines, and hence conditional compilation, is global sinceit will set the conditional values for all sketches.

I was aware of all those things up to the conditional compiling part. I did not know that. That sucks.

But, yeah, I knew that there would have to be other methods for reading the address counter to get the position, etc.. If the user wants to translate that into row and column, that would have to be left up to him. The easiest way to do this independent of the geometry is to just treat it like 0x00 to 0x80 memory addresses.

I'm certainly not planning to spend a great deal of time on it when I really don't see much of a purpose to it anyway. If someone wants to chime in (the OP perhaps) with a great reason to have this capability, I might move it up on my list of priorities. I just cannot think of a single use I would have for this.

A full implementation of the HD44780 is not necessary for 99.9% of the users. Reading the LCD would only be necessary for those who want to copy the display to another device (PC, for example) or who need to test the LCD programatically in a production environment.

do you have finished your code? If so, please publish it here, or mail it to me. I am looking for such a code for my "Textsystem" to write, edit, read text strings to/from a 2 x 16 or 2 x 20 or 4 x 16 or 4 x 20 LCD, and store the text, in case of error edited text, in arduinos- or external eeprom. I create and edit the text strings with a german ps/2 keyboard.

PS/2 keyboard functionality of writing and editing text, including cursor control for the LCD, are ok so far. Because all displayed charcters are stored within the lcd, the easiest way to store the displayed text in external eeprom ist to read the text from the lcd RAM, and move it to the eeprom. So your code would help me very much.