If you're curious as to how to figure out what I2C interface maps to which bus, take a look at this post I wrote yesterday:
https://groups.google.com/d/msg/beagleboard/v9r8UkN7klk/h3rFKFJDLnUJ On Friday, November 1, 2013 11:02:44 AM UTC-4, Jason Kridner wrote: > > On Fri, Nov 1, 2013 at 12:09 AM, Joshua Datko <[email protected]<javascript:>> > wrote: > > Nevemind, that may be unrelated. I just rebooted and my device > enumerated > > fine. I think what's confusing (me) is the I2C2 by the SRM (P9_19/20) > shoes > > up as I2C1... > > Yeah, this is a really confusing (well-known) issue where the latest > Linux kernels assign the bus names in order of them being enumerated, > despite whatever hardware name is given to them. So, I2C0, enumerated > first, becomes, i2c0 and I2C2, enumerated second, becomes i2c1. If you > then enumerate I2C1, you'll get an i2c2. Kinda confusing, got to give > you that. > > > > > some output: > > > > ebian@arm:~$ ls -l /sys/bus/i2c/devices/i2c-* > > lrwxrwxrwx 1 root root 0 Nov 1 04:02 /sys/bus/i2c/devices/i2c-0 -> > > ../../../devices/ocp.2/44e0b000.i2c/i2c-0 > > lrwxrwxrwx 1 root root 0 Nov 1 04:02 /sys/bus/i2c/devices/i2c-1 -> > > ../../../devices/ocp.2/4819c000.i2c/i2c-1 > > debian@arm:~$ su > > Password: > > root@arm:/home/debian# i2cdetect -r 1 > > WARNING! This program can confuse your I2C bus, cause data loss and > worse! > > I will probe file /dev/i2c-1 using read byte commands. > > I will probe address range 0x03-0x77. > > 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: -- -- -- -- -- -- -- -- 48 -- -- -- -- -- -- -- > > 50: -- -- -- -- UU UU UU UU -- -- -- -- -- -- -- -- > > 60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- > > 70: -- -- -- -- -- -- -- -- > > I need hints on how the MPU6050 should be wired up or assume that I've > got a bad device. I can probably try hooking it up to something else. > > > > > > > > > On Thursday, October 31, 2013 9:57:08 PM UTC-6, Joshua Datko wrote: > >> > >> So I've been struggling with I2C. Somebody on this list gave me the > tip > >> to do: > >> > >> echo BB-I2C1 > /sys/devices/bone_capemgr.????/slots > >> > >> which enables the third I2C bus and my device then was visible via > >> i2cdetect -y -r 1 on pins P9_19 and P9_20. Although, after doing that, > >> you'll have an i2c1 and a i2c2 bus, so might want to check both. But, > I'm > >> not quite sure why this works :) > >> > >> In my case, I don't think there is device tree entry for the device I'm > >> using, so I was planning on interacting with it over raw I2C. > >> > >> Hope this helps, > >> > >> Josh > >> > >> > >> On Thursday, October 31, 2013 2:32:46 PM UTC-6, Jason Kridner wrote: > >>> > >>> On Tue, Oct 29, 2013 at 2:19 PM, Jason Kridner < > [email protected]> > >>> wrote: > >>> > > >>> > On Thu, Oct 17, 2013 at 6:12 PM, <[email protected]> wrote: > >>> > > AIW: > >>> > > I went back thru the adafruit library and didn't find anything > >>> > > specific on > >>> > > I2C, although it is listed as a topic. I have been looking at > their > >>> > > github > >>> > > adafruit-beaglebone-io-python library. I also found and looked > thru > >>> > > PyBBIO. > >>> > > Even tho I'm not using Python, I can see the access mechanisms > that > >>> > > they > >>> > > use. > >>> > > I can use the MPU6050 device ok enough just reading via > >>> > > /dev/i2c/i2c-x, but > >>> > > that is too slow. > >>> > > I'm trying to figure out how to invoke and use the inv-mpu6050 > driver > >>> > > and > >>> > > adafruit doesn't use that. > >>> > > Thx -- Clark > >>> > > > >>> > > On Thursday, October 17, 2013 9:47:44 AM UTC-7, AIW wrote: > >>> > >> > >>> > >> Some good info on I2C tools at http://www.acmesystems.it/i2c. > >>> > >> > >>> > >> Python and the adafruit BBIO I2C library makes it very easy to > use > >>> > >> I2C on > >>> > >> Beaglebone Black as well. Python import smbus is fairly easy to > use > >>> > >> too. > >>> > >> Some examples of use is available in the code I provide for my > radio > >>> > >> project > >>> > >> here....www.aiwindustries.com. > >>> > >> > >>> > >> Not trying to sell the product, but I know that the I2C function > was > >>> > >> giving me some issues so I'm just trying to help the community. > >>> > >> Python code > >>> > >> is available to download and look at usage so feel free. > >>> > >> > >>> > >> On Tuesday, October 15, 2013 5:02:59 PM UTC-5, > [email protected] > >>> > >> wrote: > >>> > >>> > >>> > >>> We are using the Invensense MPU6050 IMU on I2C with Beaglebone > >>> > >>> Black > >>> > >>> (Angstrom 3.8.13). We can use I2C-tools and file I/O thru > /dev/i2c > >>> > >>> but the > >>> > >>> read speed is disappointingly slow. We only read the 3x gyros > and > >>> > >>> 3x accels > >>> > >>> (each one byte at a time plus the 2 byte temperature reading) > and > >>> > >>> it takes > >>> > >>> ~2msecs. My estimate of the I2C bus cycles for a block read > >>> > >>> suggests this > >>> > >>> should take ~160 bus cycles or .38msec on a 400MHz I2C bus. > >>> > > >>> > You are running at 400kHz, not 400MHz, right? I2C doesn't do > 400MHz. > >>> > > >>> > >>> > >>> > >>> The distribution includes the Invensense driver inv-mpu6050.ko > but > >>> > >>> there > >>> > >>> is no indication that reading through /dev/i2c invokes it. This > is > >>> > >>> a very > >>> > >>> popular IMU and Invensense widely distributes the driver over > many > >>> > >>> Linux > >>> > >>> platforms. The driver source includes “successful installation > >>> > >>> will create > >>> > >>> two directories under /sys/bus/iio/devices” and lists the files > >>> > >>> there (aka > >>> > >>> functions). I can never get these to show up. > >>> > >>> > >>> > >>> I can “insmod > >>> > >>> > >>> > >>> > /lib/modules/3.8.13/kernel/drivers/iio/imu/inv_mpu6050/inv-mpu6050.ko” and > >>> > >>> “echo inv-mpu6050 0x68 > > /sys/class/i2c-adapter/i2c-1/new_device”. > >>> > >>> This > >>> > >>> causes a new directory named 1-0068 to show in > >>> > >>> /sys/class/i2c-adapter/i2c-1with entries like name and modalias > but > >>> > >>> no > >>> > >>> functions. It never shows in /sys/bus/iio/devices. > >>> > > >>> > I don't have an MPU6050, but I just ordered a couple on express > >>> > overnight from Sparkfun. > >>> > >>> I bought https://www.sparkfun.com/products/11028 and played with it > >>> briefly before being distracted and again today, but I don't > >>> understand why I'm not able to get it to reply to me. > >>> > >>> I have the following connections: > >>> VCC: P9_4 (VDD_3V3) > >>> GNC: P9_1 (GND) > >>> INT: P9_11 (GPIO) > >>> FSYNC: - > >>> SCL: P9_19 (I2C2_SCL) > >>> SDA: P9_20 (I2C2_SDA) > >>> VIO: P9_3 (VDD_3V3) > >>> CLK: - > >>> ASCL: - > >>> ASDA: - > >>> > >>> I then perform: > >>> > >>> root@beaglebone:~# i2cdetect -y -r 1 > >>> 0 1 2 3 4 5 6 7 8 9 a b c d e f > >>> 00: -- -- -- -- -- -- -- -- -- -- -- -- -- > >>> 10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- > >>> 20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- > >>> 30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- > >>> 40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- > >>> 50: -- -- -- -- UU UU UU UU -- -- -- -- -- -- -- -- > >>> 60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- > >>> 70: -- -- -- -- -- -- -- -- > >>> > >>> Very confused why it doesn't show up. > >>> > >>> Since you have it responding to you, how do you have it wired? > >>> > >>> > > >>> > Here's the behavior I'm seeing without the board connected: > >>> > > >>> > > root@beaglebone:/lib/modules/3.8.13/kernel/drivers/iio/imu/inv_mpu6050# > >>> > ls > >>> > inv-mpu6050.ko > >>> > > root@beaglebone:/lib/modules/3.8.13/kernel/drivers/iio/imu/inv_mpu6050# > >>> > dmesg | tail -1 > >>> > [ 2992.799594] i2c i2c-1: new_device: Instantiated device > inv-mpu6050 > >>> > at 0x68 > >>> > > root@beaglebone:/lib/modules/3.8.13/kernel/drivers/iio/imu/inv_mpu6050# > >>> > lsmod > >>> > Module Size Used by > >>> > ip_tables 8294 0 > >>> > x_tables 15072 1 ip_tables > >>> > g_multi 55905 2 > >>> > libcomposite 15228 1 g_multi > >>> > rfcomm 25106 0 > >>> > ircomm_tty 14503 0 > >>> > ircomm 8846 1 ircomm_tty > >>> > irda 89974 2 ircomm_tty,ircomm > >>> > ipv6 229989 14 > >>> > hidp 10112 0 > >>> > bluetooth 146100 4 hidp,rfcomm > >>> > rfkill 16510 2 bluetooth > >>> > autofs4 17432 2 > >>> > > >>> > I looked for the installed device: > >>> > > >>> > > root@beaglebone:/lib/modules/3.8.13/kernel/drivers/iio/imu/inv_mpu6050# > >>> > cat /sys/bus/iio/devices/iio*/name > >>> > tiadc > >>> > > root@beaglebone:/lib/modules/3.8.13/kernel/drivers/iio/imu/inv_mpu6050# > >>> > ls /sys/bus/iio/devices/iio* -d > >>> > /sys/bus/iio/devices/iio:device0 > >>> > > >>> > It is clearly missing per the documentation > >>> > > >>> > ( > https://www.kernel.org/doc/Documentation/ABI/testing/sysfs-bus-iio-mpu6050) > > >>> > that says there should be a sysfs entry there. > >>> > > >>> > Just in case I could get it to show up, I did try manually doing a > >>> > modprobe. > >>> > > >>> > > root@beaglebone:/lib/modules/3.8.13/kernel/drivers/iio/imu/inv_mpu6050# > >>> > modprobe inv-mpu6050 > >>> > > root@beaglebone:/lib/modules/3.8.13/kernel/drivers/iio/imu/inv_mpu6050# > >>> > lsmod > >>> > Module Size Used by > >>> > inv_mpu6050 7190 0 > >>> > ip_tables 8294 0 > >>> > x_tables 15072 1 ip_tables > >>> > g_multi 55905 2 > >>> > libcomposite 15228 1 g_multi > >>> > rfcomm 25106 0 > >>> > ircomm_tty 14503 0 > >>> > ircomm 8846 1 ircomm_tty > >>> > irda 89974 2 ircomm_tty,ircomm > >>> > ipv6 229989 14 > >>> > hidp 10112 0 > >>> > bluetooth 146100 4 hidp,rfcomm > >>> > rfkill 16510 2 bluetooth > >>> > autofs4 17432 2 > >>> > > root@beaglebone:/lib/modules/3.8.13/kernel/drivers/iio/imu/inv_mpu6050# > >>> > ls /sys/bus/iio/devices/iio* -d > >>> > /sys/bus/iio/devices/iio:device0 > >>> > > >>> > Of course, this all makes perfect sense since the driver should exit > >>> > upon failing the 'probe': > >>> > > >>> > > https://github.com/beagleboard/linux/blob/3.8/drivers/iio/imu/inv_mpu6050/inv_mpu_core.c#L658 > > >>> > > >>> > I'd have to look up how to turn on more debugging statements. I > tried > >>> > the hints at http://elinux.org/Debugging_by_printing, but I'm > >>> > surprised the 'dmesg' log didn't show any extra errors. > >>> > > >>> > > >>> > >>> > >>> > >>> What constitutes “successful installation”? > >>> > >>> > >>> > >>> What else is needed to get the inv-mpu6050 to expose functions > in > >>> > >>> /sys/bus/iio/devices like the driver sources says? > >>> > > >>> > I don't think anything else should be required. To build the kernel > >>> > properly, there are a few things that need to be enabled > >>> > > >>> > ( > https://github.com/beagleboard/linux/blob/3.8/drivers/iio/imu/inv_mpu6050/Kconfig): > > > >>> > > >>> > INV_MPU6050_IIO, I2C, SYSFS, IIO_BUFFER, IIO_TRIGGERED_BUFFER > >>> > > >>> > And they are all there: > >>> > > https://github.com/beagleboard/kernel/blob/3.8/configs/beaglebone#L3676 > >>> > > >>> > >>> > >>> > >>> Beaglebone Black uses bone_capemgr for exposing driver functions > >>> > >>> for many > >>> > >>> devices. “echo inv-mpu6050 0x68 > > >>> > >>> /sys/devices/bone_capmgr.9/slots” raises > >>> > >>> the gripe “write error: no such file or directory”. (I can > >>> > >>> successfully > >>> > >>> load the am33xx_pwm driver this way.) Is this because there is > no > >>> > >>> matching > >>> > >>> DT fragment in /lib/firmware? > >>> > > >>> > Yes. > >>> > > >>> > >>> Is the inv-mpu6050 driver supposed to be > >>> > >>> invoked thru cape manager? > >>> > > >>> > No, because the I2C bus software provides another mechanism. I > believe > >>> > you could create a DT fragment, but I think it is pointless. > >>> > > >>> > >>> > >>> > >>> Then, most importantly, if I did read and write through the /sys > >>> > >>> tree > >>> > >>> using the Invensense driver would it be faster than /dev/i2c? > >>> > >>> Help on sorting this out would be much appreciated. > >>> > > >>> > Yes, because the driver running in kernel mode is going to be higher > >>> > performance than your pokes from userspace. > >>> > > >>> > > > >>> > > -- > >>> > > For more options, visit http://beagleboard.org/discuss > >>> > > --- > >>> > > You received this message because you are subscribed to the Google > >>> > > Groups > >>> > > "BeagleBoard" group. > >>> > > To unsubscribe from this group and stop receiving emails from it, > >>> > > send an > >>> > > email to [email protected]. > >>> > > For more options, visit https://groups.google.com/groups/opt_out. > > > > -- > > For more options, visit http://beagleboard.org/discuss > > --- > > You received this message because you are subscribed to the Google > Groups > > "BeagleBoard" group. > > To unsubscribe from this group and stop receiving emails from it, send > an > > email to [email protected] <javascript:>. > > For more options, visit https://groups.google.com/groups/opt_out. > -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups "BeagleBoard" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
