From: Joe Buehl <joe.buehl@buehltech.com>
To: lm-sensors@vger.kernel.org
Subject: [lm-sensors] Support for non-register devices
Date: Wed, 06 Mar 2013 22:02:41 +0000 [thread overview]
Message-ID: <5137BD01.6080905@buehltech.com> (raw)
I am new to using I2C so apologies if this has already been addressed
before.
In trying to communicate with a Honeywell HIH-6130 humidity sensor from
a RaspberryPi I ran into an apparent limitation of i2c-tools. There
doesn't seem to be support for reading multiple bytes of data from a
device that doesn't need a register selected before the read. This
device is accessed by first doing a write of just the address, followed
about 37ms later by a read of 4 bytes, as documented here
http://www.phanderson.com/arduino/I2CCommunications.pdf. The write
operation can be done by using write_quick(), and a subsequent
read_byte() will get the first byte of data, but multiple calls to
read_byte() will just get the same first byte again. Using
read_i2c_block_data() works better, however, because it sends an
unneeded command byte, I'm not sure the data returned is valid. There is
a long discussion of the details in this thread
http://www.raspberrypi.org/phpBB3/viewtopic.php?f2&t)454.
It seems to me that what is needed is a way to optionally specify that
no command byte should be sent in read_i2c_block_data() and
write_i2c_block_data(). While this is not compliant with the SMBus
protocol, this device doesn't claim to be compliant, and the purpose of
these two functions seems to be to allow such communications. I don't
believe this particular device is unique so there should be other cases
where this is useful.
I looked at the python wrapper code in smbusmodule.c and it looks easy
enough to implement something like specifying a value of None for the
cmd argument to indicate that no command byte should be sent, but
implementation of the behavior seems to be buried somewhere deep in
i2c-dev.c or i2c-core.c and I haven't been able to find it. I see that
there is work being done in this project to clean up these drivers, so I
wanted to propose this change, and also offer my help.
_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
next reply other threads:[~2013-03-06 22:02 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-03-06 22:02 Joe Buehl [this message]
[not found] ` <5137BD01.6080905-NG4YQ/0yFAu1Z/+hSey0Gg@public.gmane.org>
2013-03-06 22:21 ` [lm-sensors] Support for non-register devices Guenter Roeck
2013-03-06 22:21 ` Guenter Roeck
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5137BD01.6080905@buehltech.com \
--to=joe.buehl@buehltech.com \
--cc=lm-sensors@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.