Control 8 LCDs with 2 pin + backlights

fmalpartida · October 19, 2011, 8:26pm

After having to use up so many IOs to control a character based LCD, I decided to make a small board that can be fitted at the back of the LCD and use the I2C bus to control it.

I have just completed the design of a board that does just that. It is compatible with a wide range of parallel character based parallel LCDs. The board can also be used as an IO extension for applications that require more IO pins than those available on the Arduino.

You are also capable of programming the lower 3 bits of the I2C address using on board jumpers, so as the title of this post says, you can connect up to 8 LCD to an arduino + their corresponding backlights.

I am currently completing the adaption of 3 libraries that will enable you to use the LCD with the same interface as the liquidCristal library, the LCD API 1.0 library and also a library to use the board as an IO expansion module. The idea is that the entire board LCD + backpack is fully compatible with the code you already have, but instead of using 8 pins to control it will it will be using the I2C bus.

I will be publishing shortly the libraries and Eagle CAD files so that you can use them.

My project only uses 2 of these boards, so I have a couple to spare just in case anyone is interested.

Here are some images of the board in action.

bperrybap · October 20, 2011, 5:45am

Have you seen some of the similar products that are already on the market, including libraries?
Here is a popular one:

If you read on this page near the bottom, you will find a link to a
high performance i2c library:
http://www.ladyada.net/products/i2cspilcdbackpack/

Most of the products I’ve seen provide a liquidCrystal compatible library that can be
selected by simply including a different header like:
#include <LiquidCrystal_I2C.h>

— bill

fmalpartida · October 20, 2011, 7:25am

Hi Bill,
Ummm, yes it looks as if I haven’t looked enough for electronics. The board is very much the same. While looking around I did seen the liquidLibrary_i2c in the play ground but couldn’t find anything that wasn’t on a breadboard. Such library is the one I am modifying to use a controller for the driver chip I am using. I have looked at the library of the link you’ve sent and it is similar to the one I am modifying. The difference is that I only use one i2c transaction per command or data, using a 1 byte shadow and mask for input/output. This makes the library a bit more performant to the one in the link.

Perhaps the main difference is that my board has a BOM, including PCB, of just a bit more of $3 for 1 off. Which is not bad for budget constrained projects and hobby.

bperrybap · October 20, 2011, 7:56am

There is a link to a higher performance i2c library in that 2nd link that also optimizes the i2c data transfers. Here is the direct link to a thread about it: http://forums.adafruit.com/viewtopic.php?f=19&t=21586&p=113177

Have you looked at using a shift register? This is also an interesting implementation for 2 wire control: http://code.google.com/p/arduinoshiftreglcd/ No s/w backlight control capability, and can only run a single LCD but it would be much faster data transfers.

For hobbyists, a DIP version of the board using either a 74164 shift register or a MCP23008 i2c i/o expander would be much easier for them to assemble/build especially as a kit.

The tricky part is how to handle the pullup resistors when using i2c if more than one board is to be used on the same bus.

Are you supporting using i2c to turn the back light on/off? It would be easy to do with a transistor on one of the i/o expander pins.

--- bill

fmalpartida · October 20, 2011, 8:09am

The board has a dedicated pin to drive the backlight. I was going to use port 7 but decided to drive it separately. I am using the "power" version of the i2c chip, so it can drive up to 40mA per port: PCF7485APWR from TI.

I will look at the library you mention.

fmalpartida · October 26, 2011, 9:07pm

The library to control the LCD via I2C is beginning to take shape.

I have reworked the LiquidCrystal library just a bit in such a way that both LiquidCrystal_I2C and LiquidCrystal_4bit inherit from it and
converted the LiquidCrystal class into a pure abstract class with 4 pure virtual methods.

This way, we can create and drive any type of LCD (4 bit or I2C) with exactly the same code. Needless to mention that the library is fully compatible with the original LiquidCrystal library. So applications that want to migrate to this version, only need to add a new include and create an LCD I2C object or an LCD 4bit object.

Here is a sample code of how it is looking.

Code for LCD I2C:

#include <Wire.h>
#include <LiquidCrystal.h>
#include <LiquidCrystal_I2C.h>

LiquidCrystal_I2C lcd(0x38);  // set the LCD address to 0x38

void setup()
{
  Serial.begin ( 57600 );
  
  lcd.begin (16, 2);                      // initialize the lcd 

  lcd.home ();
  lcd.print("Hello, ARDUINO ");  
  lcd.setCursor ( 0, 1 );
  lcd.print (" FORUM - fm   ");

  pinMode ( 13, OUTPUT );
  digitalWrite ( 13, HIGH );
}

void loop()
{
}

And this is how it looks with a 4bit classic LCD:

#include <Wire.h>
#include <LiquidCrystal.h>
#include <LiquidCrystal_4bit.h>

LiquidCrystal_4bit lcd(12, 11, 5, 4, 3, 2);

const int    BACKLIGHT_PIN = 7;

void setup()
{
  Serial.begin ( 57600 );
  
  lcd.begin (16, 2);                      // initialize the lcd 

  lcd.home ();
  lcd.print("Hello, ARDUINO ");  
  lcd.setCursor ( 0, 1 );
  lcd.print (" FORUM - fm   ");

  pinMode ( BACKLIGHT_PIN, OUTPUT );
  digitalWrite ( BACKLIGHT_PIN, HIGH );
}

void loop()
{
}

Appart from the “include” and the object creation they are identical.

Creating a reference to the base class (LiquidCrystal) allows you to maintain all the code available if you are using pointers to the LiquidCrystal library. Very useful for LCD based MMIs, … Allowing you to change LCDs or use one or the other.

I will be publishing all the information regarding the library and board (schematics and PCB design and associated board documentation).

What do you think?

fmalpartida · October 28, 2011, 9:54pm

Just completed the library to control most LCDs based on the Hitachi HD44780 driver (most alphanumeric LCDs).

The library is based on the standard LiquidCrystal Library but with a twist (I will make a new entry on this forum regarding the library). I call it the "New Liquid Crystal" library. It has the same interface, is more flexible, is more extendable and it is also a bit faster.

You can read about it and download it from here: https://bitbucket.org/fmalpartida/new-liquidcrystal/downloads.

Hope you like it.

Comments are welcome too.

bperrybap · October 29, 2011, 12:18am

Very nice. I like the layering. It would make it really easy to also add in support for using a shift register or a SPI interface: http://code.google.com/p/arduinoshiftreglcd/

While it has the same API functions, the interface isn't 100% backward compatible so I do have some concerns about backward compatibility and coexistence with the current LiquidCrystal library.

Since it isn't a drop in replacement for the LiquidCrystal library (i.e. you can't simply remove the current LiquidCrystal library and replace it with this), I'm wondering the value of using the same base name for the main header (LiquidCyrstal.h) since using it will break existing code because the final constructor names are different. Also by using the same name, this library cannot coexist with the current LiquidCrystal library. So it is a full commitment to switching over that requires removing the current LiquidCrystal library as well as modifying any existing code to use the new library.

What about using something like hd44780 instead of LiquidCrystal for the basename of everything? That way the library is totally separate and insulated from the LiquidCrystal library and can even coexist, which makes it easier for users to add without breaking any other existing sketches they may have that currently use the LiquidCrystal library.

If the intent is to replace the LiquidCrystal library, then, IMHO, I think it is important that it be a drop in replacement and still allow existing LiquidCrystal sketches to continue to compile without having to make any changes, even if it is as simple as updating the constructor names in the sketch.

I think it should be possible to provide 100% backward compatibility with the current LiquidCrystal library by providing a LiquidCrystal.h header file that provides the needed backward compatibility by including the other needed headers and providing the needed mapping either through preprocessor macros or wrapper classes/functions to make 4bit mode work just like the LiquidCrystal library does today.

That way, the new library would be a true drop in replacement. And while it would require the removal of the old LiquidCrystal library, it would still allow existing unmodified LiquidCrystal sketches to continue to function, and new applications could include the new headers and use the new constructor names.

One other small comment is that if the examples use .pde instead they would be easier to use with the older IDEs.

--- bill

system · May 6, 2021, 3:20am