Hi, did you pursue your work on the mpu6050 ? I have a hard time figuring how to use the invensense driver. Is it worth it ?
thanks Le mardi 13 mai 2014 22:46:55 UTC+2, [email protected] a écrit : > > Hi, > I have got a small project at home running the inv_mpu6050 driver on a > 3.8.13 kernel. To get it working I had to modify the driver, so that it > accepts device tree parameters, then I wrote a cape configuration for the > i2c and the mpu6050 device and voila it worked. I added the driver to the > kernel and then add the cape to the device tree by echoing the cape name to > /sys/devices/bone_capemgr.8/slots. So then I had: > > cat /sys/devices/bone_capemgr.8/slots > 0: 54:PF--- > 1: 55:PF--- > 2: 56:PF--- > 3: 57:PF--- > 4: ff:P-O-L Override Board Name,00A0,Override Manuf,BB-BONE-MPU6050 > > lsmod > Module Size Used by > inv_mpu6050 7868 0 > g_multi 47670 0 > libcomposite 14299 1 g_multi > mt7601Usta 601404 0 > > ls /sys/bus/iio/devices/iio:device0/ > buffer in_accel_scale in_accel_z_raw in_anglvel_y_raw > in_temp_offset name sampling_frequency_available trigger > dev in_accel_x_raw in_anglvel_scale in_anglvel_z_raw > in_temp_raw power scan_elements uevent > in_accel_matrix in_accel_y_raw in_anglvel_x_raw in_gyro_matrix > in_temp_scale sampling_frequency subsystem > > cat /sys/bus/iio/devices/iio:device0/*raw > -8202 > -458 > 11288 > 10 > 51 > 109 > -4967 > > But now to the downside of it all. If I try to access the values, e.g. > /sys/bus/iio/devices/iio:device0/in_accel_x_raw it takes more than 100ms? > Well I am still working on some improvements in the driver's device tree > (the parameters can be negative, but the dtc version I have got can not > handle unary parameters yet), but when I am finished I will commit the > driver back to the community. > > My work so far: > -) The Cape File: > /* > * Copyright (C) 2014 Thomas Grazadei > * > * Make use of the Invensense MPU6050 > * > * This program is free software; you can redistribute it and/or modify > * it under the terms of the GNU General Public License version 2 as > * published by the Free Software Foundation. > */ > /dts-v1/; > /plugin/; > > / { > compatible = "ti,beaglebone", "ti,beaglebone-black"; > > /* identification */ > part-number = "BB-MPU6050"; > version = "00A0"; > > /* state the resources this cape uses */ > exclusive-use = > /* the pin header uses */ > "P9.18", /* i2c1_sda */ > "P9.17", /* i2c1_scl */ > /* the hardware ip uses */ > "i2c1"; > > fragment@0 { > target = <&am33xx_pinmux>; > __overlay__ { > bb_i2c1_pins: pinmux_bb_i2c1_pins { > pinctrl-single,pins = < > 0x158 0x72 /* > spi0_d1.i2c1_sda, SLEWCTRL_SLOW | INPUT_PULLUP | MODE2 */ > 0x15c 0x72 /* > spi0_cs0.i2c1_scl, SLEWCTRL_SLOW | INPUT_PULLUP | MODE2 */ > >; > }; > }; > }; > > fragment@1 { > target = <&i2c1>; /* i2c1 is numbered correctly */ > __overlay__ { > status = "okay"; > pinctrl-names = "default"; > pinctrl-0 = <&bb_i2c1_pins>; > > /* this is the configuration part */ > clock-frequency = <400000>; > > #address-cells = <1>; > #size-cells = <0>; > > /* add any i2c devices on the bus here */ > > mpu6050@68 { > compatible = "inv,mpu6050"; > reg = <0x68>; > orientation = <0xff 0 0 0 1 0 0 0 0xff>; > }; > }; > }; > }; > > -) and the changes in the driver: > diff --git a/drivers/iio/imu/inv_mpu6050/inv_mpu_core.c > b/drivers/iio/imu/inv_mpu6050/inv_mpu_core.c > index 37ca05b..d101a0c 100644 > --- a/drivers/iio/imu/inv_mpu6050/inv_mpu_core.c > +++ b/drivers/iio/imu/inv_mpu6050/inv_mpu_core.c > @@ -648,6 +648,31 @@ static int inv_check_and_setup_chip(struct > inv_mpu6050_state *st, > return 0; > } > > +static struct inv_mpu6050_platform_data* > + mpu6050_parse_dt(struct device* dev) > +{ > + struct device_node *np = dev->of_node; > + struct inv_mpu6050_platform_data *pdata; > + > + if (!np) { > + dev_err(dev, "no device tree or platform data\n"); > + return ERR_PTR(-EINVAL); > + } > + > + pdata = devm_kzalloc(dev, sizeof(*pdata), GFP_KERNEL); > + if (!pdata) > + return ERR_PTR(-ENOMEM); > + > + > + if (of_property_read_u8_array(np, "orientation", > + pdata->orientation, sizeof(pdata->orientation)) != 0) { > + dev_err(dev, "no valid orientation property found\n"); > + return ERR_PTR(-EINVAL); > + } > + > + return pdata; > +} > + > /** > * inv_mpu_probe() - probe function. > * @client: i2c client. > @@ -660,6 +685,7 @@ static int inv_mpu_probe(struct i2c_client *client, > { > struct inv_mpu6050_state *st; > struct iio_dev *indio_dev; > + struct inv_mpu6050_platform_data* pdata; > int result; > > if (!i2c_check_functionality(client->adapter, > @@ -675,8 +701,21 @@ static int inv_mpu_probe(struct i2c_client *client, > } > st = iio_priv(indio_dev); > st->client = client; > - st->plat_data = *(struct inv_mpu6050_platform_data > - *)dev_get_platdata(&client->dev); > + pdata = (struct inv_mpu6050_platform_data*) > + dev_get_platdata(&client->dev); > + > + if (pdata == NULL) { > + /* check of devicetree */ > + // printk(KERN_ERR "checking device tree for parameter infos"); > + pdata = mpu6050_parse_dt(&client->dev); > + } > + > + if (IS_ERR(pdata)) { > + return PTR_ERR(pdata); > + } > + > + st->plat_data = *pdata; > + > /* power is turned on inside check chip type*/ > result = inv_check_and_setup_chip(st, id); > if (result) > @@ -777,14 +816,22 @@ static const struct i2c_device_id inv_mpu_id[] = { > > MODULE_DEVICE_TABLE(i2c, inv_mpu_id); > > +static struct of_device_id inv_mpu6050_i2c_of_match[] = { > + { .compatible = "inv,mpu6050", }, > + { } > +}; > + > +MODULE_DEVICE_TABLE(of, inv_mpu6050_i2c_of_match); > + > static struct i2c_driver inv_mpu_driver = { > .probe = inv_mpu_probe, > .remove = inv_mpu_remove, > .id_table = inv_mpu_id, > .driver = { > - .owner = THIS_MODULE, > - .name = "inv-mpu6050", > - .pm = INV_MPU6050_PMOPS, > + .owner = THIS_MODULE, > + .name = "inv-mpu6050", > + .pm = INV_MPU6050_PMOPS, > + .of_match_table = inv_mpu6050_i2c_of_match, > }, > }; > > cheers, > gardi > > > Am Mittwoch, 7. Mai 2014 02:16:57 UTC+2 schrieb [email protected]: >> >> No we never got this (the Invensense driver) working. We just stuck it >> out with reading /dev/i2c. This is costing us a 20% time penalty which >> really really hurts. We couldn't get anyone to take on fixing the >> unbelievably long read times (~1msec) on /dev/i2c either. >> Some of us are hoping the up coming move to Debian from Angstrom will >> bring us an Invensense driver in the distro that will somehow work. >> On Tuesday, May 6, 2014 10:42:41 AM UTC-7, [email protected] wrote: >>> >>> Knowing this discussion is old, i have to ask did you get it working? >>> And my experience is with the bbw, not the bbb. but the i2c buss on my >>> device is 100khz. maximum is 400khz. I was able to get the accelerometer >>> and gyro values at a rate of 200hz without issue, which isn't the max the >>> chip can provide, but it's more than suitable for most applications. All >>> through accessing /dev/i2c-#. If you havent got the driver to work yet, I >>> can send you my tiny little C program that prints the data to the shell. >>> >>> 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 400kHz I2C bus. >>>> >>>> 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. >>>> >>>> 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? >>>> >>>> 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? Is the inv-mpu6050 driver supposed to be invoked thru cape >>>> manager? >>>> 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. >>>> >>> -- 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/d/optout.
