Some applications using I²C
Parallel and serial ports are disappearing from today’s pc making life harder for the people who wants to connect their home-made devices to a pc.
Some time ago I was considering USB, but it's really quite complex, so I looked over it. The I2C bus instead is very easy to implement and it’s widely supported by many devices, with the drawback of no direct pc connection (to be honest it’s commonly used nowadays by motherboards to chit-chat with DIMMS, but yet I haven’t found any decent connection to the external world to use it and - no - i won’t solder cables on memory modules).
Since the first way to start experimenting with I2C is building an I2C port, I’ve built a parport-to-i2c interface implementing the I2C schematic made by Kosma Moczek with the idea of replacing it with a more modern USB-to-I2C solution in the future.
So here it is the prototype of the parport to I2C interface:
To test the interface bus, some I2C device was needed. I had around some 24c04 eeprom, so I just setup some wirings to have the 24c04 connect the bus (note the power cord powers up the parport board too). That is the result:
Using the i2cdetect from lmsensors with the 24c04 unplugged, I was able to scan the I2C bus without results as expected:
[root@thufir ~]# i2cdetect -a 3
WARNING! This program can confuse your I2C bus, cause data loss and worse!
I will probe file /dev/i2c-3.
I will probe address range 0x00-0x7f.
Continue? [Y/n] y
0 1 2 3 4 5 6 7 8 9 a b c d e f
00: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
70: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
[root@thufir ~]#
Plugging the 24c04 eeprom in the i2c bus, a probe finds out something:
[root@thufir ~]# i2cdetect -a 3
WARNING! This program can confuse your I2C bus, cause data loss and worse!
I will probe file /dev/i2c-3.
I will probe address range 0x00-0x7f.
Continue? [Y/n] y
0 1 2 3 4 5 6 7 8 9 a b c d e f
00: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
50: 50 51 -- -- -- -- -- -- -- -- -- -- -- -- -- --
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
70: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
[root@thufir ~]#
The eeprom has been found at 0x50-1 address, which is as expected (the 24c04 has the ‘1010 E2 E1 A8’ address scheme, so in my case E2 and E1 were ground producing 1010000 and 1010001).
To be sure about the functionality of the port, I used the eeprog program by Stefano Barbato to test the 24c04.
Writing “hello world\n” on the first 12 bytes of the eeprom was fine:
[root@thufir eeprog-0.7.6]# echo hello world | ./eeprog -f /dev/i2c-3 0x50 -w 0:12
eeprog 0.7.6, a 24Cxx EEPROM reader/writer
Copyright (c) 2003-2004 by Stefano Barbato - All rights reserved.
Bus: /dev/i2c-3, Address: 0x50, Mode: 8bit
Writing stdin starting at address 0x0
............
…and so was reading what’s inside the first 12 bytes of the eeprom (the “hello world\n” string which we have just written).
[root@thufir eeprog-0.7.6]# ./eeprog -f /dev/i2c-3 0x50 -r 0:12
eeprog 0.7.6, a 24Cxx EEPROM reader/writer
Copyright (c) 2003-2004 by Stefano Barbato - All rights reserved.
Bus: /dev/i2c-3, Address: 0x50, Mode: 8bit
Reading 12 bytes from 0x0
hello world
[root@thufir eeprog-0.7.6]#
The i2c eeprom is working as expected. The eeprom was connected with a 3 meters cable. As of today I still have to buy some PCF8574 to start experimenting with some other circuits.
Update 26 Jun 2010
I bought some PCF8574 but unfortunately I lost my I2C parport adapter, so I had to build a new one from scratch. This time I managed to fit it into the parallel cable box and I used a mini molex connector to have a common connection for all the I2C boards I plan to build.
Since my purpose is to use I2C for domotics, cable length is very important. On the internet you may see that maximum length for I2C connections may vary depending on how many devices you connect and cable length, I was able to manage some tests with the 24c04 eeprom and everything worked fine with a 13 meters cable.
Then I assembled a test circuit for PCF8574 to test the bus with 2 devices connected (again with 13 meters cable). The PCF8574 board features a dip switch to select the address and 4 LED/bit connected to the lsb data output (in this case I was not interested in using the chip as an input).
The whole thing worked fine (with both 24C04 and PCF8574 connected), as shown by i2cdetect:
[root@kynes ~]# i2cdetect -a 1
WARNING! This program can confuse your I2C bus, cause data loss and worse!
I will probe file /dev/i2c-1.
I will probe address range 0x00-0x7f.
Continue? [Y/n] y
0 1 2 3 4 5 6 7 8 9 a b c d e f
00: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
20: -- -- -- -- -- -- -- 27 -- -- -- -- -- -- -- --
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
50: 50 51 -- -- -- -- -- -- -- -- -- -- -- -- -- --
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
70: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
[root@kynes ~]#
To check the PCF8574, the following “counter” script was executed:
A=0; while :; do ((A=A+1)); printf "%b", $A > /sys/bus/i2c/devices/1-0027/write; echo Wrote $A; sleep 1; done
Leds were correctly blinking showing the binary representation of the bytes sent by the counter script.