Serial LCD driver, vs. I2C slave arduino?

Forum 2005-2010 (read only) General Frequently-Asked Questions
1

Hello all,

I'm running out of functionality on a project that's using an RBBB from Modern Device. I'd like to add an LCD, but don't think I have the program memory or pins available to just slap an LCD on the RBBB.

So, I started looking at LCD drivers that can communicate via I2C, SPI, or some other method, such as the Serial LCD board from Modern Device:

Then, I had an epiphany. That board, like many others, is in the $12 - $15 price range. That's what another RBBB would cost me! So, why not just get another RBBB, connect it to my current RBBB via I2C, and use the second RBBB to drive the LCD. Plus, I'd get the analog pins, PWM pins, etc. as bonus for future expansion.

Anyone see problems with this? Am I missing anything complicated about slaving an arduino on I2C? Will it consume too many resources or slow things down? I've never done anything like this, so I don't know how complicated the programming will be - Of couse, I'll have to send data to the slave device, then have some programming on it to interpret the data and display it on the LCD. Any examples? The master and slave examples for the wire library are a bit basic and have left me with some gaps in my understanding. . .

2

No your absolutely right, you can control one as a slave. The reason the LCD kit from modern device costs so much, is cause its already programed to be a slave and has all the helper functions programmed into it. you are going to have to program all these yourself. Its not hard at all, you just got to take that into consideration.

If you don't mind doing some soldering, I'd get one of the chips from here: http://phanderson.com/lcd106/lcd107.html Its the chip used in the Modern Device LCD driver. Its pre programmed and you just need to either breadboard it, or solder it onto a protoboard. There was another company that sold an I2C version as well, but I can't find it.

3

I may get one of the Serial LCD boards just to play with, AND try a second RBBB (I have a bare RBBB PCB and a bootloaded 328, so it would just be some rummaging to put one togeher.)

I'm just trying to get a feel from more experienced folks about the amount of complexity it would take to program an arduino to act as an I2C slave LCD driver, plus be able to use it's other pins (PWM please!) for "normal" use. I understand that I could use the liquidcrystal library to control the LCD from the slave arduino, but what I don't understand is how I would transmit commands and data from the master to the slave. All the I2C master-slave examples I've found concentrate on really simple things, where the slave only "knows" how to do one thing (blink an LED), and just waits for a pre-designated command from the master before doing it.

I cross-posted this on modern device's forum, and someone asked for more info on my project, so here's my response, in case people here would like more background:

Don,

I am working on a controller for an aquarium. This is intended to be both a functional project, and a learning experience. So, yeah, saving twelve cents isn't my only motivation here, so if that's what came across in my original post it wasn't intentional! While it would be simple to use the Serial LCD board, I'm wondering if the other option I presented (using another RBBB, communicate via I2C) would help me solve some other problems I may end up having as I continue this project. If I went with the Serial LCD board, all I'd get is an LCD. If I went with an RBBB, I get more PWM outputs, etc. But I'd need to do a lot of programming, in an area I'm not familiar with.

Basically what I'm looking for in this thread is a general idea - would that be a boneheaded and overcomplicated approach? If so, I'll just use the Serial LCD board, and port expanders or other add-on ICs to handle my potential other needs.

Currently, I have the following working:

  1. controlling several strings of high brightness LED lighting via PWM (I have drivers built around the OnSemi NCP3066 IC, which take a PWM signal to dim. I am using this functionality to approximate changes in light intensity throughout a typical day on a natural reef - dim in the morning, fading up to full intensity at noon, then back down to dim in the evening. Having multiple strings controlled independantly lets me also simulate relative position of the sun as it moves across the sky.)
  2. using one-wire for several temperature sensors
  3. using a DS1307 RTC via I2C for time backup (if the power goes out in the middle of the day, my program needs to maintain time when power comes back on, in order to pick up at the correct point in lighting schedules, etc.)

These items are all in progress. For some, I have some of the code and some of the hardware done, but for others, it's conceptual, so I don't know exact requirements (i.e. I don't really know if I'll need a bunch more PWM pins, but I have a feeling I will). And, I may add or drop from this list as needs dictate. Presenting this in order of decreasing importance (i.e. I will certainly do #1, but maybe not number 7)

  1. Controlling heaters and cooling fans from the temperature sensors
  2. Controlling one or more DC pumps to generate random water currents in the aquarium (the pumps have drivers that are designed to take a PWM signal)
  3. A "storm mode" for the lighting, such that the lighting dims (to simulate clouds blocking the sun) on a random schedule (hardware already in place, just need to code it)
  4. A moonlight simulation, following a 20-day moon cycle - dimming more LEDs via PWM
  5. A pH probe to monitor pH, and control dosing from a kalk reactor and/or calcium reactor to maintain steady pH
  6. An LCD to display temperature, pH, and other status information
  7. A "spill detector" to sense if water ends up somewhere where it shouldn't be (i.e. on the floor!) due to a leak or overflow somewhere in the system
  8. An ethernet connection to twitter or send text messages when alarm conditions occur (temperature out of range, pH out of range, spill detected, etc.)
4

Your going to have to do that bit of programming. Your going to have to create a bunch of I2C commands on your slave. Then your master can send these commands over I2C. Your slave in the meanwhile will keep polling and when it receives a command it will carry out what you want it to. In this case it would run commands off the liquidcrystal library.

Here is some more info on creating a simple i2c slave/master: http://www.arduino.cc/cgi-bin/yabb2/YaBB.pl?num=1208761098

5

So, bear with me through some pseudo-code to make sure I have this right.

  1. If I wanted to be able to set a PWM pin on the slave to some value, I could have a PWM function on the slave, called by ?p (for example), that took a two-digit pin number, and a three-digit value. Then send a string ?p09150 to the slave Arduino, which would set pin 9 to value 150.

  2. If I had lots of programming skills, I could implement a command set similar to the set used by Modern Device's Serial LCD board, such that sending "Hello World?n" would print Hello World to the LCD, then start a new line.

Correct me if the above-two examples are incorrect.

That takes care of the master sending commands to the slave, but what about the other way around? What if I want to read the value of an analog pin, for instance? I'll have to go study up on the master reading from the slave. Technically I'm already doing this (with the DS1307 RTC) but I admit that I just ripped that code off someone's blog or forum post, and I don't yet understand it. Plus, that's kind of one-dimensional. The master (my arduino) only ever asks one question (Hey, what time is it?) and the slave (RTC) returns an answer - I don't have experience with specifying which of multiple questions I want answered. . .

6

Yup basicaly you have to program those 2 examples. To read from the slave it would be the same code, except you'd do a "question-answer" (like you already have interrupted) interface instead of polling. just ask multiple questions for multiple devices. All you have to do is send the right address.

7

Here are some random thoughts on the topic:

If it were me, I wouldn't mess with I2C or SPI for this application. I'd use the serial port. You'll need two pins (RX and TX), same number as I2C. If you're already using the hardware serial port, use two other pins with the soft serial library.

Don't bother to convert the signal to RS232. Just use the 0 - 5V serial as it comes out of the pin. For cable lengths of a couple feet or less, this should work fine.

If you've managed to get one command working, you can get several working.

As to the LCD, get a parallel inteface LCD. The Arduino LCD library will let you do anything you want to do with it.

For the first version, I would keep it simple. You could make it general purpose, where the master could command the slave to write anywhere on the LCD, move the cursor, etc., but you probably will have fixed fields on the LCD. Instead of the master sending commands to position to the temperature field on the LCD, have a dedicated command that says "Update the temperature display to this value", followed by the new temperature. The slave knows where it goes on the display, so the slave will position the cursor to the correct spot before updating the temperature.

Also, I'd transmit all of the data in ASCII. In other words, if you want to send '99', send two ascii '9' digits, not one byte with the binary value of 99.

The reason to make it all ASCII is to make it easy to debug and test. A PC terminal program will let you pretend to be a master or a slave, and talk to its counterpart. Also, if you want to log the transmissions, they will already be in readable form.

Sounds like a fun project. Good luck!

-Mike

8

ill_switch

Did you see this yet? It was posted a few hours ago in the Exhibition section.

http://www.arduino.cc/cgi-bin/yabb2/YaBB.pl?num=1253551293

Don

9

mfm9,

Interesting suggestion to use the hardware serial port, but I'm not sure I understand how it would be better than I2C, if I'm already using I2C for other purposes (RTC, at least) - if I stick with I2C, it'll just be another slave on the same bus and consume no more pins on my master, while if I use the hardware serial port, it'll consume 2 more pins, correct?

Don,

Gasp! It's as if they were reading my mind. . . I'll have to keep an eye on that. Thanks!

10

Gasp! It's as if they were reading my mind. . . I'll have to keep an eye on that. Thanks!

we were polling arduino pins -1 and -2. those are the clairvoyant pins.

oops, I said too much already.

:wink: :wink:

seriously, this project was in the works for months now. here's an early physical proto I built:

Imgur

its been in use for a while and it was finally time to take it to a pc fab house for beta testing. we sent off an order for 20 boards and once the beta test crew is done and things are generally working for everyone, we'll send in a larger order for real production boards.

my friend will be hosting the e-sales on his existing site: AMB Laboratories (look for it by 'LCDuino').

cheers

/bryan

11

ill_switch,

Sorry, I wasn't paying attention. If you're already using I2C, you're absolutely right about just adding another slave being the easiest way.

Regards,

-Mike