I2C Pressure Sensor

GoogleGroups
1

Hello everyone!

I am currently trying to get my beaglebone black to communicate via the I2C_1 port to a honeywell pressure sensor. The interesting part is that I had it working, but when I went to change from a normal breadboard to the beaglebone black protocape for convenience in transportation, the sensor stopped communicating. I have attached the relevant data sheets and a couple pictures that show my breadboard. I made sure to show the prongs of each resistor so you could see where they were located. However, just in case it is not clear, I have the sensor plugged into breadboard rows 1,2,3 & 4; the resistors are 1K each, and are plugged into rows 2&3 and 2&4; and the rest should be apparent from the photos. Obviously, I am fairly new to this stuff. I cannot figure out if it is something super obvious that I am missing, or if there is something obscure hidden well within the linux OS that could be impacting the lack of communication.

Note: I did follow Derek Molloy’s video to get this far. I am using Ubuntu and i2cdetect/i2cdump to verify that the port is picking up the sensor address (0x28)

Thanks for any assistance in advance,

Jacob Stockton

HoneywellDPTDatasheet.pdf (1.12 MB)

BeagleboneBlackP9HeaderTable.pdf (110 KB)

Honeywell - I2C Comms Digital Output Pressure Sensors.pdf (212 KB)

Photo Jul 30, 12 20 20 PM.jpg

Photo Jul 30, 12 20 53 PM.jpg

2

Curiously enough, the board is now communicating with the sensor through i2c-1, but I have the sda and scl lines plugged into pins 19&20 on the P9 header. I believe these pins correspond to i2c-2, right? At least, that’s what it says in the pinout on the BBB-SRM pg 78. Can anyone speak to this?

Also, I am having troubles with the open() function in my c++ driver that I am trying to write; the code is below. Again, I am following Derek Molloy’s tutorial from my last post, and I believe he followed the instructions posted here. Can anyone provide any insight as to why the open() function is failing? I can go to the /dev directory and there is a file called i2c-1, so I am unsure as to why this is not working.

#define MAX_BUS 64
#define I2CBus 1
#define I2CADDRESS 0x28
#define HDPT_I2C_BUFFER 0x80

using namespace std;

int main() {

cout << “Starting HDPT I2C sensor state read” << endl;

char namebuf[MAX_BUS];
snprintf(namebuf, sizeof(namebuf), “/dev/i2c-%d”, I2CBus);
int file;
if ((file = open(namebuf, O_RDWR)) < 0){
cout << "Failed to open Honeywell DPT Sensor on " << namebuf << " I2C Bus. Error no. " << file << endl;
return(1);
}
if (ioctl(file, I2C_SLAVE, I2CADDRESS) < 0){
cout << “I2C_SLAVE address " << I2CADDRESS << " failed…” << endl;
return(2);
}

3

Curiously enough, the board is now communicating with the sensor through
i2c-1, but I have the sda and scl lines plugged into pins 19&20 on the
P9 header. I believe these pins correspond to i2c-2, right? At least,
that's what it says in the pinout on the BBB-SRM pg 78. Can anyone speak
to this?

i2c devices in the /dev directory are a count of enabled devices.

You have i2c-0 and i2c-2 enabled, by the beaglebone naming scheme. But
to Linux you have

i2c-0 (i2c-0)
i2c-2 (i2c-1)

Also, I am having troubles with the open() function in my c++ driver
that I am trying to write; the code is below. Again, I am following
Derek Molloy's tutorial from my last post, and I believe he followed the
instructions posted here
<https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/tree/Documentation/i2c/dev-interface&gt;\.
Can anyone provide any insight as to why the open() function is failing?
I can go to the /dev directory and there is a file called i2c-1, so I am
unsure as to why this is not working.

Do you have the correct permissions?

[snip]

Cheers,

4

The BBB SRM is correct. However, in the Linux world, the number it uses, such as I2C0 or I2C2, has nothing to do with the HW.

Gerald

5

Thanks guys for the prompt response! That makes sense as I have seen a few posts on gaining access to the i2c-1 port. That being said, if linux sees it as i2c-1, wouldn’t it make sense for my code to do so as well?

Jack,

It seems you were correct! I just ran it using the sudo command and it worked. I am very new to linux, and I do not understand the entirety of user permissions. I need this program to be able to run as a driver for all users. How would i set the permissions accordingly? Also, is there a resource I could consult for this? There are so many flavors of embedded linux that I cannot find a good resource to get my footing. The resources I have found are to technical or too specific to a certain distro.

Thanks,

Jacob

6

Jacob,

Thanks guys for the prompt response! That makes sense as I have seen a
few posts on gaining access to the i2c-1 port. That being said, if linux
sees it as i2c-1, wouldn't it make sense for my code to do so as well?

Jack,

It seems you were correct! I just ran it using the sudo command and it
worked. I am very new to linux, and I do not understand the entirety of
user permissions.

Linux permissions are not specific to any Embedded Linux, or even a
flavour Linux. I would recommend reading up on Linux file permissions[1].

I need this program to be able to run as a driver for
all users. How would i set the permissions accordingly?

I don't know how these device files are created, if they are created
with udev, you can write a rule to set permissions on creation I
believe. Alternatively, if you run a script as root which chmod's the
i2c devices on boot that might be easier than dealing with udev, it
depends on your expertise and the depth you want to go into.

Also, is there a
resource I could consult for this? There are so many flavors of embedded
linux that I cannot find a good resource to get my footing.

This is a common mistake.

Linux is Linux.

Different distributions ship different programs, different versions and
different default settings. But, in the grand scheme, the fundamentals
are the same. If you're struggling you need to get a grip on the basics
of the Linux kernel, and the userspace application stack and how they
interact. This will make things clearer.

The
resources I have found are to technical or too specific to a certain distro.

Unfortunately it's a fairly steep learning curve, the best way to do it
is get stuck in and when stuck, read, read, read.

Thanks,

Jacob

Cheers,

[1] http://www.tuxfiles.org/linuxhelp/filepermissions.html

7

Thanks again Jack. One more question while I have you. From what I read, it makes more sense for me to add my user (ubuntu) to the group “i2c” that is in /dev. Then I would have read write permissions to that file for my user permanently, see below for permissions associated with the files.

crw-rw---- 1 root i2c 89, 0 Jun 14 19:08 i2c-0

crw-rw---- 1 root i2c 89, 1 Jun 14 19:08 i2c-1

Is this a viable option? If so, I believe I need to use the “usermod” command as shown here, but when I do so, it doesn’t seem to work. I typed:

sudo usermod -a -G i2c ubuntu

But when i type “groups” to query which groups I am associated with, I do not see i2c listed.

8

That is the correct way to do it. Ensure you have restarted or logged
in/out after you have issued the useradd command.

Cheers,

9

The restart was what I was missing. Thanks! I am now able to move forward.