trouble with BBB and I2C temperature sensor (HIH 6130)

[Josh Hill]

Hi everyone, I just got my BBB and I wanted to get temp/humidity so I got a HIH6130. I have a good amount of experience with OOP and HDLs, so I can read code and I also understand the low level stuff working directly with bits, however I have zero experience with I2C and I have no idea how to use it.


I read a lot of other simple I2C programs, one example being http://beagleboard.org/Support/BoneScript/demo_bmp085/
I modified the code to match the address of the HIH6130 and the two functions given by the kernel driver (https://www.kernel.org/doc/Documentation/hwmon/hih6130)

var b = require('bonescript');
var iic = '/sys/class/i2c-adapter/i2c-1/';

//Sensor Locations on the BeagleBone Black
var temperature = '/sys/bus/i2c/drivers/hih6130/1-0027/temp1_input';
var humidity = '/sys/bus/i2c/drivers/hih6130/1-0027/humidity1_input';

// We will initialize the driver for the BMP085 sensor located at I2C location 0x77
b.writeTextFile(iic + 'new_device', 'hih6130 0x27');

// Opens,reads, and prints humidity and temperature
b.readTextFile(humidity, printHumidity);
b.readTextFile(temperature, printTemperature);

// Prints humidity
function printHumidity(x) {
   console.log("humidity: ", x.data/100 + " %");
}

// Prints Temperature
function printTemperature(x) {
   // '\xB0' is the degree symbol in hexademical
   console.log("Temperature: ", x.data/10 + '\xB0' + " Celcius");
   x.data /= 10;
   x.data *= 1.8;
   x.data += 32;
   console.log("or: ", x.data + '\xB0' + " Fahrenheit");
}

I didn't really care about the math behind the information so I left it alone. When the above code is run I get NaN for everything. I'm assuming because it is literally trying to read the "temp1_input" and just dump that to the screen. However...

root@beaglebone:/sys/class/i2c-adapter/i2c-1/1-0027# cat temp1_input
cat: temp1_input: Invalid argument

nothing is there.

According to the datasheet (http://www.phanderson.com/arduino/I2CCommunications.pdf) It says the device is sleeping and needs to be sent a "measurement request" command in the form of [6bit address][0].
My main problem is I'm not sure how to send data directly to the bus. I was thinking about using the i2cset command, but that doesn't seem right as it sets a specific address of memory on a specific device. According to the datasheet I'm not trying to send it data other then the address + a '0' but the other i2c tools don't seem to be any more help.

Last, here's an i2c dump of the device.

root@beaglebone:/sys/class/i2c-adapter/i2c-1# i2cdump 1 0x27
No size specified (using byte-data access)
WARNING! This program can confuse your I2C bus, cause data loss and worse!
I will probe file /dev/i2c-1, address 0x27, mode byte
Continue? [Y/n] y
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f    0123456789abcdef
00: 5e 5e 5e 5e 5e 5e 5e 5e 5e 5e 5e 5e 5e 5e 5e 5e    ^^^^^^^^^^^^^^^^
10: 5e 5e 5e 5e 5e 5e 5e 5e 5e 5e 5e 5e 5e 5e 5e 5e    ^^^^^^^^^^^^^^^^
20: 5e 5e 5e 5e 5e 5e 5e 5e 5e 5e 5e 17 57 57 57 57    ^^^^^^^^^^^?WWWW
30: 57 57 57 57 57 57 57 57 57 57 57 57 57 57 57 57    WWWWWWWWWWWWWWWW
40: 57 57 57 57 57 57 57 57 57 57 57 57 57 57 57 57    WWWWWWWWWWWWWWWW
50: 57 57 57 57 57 57 57 17 57 57 57 57 57 57 57 57    WWWWWWW?WWWWWWWW
60: 57 57 57 57 57 57 57 57 57 57 57 57 57 57 57 57    WWWWWWWWWWWWWWWW
70: 57 57 57 57 57 57 57 57 57 57 57 57 57 57 57 57    WWWWWWWWWWWWWWWW
80: 57 57 57 17 57 57 57 57 57 57 57 57 57 57 57 57    WWW?WWWWWWWWWWWW
90: 57 57 57 57 57 57 57 57 57 57 57 57 57 57 57 57    WWWWWWWWWWWWWWWW
a0: 57 57 57 57 57 57 57 57 57 57 57 57 57 57 57 17    WWWWWWWWWWWWWWW?
b0: 57 57 57 57 57 57 57 57 57 57 57 57 57 57 57 57    WWWWWWWWWWWWWWWW
c0: 57 57 57 57 57 57 57 57 57 57 57 57 57 57 57 57    WWWWWWWWWWWWWWWW
d0: 57 57 57 57 57 57 57 57 57 57 57 57 57 57 57 57    WWWWWWWWWWWWWWWW
e0: 57 57 57 57 57 57 57 57 57 57 57 57 57 57 57 57    WWWWWWWWWWWWWWWW
f0: 57 57 57 57 57 57 57 57 57 57 57 57 57 57 57 57    WWWWWWWWWWWWWWWW

I wouldn't call it "garbage data" per se, however it isn't very useful.

If anyone has experience with the HIH6130 or really any pointers on how to send specific bytes directly to the I2C bus would be great.

Thanks a lot!

[ky...@cranehome.info]

You may be in a bit of a bind.  The Linux kernel drivers for I2C don't really give you a function for this that I have seen.  Specifically to write the "WRITE" address of the device to the bus and then immediately terminate the transaction.  You could see if it will respond with something interesting if you try to write a dummy value to it first instead of just the device address.   It may ignore the other data bits after it's "WRITE" address and just wait patiently for the "STOP" condition to occur.   If so then it should wake up and perform a measurement.  Kind of ugly but it might work.  If it freaks out because another byte follows the address after it ACKs then you may be a bit stuck without getting your feet wet in writing some more capable I2C drivers.  

I need to watch the output of i2cdetect sometime and see what it does and how it does it.   This is almost the mirror image of the type of 'ping' it's doing using the write address instead of the read address.  I always detected devices on micro-controllers by iterating through the "READ" address space, "START" the bus, write the "READ" address to the bus and detecting the ACK then "STOP", increment address and repeat.  In micro-controller world it would be easy enough to do that for a write as well but it's more complicated in Linux Kernel land.

Afraid I don't bonescript though, so I don't know much about I2C functions available for that or how to code them.

I imagine on the basis of the data sheet that the result of i2cdump is just gibberish.  The normal sequence to get register data (which this device doesn't appear to even have) would be:

START

Write the WRITE address to bus, followed by register address as data.

REPEATED START or perhaps STOP | START

Write the READ address to the bus and data bytes that follow until NACK.

STOP

Looking at the datasheet the best you might be getting is the first byte of humidity data and status bits repeated.  Usually a total failure to respond at all is FF so I think it's at least trying to speak with you.

[Josh Hill]

Ok. So what I'm gathering is that the Linux Kernel drivers don't allow for direct manipulation of the I2C data bus.
So can I simulate my own? Use two of the GPIOs and have one be a clock and one be a data line?

Is that feasible?
Can a GPIO operate at 100kHz?
If not can I2C devices operate at clocks of lower frequencies? (would 50kHz work? 10kHz?)
Would the I2C device care? Or would it just be happy receiving a clock and spitting out data?

I already know the device's address, and that cannot change so that would just be a static 7 bits I'm sending over the "data" line add on my 0 for "make measurement" then just listen for one bit at each clock edge, when I get 8 bits, send a ACK and continue.

Shouldn't that work just fine outside of the real I2C bus?

[Roy Bellingan]

I normally use the i2c without any problem...

You can play with the onboard i2c0, enable it and just do http://linux.die.net/man/8/i2cdetect
Or connect something on the other bus and do the same...

The code I use i the following

#include <stdio.h>                                                                                                                          
#include <stdlib.h>                                                                                                                         
#include <linux/i2c-dev.h>                                                                                                                  
#include <fcntl.h>                                                                                                                          
#include <string.h>                                                                                                                         
#include <sys/ioctl.h>                                                                                                                      
#include <sys/types.h>                                                                                                                      
#include <sys/stat.h>                                                                                                                       
#include <unistd.h>                                                                                                                         
                                                                                                                                            
int main(int argc, char **argv)                                                                                                             
{                                                                                                                                           
        printf("**** test program ****,\n");                                                                                          
        int fd;                                                                                                         // File descrition
        char *fileName = "/dev/i2c-1";                                                          // Name of the port we will be using
        int  address = 0x48;                                                                            // Address of TPA81 shifted right 1 bit
        unsigned char buf[10];  // Buffer for data being read/ written on the i2c bus
        int tempreg;
        float temperature;

        printf(" address is %i \n", address);


        if ((fd = open(fileName, O_RDWR)) < 0) {                                        // Open port for reading and writing
                printf("Failed to open i2c port\n");
                exit(1);
        }

        if (ioctl(fd, I2C_SLAVE, address) < 0) {                                        // Set the port options and set the address of the device we wish to speak to
                printf("Unable to get bus access to talk to slave\n");
                exit(1);
        }


        buf[0] = 0x01;                                                                  
        buf[1] = 0x60;

        if ((write(fd, buf, 2)) != 2) {                                                         // Write data to a register (meaning the desidered resolution
                printf("Error writing to i2c slave 1 \n");
                exit(1);
        }

                                                                                                                
        buf[0] = 0x00;
        if ((write(fd, buf, 1)) != 1) {                                                         // Send register to read from
                printf("Error writing to i2c slave 2\n");
                exit(1);
        }
       

        while (1){
          if (read(fd, buf, 2) != 2) {                                                          // Read back data into buf[]
                  printf("Unable to read from slave 4 \n");
                  exit(1);
          }
          else {
                 
                  tempreg = buf[0];
                  tempreg = tempreg << 8;
                  tempreg |= buf[1];
                  tempreg = tempreg >> 4;
                  temperature = (float)tempreg / 16; 
                  printf("Ambient temperature: %f \n",temperature);

          }
          usleep(350000);
        }
        return 0;
}

[garyamort]

On Thursday, August 29, 2013 2:21:11 PM UTC-4, ky...@cranehome.info wrote:

You may be in a bit of a bind.  The Linux kernel drivers for I2C don't really give you a function for this that I have seen. 

 Specifically to write the "WRITE" address of the device to the bus and then immediately terminate the transaction.  You could see if it will respond with something interesting if you try to write a dummy value to it first instead of just the device address.  

When I was cut/pasting commands and making changes to adjust the power LED, I fumbled a few times and ran command like

i2cset -f -y 0 0x24 0x0B

Where I left off the DATA to be sent and just had the register address.  i2cset didn't complain and was perfectly happy to try to write without sending data[and a quick look at the underlying code, http://lxr.free-electrons.com/source/drivers/i2c/i2c-core.c#L1956 it doesn't seem to care at all if the value is null.

As such, I'd say give a try writing to register 0 with no data, ie

i2cset -f -y 1 0x27 0x00

 

Don't forget to include the -f!  i2cset is configured not to write to any i2c addresses if there is another driver configured for that device!

[garyamort]

On Wednesday, August 28, 2013 10:57:14 PM UTC-4, Josh Hill wrote:

Last, here's an i2c dump of the device.

root@beaglebone:/sys/class/i2c-adapter/i2c-1# i2cdump 1 0x27

Note: this command does not always give the correct data if your running it against a device where linux already has a driver loaded.  Depending on the device, sometimes it looked like it work but I got the wrong data, and sometimes it fails outright.  I had to add the force flag in order to get data which looks right, for example to dump the board id from the eeprom:

root@ubuntu-armhf:/home/ubuntu# i2cdump -y 0 0x50

No size specified (using byte-data access)

Error: Could not set address to 0x50: Device or resource busy
root@ubuntu-armhf:/home/ubuntu# i2cdump -f -y 0 0x50

No size specified (using byte-data access)

     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f    0123456789abcdef

00: 55 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff    U...............
10: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff    ................
20: 55 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff    U...............
30: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff    ................
40: 55 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff    U...............
50: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff    ................
60: 55 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff    U...............
70: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff    ................
80: 55 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff    U...............
90: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff    ................
a0: 55 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff    U...............
b0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff    ................
c0: 55 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff    U...............
d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff    ................
e0: 55 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff    U...............
f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff    ................

[ky...@cranehome.info]

The Linux generic /dev/i2c-X device driver can do everything you need to do except send just the address and no other data as far as I can tell.  All the functions that I have worked with appear to expect data to be sent to a device you are going to write to.  I think the command line suggestions by garyamort are not going to send exactly the wake-up that the sensor documents and would instead send:

(Note: 4E is the actual write address that is sent to the bus after the driver shifts 0x27 left one bit and leaves the trailing bit at 0 for a write)

START | 0x4E | 0x00 | STOP

where you want:

START | 0x4E | STOP

You might see if you can write a program that just uses the Linux device file that will work.  See this page:

http://elinux.org/Interfacing_with_I2C_Devices

So try the write example but change the number of bytes to write to zero and see if that works for you then when you turn around and read.  I would also test and see if you send a dummy data byte after the write address and have it still work.  It may not be that picky.

Yes, you can always bit-bang an I2C bus and there is code out there in C/C++ to do that you could adapt.  If you don't have access to a logic analyzer you're probably looking at a lot of work to get there and debug.  Hopefully something above works for you and you don't have to reinvent the wheel to wake the silly thing up.

There are a few libraries showing up now that use memory mapped access to GPIO that can reach far beyond 100KHz on GPIO.  Even a decently well implemented SYSFS interface to GPIO can likely get close to 100KHz doing some real work in between.   I2C can operate at any frequency at or below the maximum speed of the slowest device on the bus.  So if your device can operate at 100KHz it can most likely also operate at 10KHz or 1KHz.  Some devices do have a floor so check the datasheet carefully.

[Josh Hill]

I just came home from my parents place in Ohio, and of course I left the Beagle Bone there, so I can't test out anything right now.
But, I do know that I already did try an i2cset command using 0x4E (0100 1110) as the address with no data and I got an invalid address error. Which I ignored because I assumed the linux kernel was expecting some sort of reply from that address when, in-fact, it would have just woken up the device on 0x27 (assuming it worked).

I did an i2cdump on 0x27 before and after the i2cset 0x4E and the numbers were different. However the output was exactly like the output I showed in the first post.

One last piece of information that I can add is this. I also assumed the i2cdump data was valid. Taking the first 4 bytes and applying the logic in the data sheet. For example the first 4 bytes in my first post is 5E 5E 5E 5E. The datasheet says the first 2 bits are status, and the last 2 bits are don't care's. Some quick math says the Humidity is 0x1E5E and the Temp is 0x1797. Converting to decimal and doing the math in the datasheet yields a measurement of 47.4% humidity and 20.89 degrees C. Those seem to be fairly valid results, however when I did the same thing again a few minutes later I got results that were closer to 25 degrees C. I had a thermometer sitting next to me, the first measurement was almost a full degree off, which I thought was good enough, the ambient temp didn't change between the measurements, making the 2nd measurement WAY off.

Also I'm not sure of the validity of the data since in the i2cdump since it is repeated so much.
Last point of concern is that to read the device I need to append a 1 to the device address.
So, 0x27 = 0010 0111 (device), 0x4E = 0100 1110 (bit shift left one, device wake up, and take measurement), 0x4F = 0100 1111 (read bit)
Is the linux kernel doing that last bit on it's own? Or is that the problem here, the i2cdump command isn't sending out the proper "Read flag" or "0x4F address" and thus I'm not able to get the 4 bytes because the device isn't actually communicating?

[Josh Hill]

Some new developments:

I got the source code for the linux driver for the HIH6130

/* Honeywell HIH-6130/HIH-6131 humidity and temperature sensor driver
 *
 * Copyright (C) 2012 Iain Paton <ipa...@gmail.com>
 *
 * heavily based on the sht21 driver
 * Copyright (C) 2010 Urs Fleisch <urs.f...@sensirion.com>
 *
 * This program is free software; you can redistribute it and/or modify
 * it under the terms of the GNU General Public License as published by
 * the Free Software Foundation; either version 2 of the License, or
 * (at your option) any later version.
 *
 * This program is distributed in the hope that it will be useful,
 * but WITHOUT ANY WARRANTY; without even the implied warranty of
 * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
 * GNU General Public License for more details.
 *
 * You should have received a copy of the GNU General Public License
 * along with this program; if not, write to the Free Software
 * Foundation, Inc., 51 Franklin St - Fifth Floor, Boston, MA 02110-1301 USA
 *
 * Data sheets available (2012-06-22) at
 * http://sensing.honeywell.com/index.php?ci_id=3106&la_id=1&defId=44872
 */

#include <linux/module.h>
#include <linux/init.h>
#include <linux/slab.h>
#include <linux/i2c.h>
#include <linux/hwmon.h>
#include <linux/hwmon-sysfs.h>
#include <linux/err.h>
#include <linux/mutex.h>
#include <linux/device.h>
#include <linux/delay.h>
#include <linux/jiffies.h>

/**
 * struct hih6130 - HIH-6130 device specific data
 * @hwmon_dev: device registered with hwmon
 * @lock: mutex to protect measurement values
 * @valid: only false before first measurement is taken
 * @last_update: time of last update (jiffies)
 * @temperature: cached temperature measurement value
 * @humidity: cached humidity measurement value
 */
struct hih6130 {
    struct device *hwmon_dev;
    struct mutex lock;
    bool valid;
    unsigned long last_update;
    int temperature;
    int humidity;
};

/**
 * hih6130_temp_ticks_to_millicelsius() - convert raw temperature ticks to
 * milli celsius
 * @ticks: temperature ticks value received from sensor
 */
static inline int hih6130_temp_ticks_to_millicelsius(int ticks)
{

    ticks = ticks >> 2;
    /*
     * from data sheet section 5.0
     * Formula T = ( ticks / ( 2^14 - 2 ) ) * 165 -40
     */
    return (DIV_ROUND_CLOSEST(ticks * 1650, 16382) - 400) * 100;
}

/**
 * hih6130_rh_ticks_to_per_cent_mille() - convert raw humidity ticks to
 * one-thousandths of a percent relative humidity
 * @ticks: humidity ticks value received from sensor
 */
static inline int hih6130_rh_ticks_to_per_cent_mille(int ticks)
{

    ticks &= ~0xC000; /* clear status bits */
    /*
     * from data sheet section 4.0
     * Formula RH = ( ticks / ( 2^14 -2 ) ) * 100
     */
    return DIV_ROUND_CLOSEST(ticks * 1000, 16382) * 100;
}

/**
 * hih6130_update_measurements() - get updated measurements from device
 * @client: I2C client device
 *
 * Returns 0 on success, else negative errno.
 */
static int hih6130_update_measurements(struct i2c_client *client)
{
    int ret = 0;
    int t;
    struct hih6130 *hih6130 = i2c_get_clientdata(client);
    unsigned char tmp[4];
    struct i2c_msg msgs[1] = {
        {
            .addr = client->addr,
            .flags = I2C_M_RD,
            .len = 4,
            .buf = tmp,
        }
    };

    mutex_lock(&hih6130->lock);

    /*
     * While the measurement can be completed in ~40ms the sensor takes
     * much longer to react to a change in external conditions. How quickly
     * it reacts depends on airflow and other factors outwith our control.
     * The datasheet specifies maximum 'Response time' for humidity at 8s
     * and temperature at 30s under specified conditions.
     * We therefore choose to only read the sensor at most once per second.
     * This trades off pointless activity polling the sensor much faster
     * than it can react against better response times in conditions more
     * favourable than specified in the datasheet.
     */
    if (time_after(jiffies, hih6130->last_update + HZ) || !hih6130->valid) {

        /* write to slave address, no data, to request a measurement */
        ret = i2c_master_send(client, tmp, 0);
        if (ret < 0)
            goto out;

        /* measurement cycle time is ~36.65msec */
        msleep(40);

        ret = i2c_transfer(client->adapter, msgs, 1);
        if (ret < 0)
            goto out;

        if ((tmp[0] & 0xC0) != 0) {
            dev_err(&client->dev, "Error while reading measurement result\n");
            ret = -EIO;
            goto out;
        }

        t = (tmp[0] << 8) + tmp[1];
        hih6130->humidity = hih6130_rh_ticks_to_per_cent_mille(t);

        t = (tmp[2] << 8) + tmp[3];
        hih6130->temperature = hih6130_temp_ticks_to_millicelsius(t);

        hih6130->last_update = jiffies;
        hih6130->valid = true;
    }
out:
    mutex_unlock(&hih6130->lock);

    return ret >= 0 ? 0 : ret;
}

/**
 * hih6130_show_temperature() - show temperature measurement value in sysfs
 * @dev: device
 * @attr: device attribute
 * @buf: sysfs buffer (PAGE_SIZE) where measurement values are written to
 *
 * Will be called on read access to temp1_input sysfs attribute.
 * Returns number of bytes written into buffer, negative errno on error.
 */
static ssize_t hih6130_show_temperature(struct device *dev,
                    struct device_attribute *attr,
                    char *buf)
{
    struct i2c_client *client = to_i2c_client(dev);
    struct hih6130 *hih6130 = i2c_get_clientdata(client);
    int ret = hih6130_update_measurements(client);
    if (ret < 0)
        return ret;
    return sprintf(buf, "%d\n", hih6130->temperature);
}

/**
 * hih6130_show_humidity() - show humidity measurement value in sysfs
 * @dev: device
 * @attr: device attribute
 * @buf: sysfs buffer (PAGE_SIZE) where measurement values are written to
 *
 * Will be called on read access to humidity1_input sysfs attribute.
 * Returns number of bytes written into buffer, negative errno on error.
 */
static ssize_t hih6130_show_humidity(struct device *dev,
                     struct device_attribute *attr, char *buf)
{
    struct i2c_client *client = to_i2c_client(dev);
    struct hih6130 *hih6130 = i2c_get_clientdata(client);
    int ret = hih6130_update_measurements(client);
    if (ret < 0)
        return ret;
    return sprintf(buf, "%d\n", hih6130->humidity);
}

/* sysfs attributes */
static SENSOR_DEVICE_ATTR(temp1_input, S_IRUGO, hih6130_show_temperature,
    NULL, 0);
static SENSOR_DEVICE_ATTR(humidity1_input, S_IRUGO, hih6130_show_humidity,
    NULL, 0);

static struct attribute *hih6130_attributes[] = {
    &sensor_dev_attr_temp1_input.dev_attr.attr,
    &sensor_dev_attr_humidity1_input.dev_attr.attr,
    NULL
};

static const struct attribute_group hih6130_attr_group = {
    .attrs = hih6130_attributes,
};

/**
 * hih6130_probe() - probe device
 * @client: I2C client device
 * @id: device ID
 *
 * Called by the I2C core when an entry in the ID table matches a
 * device's name.
 * Returns 0 on success.
 */
static int hih6130_probe(struct i2c_client *client,
                   const struct i2c_device_id *id)
{
    struct hih6130 *hih6130;
    int err;

    if (!i2c_check_functionality(client->adapter, I2C_FUNC_I2C)) {
        dev_err(&client->dev, "adapter does not support true I2C\n");
        return -ENODEV;
    }

    hih6130 = devm_kzalloc(&client->dev, sizeof(*hih6130), GFP_KERNEL);
    if (!hih6130)
        return -ENOMEM;

    i2c_set_clientdata(client, hih6130);

    mutex_init(&hih6130->lock);

    err = sysfs_create_group(&client->dev.kobj, &hih6130_attr_group);
    if (err) {
        dev_dbg(&client->dev, "could not create sysfs files\n");
        return err;
    }

    hih6130->hwmon_dev = hwmon_device_register(&client->dev);
    if (IS_ERR(hih6130->hwmon_dev)) {
        dev_dbg(&client->dev, "unable to register hwmon device\n");
        err = PTR_ERR(hih6130->hwmon_dev);
        goto fail_remove_sysfs;
    }

    return 0;

fail_remove_sysfs:
    sysfs_remove_group(&client->dev.kobj, &hih6130_attr_group);
    return err;
}

/**
 * hih6130_remove() - remove device
 * @client: I2C client device
 */
static int hih6130_remove(struct i2c_client *client)
{
    struct hih6130 *hih6130 = i2c_get_clientdata(client);

    hwmon_device_unregister(hih6130->hwmon_dev);
    sysfs_remove_group(&client->dev.kobj, &hih6130_attr_group);

    return 0;
}

/* Device ID table */
static const struct i2c_device_id hih6130_id[] = {
    { "hih6130", 0 },
    { }
};
MODULE_DEVICE_TABLE(i2c, hih6130_id);

static struct i2c_driver hih6130_driver = {
    .driver.name = "hih6130",
    .probe       = hih6130_probe,
    .remove      = hih6130_remove,
    .id_table    = hih6130_id,
};

module_i2c_driver(hih6130_driver);

MODULE_AUTHOR("Iain Paton <ipa...@gmail.com>");
MODULE_DESCRIPTION("Honeywell HIH-6130 humidity and temperature sensor driver");
MODULE_LICENSE("GPL");

I see the methods I'm interested in..

Enter code here.../**
 * hih6130_show_temperature() - show temperature measurement value in sysfs
 * @dev: device
 * @attr: device attribute
 * @buf: sysfs buffer (PAGE_SIZE) where measurement values are written to
 *
 * Will be called on read access to temp1_input sysfs attribute.
 * Returns number of bytes written into buffer, negative errno on error.
 */
static ssize_t hih6130_show_temperature(struct device *dev,
                    struct device_attribute *attr,
                    char *buf)
{
    struct i2c_client *client = to_i2c_client(dev);
    struct hih6130 *hih6130 = i2c_get_clientdata(client);
    int ret = hih6130_update_measurements(client);
    if (ret < 0)
        return ret;
    return sprintf(buf, "%d\n", hih6130->temperature);
}

Will be called on read access to temp1_input sysfs attribute."
So my earlier attempt to cat the device SHOULD work, cat is a read command.
Infact, here is the output for the on board temperature sensor

root@beaglebone:/sys/class/hwmon/hwmon0/device# ls -lha
total 0
drwxr-xr-x  4 root root    0 Dec 31  1999 .
drwxr-xr-x 30 root root    0 Dec 31  1999 ..
lrwxrwxrwx  1 root root    0 Sep 10 15:34 driver -> ../../../bus/platform/drivers/am335x-bandgap
drwxr-xr-x  3 root root    0 Dec 31  1999 hwmon
-r--r--r--  1 root root 4.0K Sep 10 15:34 modalias
-r--r--r--  1 root root 4.0K Sep 10 15:34 name
drwxr-xr-x  2 root root    0 Sep 10 15:34 power
lrwxrwxrwx  1 root root    0 Dec 31  1999 subsystem -> ../../../bus/platform
-r--r--r--  1 root root 4.0K Sep 10 15:33 temp1_input
-rw-r--r--  1 root root 4.0K Dec 31  1999 uevent
root@beaglebone:/sys/class/hwmon/hwmon0/device# cat temp1_input
55000

So I'm thinking the idea is sound, however I don't get that kind of output

root@beaglebone:/sys/class/i2c-adapter/i2c-1/1-0027# ls -lha
total 0
drwxr-xr-x 4 root root    0 Sep 10 15:53 .
drwxr-xr-x 9 root root    0 Dec 31  1999 ..
lrwxrwxrwx 1 root root    0 Sep 10 15:53 driver -> ../../../../../bus/i2c/drivers/hih6130
-r--r--r-- 1 root root 4.0K Sep 10 15:53 humidity1_input
drwxr-xr-x 3 root root    0 Sep 10 15:53 hwmon
-r--r--r-- 1 root root 4.0K Sep 10 15:53 modalias
-r--r--r-- 1 root root 4.0K Sep 10 15:53 name
drwxr-xr-x 2 root root    0 Sep 10 15:53 power
lrwxrwxrwx 1 root root    0 Sep 10 15:53 subsystem -> ../../../../../bus/i2c
-r--r--r-- 1 root root 4.0K Sep 10 15:53 temp1_input
-rw-r--r-- 1 root root 4.0K Sep 10 15:53 uevent
root@beaglebone:/sys/class/i2c-adapter/i2c-1/1-0027# cat temp1_input
cat: temp1_input: Invalid argument

I really don't want to make my own I2C bus. The driver is there, it says how it works yet it does not.
Any Ideas?

[Roy Bellingan]

Find the sensor address and do a simple i2cget

i2get "bus number" "device address" "register address"

http://www.lm-sensors.org/wiki/man/i2cget

[Josh Hill]

root@beaglebone:/sys/class/i2c-adapter/i2c-1# i2cget -y 1 0x27 0
0x60
root@beaglebone:/sys/class/i2c-adapter/i2c-1# i2cdump -y 1 0x27

No size specified (using byte-data access)

     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f    0123456789abcdef

00: 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60    ````````````````
10: 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60    ````````````````
20: 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60    ````````````````
30: 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60    ````````````````
40: 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60    ````````````````
50: 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60    ````````````````
60: 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60    ````````````````
70: 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60    ````````````````
80: 60 60 60 20 60 60 60 60 60 60 60 60 60 60 60 60    ``` ````````````
90: 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60    ````````````````
a0: 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60    ````````````````
b0: 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60    ````````````````
c0: 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60    ````````````````
d0: 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60    ````````````````
e0: 60 60 20 60 60 60 60 60 60 60 60 60 60 60 60 60    `` `````````````
f0: 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60    ````````````````
root@beaglebone:/sys/class/i2c-adapter/i2c-1#

I don't think the device has registers, I could be wrong. Either way the above information isn't helpful.

[Roy Bellingan]

This an arduino code I've found
http://www.phanderson.com/arduino/hih6130.html

Reading the sensor doc I think you just have to "call" the sensor whitout the register, and after a small delay read the received data.

      address = 0x27;;
      Wire.beginTransmission(address); 
      Wire.endTransmission();
      delay(100);
      
      Wire.requestFrom((int)address, (int) 4);
      Hum_H = Wire.receive();
      Hum_L = Wire.receive();
      Temp_H = Wire.receive();
      Temp_L = Wire.receive();
      Wire.endTransmission();

I don't know how to replicate this behaviur in i2cget...

[Josh Hill]

Well, I started thinking the module was bad. (namely because the driver made for this exact device isn't working)
Last ditch effort I hooked it up to an arduino and copied the code on sparkfun's website.
Turns out it works, the humidity is off by ~10% (not usable with that much error) but the temperature was spot on.

So now I'm not sure what to do, I really don't want to design my own data bus, it's not in the scope of my project.

Last thoughts from anyone?
Different temperature sensor (something someone has experience with? I would like something more accurate then +/- 2C, which is why I opted away from an analog TMP36)
Or other ideas?

[Hunyue Yau]

On Wed September 11 2013 18:02:20 Josh Hill wrote:
> Well, I started thinking the module was bad. (namely because
> the driver made for this exact device isn't working)
> Last ditch effort I hooked it up to an arduino and copied the
> code on sparkfun's website.
> Turns out it works, the humidity is off by ~10% (not usable
> with that much error) but the temperature was spot on.

What are you using as a reference to determine it is 10% off?
Humidity is often not completely uniform.

>
> So now I'm not sure what to do, I really don't want to design
> my own data bus, it's not in the scope of my project.
>
> Last thoughts from anyone?
> Different temperature sensor (something someone has experience
> with? I would like something more accurate then +/- 2C, which
> is why I opted away from an analog TMP36)
> Or other ideas?
>

--
Hunyue Yau
http://www.hy-research.com/

[Josh Hill]

I am using a commercial temp/RH monitor. It's a simple little device, nothing special.
I ran the test again and it was closer to 5% different. So maybe the RH is accurate too and my standalone is off.

However, I was beginning to suspect the sensor was defective because the drivers made for it don't do anything.
I don't want to make my own clock and data signals with my own driver, and I don't want to plug an arduino into my BBB.

[garyamort]

On Tuesday, September 10, 2013 3:55:52 PM UTC-4, Josh Hill wrote:

Some new developments:

I got the source code for the linux driver for the HIH6130




Your problem might actually be in the ti driver.  As near as I can tell, this will call i2c_master_send in i2c-core.c

https://github.com/torvalds/linux/blob/master/drivers/i2c/i2c-core.c#L1775

 

There it will setup:

msg.addr = client->addr;
msg.flags = client->flags & I2C_M_TEN;
msg.len = count;
msg.buf = (char *)buf;

Where buf is  

[garyamort]

Sorry, posted too soon.

Where buf is a pointer to a 4 byte charector string[tmp from the original driver, which is an uninitialized 4 byte charector string, so it could contain anything!]

And count is 0 [length 0]

This goes to i2c_transfer in the same file:

https://github.com/torvalds/linux/blob/master/drivers/i2c/i2c-core.c#L1716

Which just bumps it along to __i2c_transfer:
https://github.com/torvalds/linux/blob/master/drivers/i2c/i2c-core.c#L1685

Which then just bumps it along to the protocol transfer code:
ret = adap->algo->master_xfer(adap, msgs, num);

In the standard i2c xfer protocols, because msgs->len is 0, it will send the address, but will not send any messages.

However, since we are using the AM3353x, I beleive it uses omap_i2c_xfer_msg
https://github.com/torvalds/linux/blob/a09e9a7a4b907f2dfa9bdb2b98a1828ab4b340b2/drivers/i2c/busses/i2c-omap.c#L514

Which then aborts out:
https://github.com/torvalds/linux/blob/a09e9a7a4b907f2dfa9bdb2b98a1828ab4b340b2/drivers/i2c/busses/i2c-omap.c#L524
if (msg->len == 0)
		return -EINVAL;

Thus killing you right then and there.  Because of this, I don't think there is a way to send JUST the address on i2c.  I'd suggest bumping this over to TI as a bug report and confirming with them whether or not their driver allows for it.

Of course, see my post about my background - I am NOT a C programmer or an embedded systems designer - so I may well be completely off-base.  This is just basic code review/tracking thanks to Google and Github.

[garyamort]

As a followup, because this seems to be a TI driver issue and not Beagle Bone Black specific, I did a quick search of the TI forum and ran across this post:

http://e2e.ti.com/support/embedded/linux/f/354/t/153514.aspx

Which deals with a similar issue.  It seems that in order to write just the address to the i2c transmission with no data you need to use the i2c_smbus_access()  function.

While this feels like a bug in the TI i2c protocol driver since it should support the SAME command usage as the basic i2c protocol drivers, rather than waiting for TI to fix it a possible workaround would be to rewrite your driver as follows:

In the function hih6130_update_measurements.  Based on https://www.kernel.org/doc/Documentation/i2c/dev-interface I think what you would need to do is:

1) make sure to load the i2c-dev driver.  I think modprobe i2c-dev should do it.  Then check the /sys/class/i2c-dev/ director to see what adapter numbers are assigned. Finally, in the driver, at the top of the file make sure to add:

#include <linux/i2c-dev.h>

replace

     

  /* write to slave address, no data, to request a measurement */
        ret = i2c_master_send(client, tmp, 0);
        if (ret < 0)
            goto out;

with

        /* write to slave address, no data, to request a measurement */

        /* HACK: open the i2c-dev file for the i2c device */
        int i2cs_smbus_file;
        int adapter_nr = 2; /* use numbers determined from checking the /sys/class/i2c-dev folder */
        char i2cs_smbus_file[20];
 
        snprintf(i2cs_smbus_file, 19, "/dev/i2c-%d", adapter_nr);
        i2c_smbus_fd = open(i2cs_smbus_file, O_RDWR);
        if (i2c_smbus_fd < 0) {
            /* ERROR HANDLING; you can check errno to see what went wrong. Probably should return a more intelligent error code here */
           return i2c_smbus_fd;
        }


        // setup the smData structure with a length of 0 to indicate no data to be cent
        union i2c_smbus_data smData;
        smData.length = 0;


        // create some dummy data by using the sensors address
        __u8 i2c_smbus_data = client->addr;


       // Silly call to write to the file using a broken stream of data
       ret = i2c_smbus_access(i2c_smbus_fd, I2C_SMBUS_WRITE, i2c_smbus_data, I2C_SMBUS_I2C_BLOCK_BROKEN, &i2c_smbus_data);

       if (ret < 0)
            goto out;

       // cleanup our file handle
       int closeFileReturn = 0;
       closeFileReturn  = close(i2c_smbus_fd);

There are a couple of other ways of doing the above depending on how much deeper you want to go.

I'm not sure about the placement of the file close function call, or if it is even really needed.  Because file operations slow things down, ideally the i2c_smbus_fd handle should really be placed in the driver initialization and stored either globally or in the device structure - that way it can be opened once and reused, rather than opening and closing it every time you want to take a reading.

Of course, I'm not really sure about the entire code to begin with.  I'll pick through my various modules and see if I have an i2c device that works in this manner[ie send it the address with no data, then read the return value] and if so I can test it out...or if you want to setup your device with remote SSH access I'd be happy to hack the driver and compile it there and see if I can get it to work.