Arduino + LCD

For a project I need to display temperature, humidity, EEPROM usage (x of 1024 bytes used), a sort of progress bar (when transmitting the content of the EEPROM over the serial interface to my pc) and some status messages on an LCD. The whole thing is working, except the LCD part.

I haven't made any experience with any type of display yet, but according to my previous searching I found out that a 16x2 or similar LCD would be enough for my needs (assuming that it's easier to handle a 16x2 LCD compared to a graphic LCD). Please correct me if the latter is not "that" correct. Maybe it's not much harder to talk to a graphic lcd than to a character based LCD, but I can't tell that. In this case I would prefer the graphic LCD.

I would ask anyone who hase made experiences with LCDs so far to give me a few hints on what I sould consider to choose right.

Here are some things I have considered so far:

  • It should be compatible to an existing lib (e.g. LiquidCrystal or SparkFunSerialLCD for character LCDs or KS0108 library for graphic LCDs --> these are just examples, I picked them at random. I don't know if these libs can be used with displays that fulfil my needs).
  • I'm planning to use the Ethernet-SD shield for data logging too (could that cause conflicts?).
  • I'm using several Buttons, sensors, LEDs, so slowly but surely I'll run out of IO pins. I would prefer to talk to the LCD in a way where I don't need much of the IO pins. When I'm understanding correctly, there are LCDs that need ~11 pins. That's way too many. However, there are LCDs that need only 4 (serial communication) or 2 (I2C) pins. So I guess, if I choose an LCD, it should be able to communicate over a serial interface (hardware or software) or i2c, whether it's a 2x16 or graphical.

So please give me your opinion if I should take a character based or graphical LCD and then maybe even which one would be good for me exactly.

Thanks for help!

I think it is safe to say that it is easier to deal with the character mode LCDs than the graphical mode LCDs.

The character mode LCDs (16x2, 20x4, 40x2, etc.) all use the same 14-pin parallel interface. Many now have 16 pins, but the two additional pins are for the backlight, not the LCD and the remaining 14 pins correspond exactly to original the 14-pin interface. Of the 14 pins three deal with powering the LCD and it's controller, three are 'control' pins, and the remaining eight are 'data' pins. You can always get away with using only four of the eight data pins and you can usually get away with using only two of the three control pins. This means that for a parallel interface you will tie up at least six of your Arduino pins. The LiquidCrystal library can deal with any of these combinations.

There are add on boards that use a dedicated microprocessor to accept one or more of the various serial protocols (RS-232, TTL level 'RS-232', I2C etc.) as an input and generate the required parallel interface signals as an output. Some of these are sold as add-ons and others are sold with the LCD module already attached.

The basic parallel LCD modules all use the same instruction set so the LiquidCrystal library works equally well with any of them. On the other hand, each of the various serial devices uses it's own instruction set so you are at the mercy of the manufacturer for software support. So if you can afford the pins you are probably better off using a parallel interface (maybe use a Mega). This also gives you the capability of specifying which pins to use. For the luxury of using fewer pins you will have fewer choices (if any) for prepackaged libraries. If you want to use the built in I2C or Serial capabilities of the microprocessor then you will be restricted to specific pins.


Hello, Don!

Thanks for clarifying the advantages/drawbacks of parallel/non parallel mode. This helped a lot for my basic understanding of character based LCDs.

However, I may have expressed myself a little bit bogus.
For graphical displays:
If I had “just” to implement sort of “paint” method where I say something like “pixel with coordinates (x;y) turn black” it wuld be sufficient for my needs. If there are convenience methods like “draw a rectangle starting at (x;y) ending at (a;b)” it would be nice to have, but is not so essential.

So maybe you could clarify WHY graphical displays are harder to handle?

Another thing I wonder: Would it be possible to use a shift register to save IO Pins? If that meant that I had to adapt a library, I think I could handle that - so the assumption I mentioned “it should be compatible with an existing library” would be fulfiled if I just had to ADAPT an existing lib.
What are the drawbacks if I chose your suggestion to only use six of 14 pins? Why does that work actually?

Do you know any prepackaged libraries that use fewer pins than 6 (whatever wiring is used)?

So far I’m not using any of my analog pins. So an I2C solution would be possible for this specific project.
I’m not sure about the hardware serial solution as I transmit data over the serial interface (pins 0, 1) to a PC. It would be ok for me to implement a solution that makes it possible that the LCD and the data transmission can share the serial interface (as I’m using only one of the two functionalities at a time).
Regarding the pins, I’m quite sure that a software serial solution would work.

So considering these aspects, which display(s) would you recommend now?

When it’s possible, I would like to stick to my Duemilanove and invest some effort to get everything work. However, I agree with you that buying a Mega would be the easiest way to get a result.