cyberz.org » Linux

Some applications using I2C

andrea — Mon, 08 Jun 2009 21:49:43 +0000

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. The USB bus seems to be very appealing but it has the drawback of complexity while the I²C bus 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 used inside the pc, so somewhere on the motherboard there is a I²C bus, but yet I haven’t found any decent connection to the external world to use it – no, i won’t solder things on memory modules). Since the first way to start experimenting with I²C is building an I²C port, I’ve built a parport-to-i²c interface implementing the I²C schematic made by Kosma Moczek with the idea of replacing it with a more modern USB-to-I²C solution in the future.

So here it is the prototype of the parport to I²C interface:

To test the interface bus, some I²C device was needed. A common 24c04 eeprom was very easy to find, so I just setup some wires 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 I²C 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 0×50-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 June 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 correcly blinking showing the binary representation of the bytes sent by the counter script.

Nagios nrpe and sudo: “NRPE: Unable to read output”

andrea — Sat, 03 Jan 2009 18:21:21 +0000

On CentOS 5 (and RedHat EL as well), you can encounter the following behaviour when configuring an nrpe plugin with sudo:
[andrea@feyd ~]$ /usr/lib/nagios/plugins/check_nrpe -H 1.2.3.4 -c check_md_raid NRPE: Unable to read output

Given that check_md_raid is defined as follows, in nrpe.conf:
command[check_md_raid]=sudo /usr/local/bin/nagios_check_md_raid
And given (for completeness) its relative /etc/sudoers line as follows:
nagios ALL=(ALL) NOPASSWD:/usr/local/bin/nagios_check_md_raid
Then the problem is in the requiretty options in /etc/sudoers, enabled by default on CentOS. Simply comment it as follows:
#Defaults requiretty
After that the plugin should work as expected:
[andrea@feyd ~]$ /usr/lib/nagios/plugins/check_nrpe -H 1.2.3.4 -c check_md_raid RAID OK: All arrays OK [1 array checked]

Using samba with autofs on Fedora 9

andrea — Sun, 07 Sep 2008 14:55:54 +0000

Mount a samba share on the fly without having it mounted statically at boot via the /etc/fstab file can bring you the advantage of an unpainful boot in case of unavailability of the samba server like in the following common scenarios:

laptop: you mount your pc share at home, but when you move it becomes unavailable
workstation: you mount the share of your workmate – but when he/she goes on holiday his/her workstation stays off

Using autofs this can be accomplished easily following these steps:

Set /auto under the control of autofs adding this line to /etc/auto.master:

/auto /etc/auto.auto --timeout=5 --ghost
Point directory to a samba share //server/share in /etc/auto.auto:

directory -fstype=cifs,credentials=/etc/smb.auth ://server/share (directory is a child directory of /auto)
Store access credentials to the samba share in /etc/smb.auth:

username=yourusername password=youpassword
Secure the password file:

# chmod 600 /etc/smb.auth
Start autofs:

# /etc/init.d/autofs start Starting automount: [ OK ]

MusicBrainz not working with Amarok on Fedora 8

andrea — Sun, 13 Apr 2008 10:14:05 +0000

On my Fedora 8 system with Amarok I was trying to fill an mp3′s tag header using MusicBrainz, getting the following error:

Tunepimp (MusicBrainz tagging library) returned the following error: "Fingerprinting of .mp3 files is not supported."

To make it work, just yum install libtunepimp-extras-nonfree

SSH X11 forwarding issue

andrea — Sat, 12 Apr 2008 21:38:53 +0000

Recently I’ve been in an awkward situation with ssh and X11 forwarding, where ssh using the classic -Y (or -X) switch wasn’t working (DISPLAY was not set):

[andrea@duncan ~]$ ssh -Y root@thufir root@thufir's password: Last login: Sat Apr 12 23:30:09 2008 from *** [root@thufir ~]# echo $DISPLAY [root@thufir ~]#

If you are experiencing the same and your sshd_config looks fine (which means TCP and X11 forwarding is already enabled) then the answer is missing xauth!

On RedHat yum install xauth will do the trick