All of lore.kernel.org
 help / color / mirror / Atom feed
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

             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.