Hardware Reference
In-Depth Information
This is our shift register's address in hex. This indicates that you have successfully detected an I2C device on the
bus. If you don't get this far, go back and check your connections. More than likely you have something wrong and
I would suggest checking the address pins. You'll notice that the first three addresses are not present on the output of
the
i2cdetect
utility. This is because they are part of the reserved address space according to the I2C specification.
Now that you have found something what should you do? Simply probe it! You want to see if your I2C device can
communicate back with the bus correctly before you try and use it at a software level. This is where our good friend
i2cset
comes into play. You can use the
i2cset
command to send a simple write command to the device you found.
Let's do that now. Run the following command:
# i2cset 0 0x38 255
Does this make sense? Unlikely, so let me explain the command.
•
First up we have the tool
i2cset
; its main function in life is to set an I2C register.
The first option to this command is
•
0
, which indicates the bus: in your case
/dev/i2c-0
is
specified as bus
0
. If your device was detected on a different bus in the previous step, change
this value to the value you found your device at. This should be 0 or 1.
•
You have the bus, so the next part of the string is the address in hex of the device. The output of
i2cdetect
makes this part very easy. Find the two-digit number and prefix it with
0x
. So
38
on
the table would be expressed as
0x38
.
•
The last part of this command writes the byte value of 255 to the I2C device. This value of
255 is not super important: it's just a random register on the device. You could use 254 and it
would work just as well. You are just testing the communication between the master and slave.
Now let's run the command and see what happens. If the I2C device is responding correctly you should get
nothing back from the command. If something is wrong you will get some form of error. The most common error
will be “Write failed”. If you do get this error, check that you turned on the LCD and the shift register. Don't laugh;
it happens a lot, just like not turning on your soldering iron. So in Figure
4-18
you can see that the
i2cset
tool has
successfully ran and we got no response. No response means no error, so it's all good.
Figure 4-18.
The i2cset tool as run successfully
If this tool gives you any error back, you have a problem. Go back and check your connections again. Keep trying
until this tool gives no feedback. Now that you have confirmed you can communicate without error to your I2C slave
device it's time you did something with it.
Software and LCD Clients
lcdproc
is a client/server application. You can find it by going to
http://lcdproc.org
.
One of the main reasons
I selected
lcdproc
is that it supports a wide range of displays connected in many different methods. This is important
as you are making use of the I2C bus to connect the LCD rather than the more common parallel port or USB methods.
Don't be too concerned about the project's slow release cycle; there are not many changes in the character LCD
