Odd LiquidCrystal behavior

Forum 2005-2010 (read only) Hardware Interfacing
#1

Built a simple techometer (i.e. RPM-measuring-thing) recently that printed its measurements to a 1x16 LCD. I got it all working easily enough, but I came across some odd behavior. I'll describe it here in the hopes that someone might explain what's going on, and so others can find the workaround I used.

I used the LiquidCrystal library to handle the LCD (obviously), but for some reason, I couldn't print to the entire row. I could only print to characters 0 to 7 - half the display's width. Here's the odd part: I'd set the LiquidCrystal-object to behave like a 1 row x 16 char display, but I found that I could a) set the cursor to the 2nd row (index 1) just fine even though I'd only declared one row, and in fact the 2nd row corresponded to characters 8-15. So in order to print to the entire row, I had to print to row 0, chars 0-7, and then to row 1, char 0-7. I should have been able to just print to row 0, chars 0-15, but nope: In software, the display's single row was somehow split into two rows. I looked around in the docs but found nothing that explained what was going on. Everything worked out fine, but it was an odd hack.

Here's the display I used (from a pretty awesome Swedish electronics shop): http://www.electrokit.se/opto-display-lcd-lcd-1x16-tecken-jhd161a-tn_41000945

#2

Flambino:

You can find a complete explanation for the curious behavior that you noticed by following the [u]LCD Addressing[/u] link at http://web.alfredstate.edu/weimandn.

Don

#3

You can find a complete explanation for the curious behavior that you noticed by following the LCD Addressing link at http://web.alfredstate.edu/weimandn.

Thanks Don! That does indeed explain it. I figured that the LiquidCrystal library would abstract exactly that kind of thing, so one could just print to row 0, cols 0-15 without having to worry about memory addresses being split into to two rows. But I didn't know that there were two types of 1x16 displays, so of course the library can't automatically assume what type it's dealing with. So thanks again - things make sense now :-)

#4