Okay thanks for all the help! I think I'm just going to get familiar with the registers and either write or find a library rather than delve too much farther into drivers and such. Maybe another day.
Thanks again for the pointers Andrew On Fri, Dec 27, 2013 at 6:55 PM, <[email protected]> wrote: > Andrew, > Doing file I/O means read and write to /dev/i2c/etc. As you put it in > your question, they are the same thing and basically the same as using the > command line tools. This works out of the box. You need to know the device > registers pretty well because you will be accessing them. Some libraries > will give you nice wrappers for simple register access and some may provide > higher level calls, for example, for reading all 3 gyros. > The alternative is to use the Invensense driver. Way back up in this > conversation was a description of how it should work based on documentation > in the driver and the kernel source tree. So far in this conversation, no > one has made that work. That is, the driver fails to load. When it does > load, its documentation says it will provide psuedo files that are > functions under the sysfs tree /sys/bus/iio/devices. Besides being > functionally named instead of addresses, we are expecting them to be > faster. My timing tests with using file I/O via /dev/i2c shows file I/O to > take significantly more time that one would expect by counting I2C bus > cycles. Some applications need faster access time than this provides. > Your application may work just fine at this speed. > Clark > > On Thursday, December 26, 2013 8:25:03 PM UTC-8, Andrew Dai wrote: > >> Setting the SLEEP bit seemed to have done the trick, everything seems to >> work now! (or at least at the surface) >> >> I apologize for any beginner questions (this is my first trip into the >> wonderful world of embedded linux). What is the difference between the >> "file" approach and i2c? >> I was planning on using something like the Adafruit_BBIO library ( >> http://learn.adafruit.com/setting-up-io-python-library- >> on-beaglebone-black) and accessing the chip through i2c. My >> understanding is that that approach would be basically the same as using >> the command line tools (i2cdetect, i2cdump/set/get etc). Using this method, >> I have no use for anything driver or device tree related... correct? >> >> >> >> On Mon, Dec 23, 2013 at 4:41 PM, <[email protected]> wrote: >> >>> Andrew, >>> You have made some progress. i2cdetect can see it. Your pin >>> connections seem to be ok, compared to the ones posted earlier. According >>> to the device docs, it "will come up in sleep mode upon power up." >>> The SLEEP bit is apparently Bit6 in Register 0x6B. Set it to 0 to leave >>> the sleep mode. >>> >>> Maybe that helps. >>> >>> We got as far as using the MPU6050 and the MPU9150 via file I/O thru >>> /dev/i2c. We never got the Invensense driver to work. It still looks like >>> no one replying to the posts here has either. The disadvantage of the >>> file I/O access approach is that it seems very slow compared to the >>> relatively few I2C bus cycles required. >>> >>> Clark >>> >>> >>> On Sunday, December 22, 2013 8:45:23 AM UTC-8, Andrew Dai wrote: >>> >>>> So has anyone figured out how to get the MPU6050 to respond? >>>> I dont know too much about how all this works but all I've done is >>>> 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: -- -- -- -- -- -- -- -- 68 -- -- -- -- -- -- -- >>>> 70: -- -- -- -- -- -- -- -- >>>> root@beaglebone:~# i2cdump -y 1 0x68 >>>> 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: 81 7d 00 1d 3c cd fc ae 05 44 08 5c 28 8f 6e 90 ?}.?<????D?\(?n? >>>> 10: d4 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ?............... >>>> 20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ >>>> 30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ >>>> 40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ >>>> 50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ >>>> 60: 00 00 00 00 00 00 00 00 00 00 00 40 00 00 00 00 ...........@.... >>>> 70: 00 00 00 00 00 68 00 00 00 00 00 00 00 00 00 00 .....h.......... >>>> 80: 81 7d 00 1d 3c cd fc ae 05 44 08 5c 28 8f 6e 90 ?}.?<????D?\(?n? >>>> 90: d4 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ?............... >>>> a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ >>>> b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ >>>> c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ >>>> d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ >>>> e0: 00 00 00 00 00 00 00 00 00 00 00 40 00 00 00 00 ...........@.... >>>> f0: 00 00 00 00 00 68 00 00 00 00 00 00 00 00 00 00 .....h.......... >>>> >>>> I cant get my board (sparkfun breakout board) to respond to anything... >>>> i2cset doesn't affect the board... did I wire something wrong? >>>> VDD to Pin 3 (3.3V) >>>> Gnd to Pin 1 >>>> SCL to Pin 19 >>>> SDA to Pin 20 >>>> VIO to Pin 3 (3.3) <-- I'm not quite sure what this does but I get >>>> nothing back when I disconnect it. >>>> >>>> Any help will be greatly appreciated! >>>> >>>> Thanks, >>>> Andrew >>>> >>>> On Saturday, November 16, 2013 10:27:19 PM UTC-5, >>>> [email protected]: >>>>> >>>>> Mark, >>>>> I poked briefly at the reference you provided. The write up looks >>>>> very much the same as the Invensense MPU6050 driver in the Angstrom on the >>>>> Black. This seems reasonable. The Invensense author has done a good job >>>>> of getting it into the Linux tree and the various distributions have >>>>> picked >>>>> it up. Apparently, the MPU 60x0 family of MEMS IMUs is widely used and >>>>> popular. >>>>> The Anstrom driver reads nice. No one here has yet to get it to load >>>>> and respond. >>>>> Clark >>>>> On Thursday, November 14, 2013 1:40:35 PM UTC-8, Mark A. Yoder wrote: >>>>> >>>>>> It looks like someone has done a nice port to Andriod[1]. How hard >>>>>> would it be to port it to Angstrom? >>>>>> >>>>>> --Mark >>>>>> >>>>>> [1] https://android.googlesource.com/kernel/tegra/+/74f15aa7 >>>>>> 3e1d999368e3a8287cdb85718e987d48/drivers/staging/iio/imu/mpu/README >>>>>> >>>>>> On Wednesday, November 13, 2013 10:30:07 PM UTC-5, >>>>>> [email protected] wrote: >>>>>>> >>>>>>> Mark, >>>>>>> Near as I can tell, no one has done better than just file i/o via >>>>>>> /dev/i2c/... This works, but doesn't seem to expose or take advantage >>>>>>> of >>>>>>> the Invensense kernel driver functionality. Plus it seems to be very >>>>>>> slow. Jason Kridner was tackling it a couple weeks ago, but didn't >>>>>>> report >>>>>>> any success. I haven't made any progress either. >>>>>>> Seems we are stuck. I wish someone could figure out how to ping the >>>>>>> author at Invensense. I tried writing via thier support web page but >>>>>>> didn't >>>>>>> get a reply. >>>>>>> Clark >>>>>>> On Tuesday, November 12, 2013 12:57:54 PM UTC-8, Mark A. Yoder wrote: >>>>>>> >>>>>>>> Did anyone every get the inv-mpu6050 kernel driver to work? I have >>>>>>>> the device on the i2c bus and I can read and write registers using >>>>>>>> *i2cset/i2cget*, but *modprobe inv-mpu605* doesn't make anything >>>>>>>> appear. >>>>>>>> >>>>>>>> --Mark >>>>>>>> >>>>>>>> On Saturday, November 2, 2013 11:51:04 AM UTC-4, >>>>>>>> [email protected] wrote: >>>>>>>>> >>>>>>>>> Jason, >>>>>>>>> I apologize for taking so long to answer. It wasn't quick to >>>>>>>>> figure out which breakout board we had with the MPU6050 on it. It is >>>>>>>>> apparently a Kootek® Arduino GY-521 MPU-6050 Module from Amazon. >>>>>>>>> Itis wired: >>>>>>>>> >>>>>>>>> P9_1->Gnd >>>>>>>>> >>>>>>>>> P9_3->VCC >>>>>>>>> >>>>>>>>> P9_19 ->SCL >>>>>>>>> >>>>>>>>> P9_20 -> SDA >>>>>>>>> >>>>>>>>> Your P9_19 SCL and P9_20 SDA should be fine. >>>>>>>>> >>>>>>>>> Later posts suggest you can talk to you device and have shown us >>>>>>>>> via W Smith the way to straighten out which bus is which. >>>>>>>>> >>>>>>>>> Clark >>>>>>>>> On Thursday, October 31, 2013 1:32:46 PM UTC-7, 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/grou >>>>>>>>>> ps/opt_out. >>>>>>>>>> >>>>>>>>> -- >>> For more options, visit http://beagleboard.org/discuss >>> --- >>> You received this message because you are subscribed to a topic in the >>> Google Groups "BeagleBoard" group. >>> To unsubscribe from this topic, visit https://groups.google.com/d/ >>> topic/beagleboard/hqqecmOjpTU/unsubscribe. >>> To unsubscribe from this group and all its topics, send an email to >>> [email protected]. >>> >>> For more options, visit https://groups.google.com/groups/opt_out. >>> >> >> >> >> -- >> Best Wishes, >> Andrew >> > -- > For more options, visit http://beagleboard.org/discuss > --- > You received this message because you are subscribed to a topic in the > Google Groups "BeagleBoard" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/beagleboard/hqqecmOjpTU/unsubscribe. > To unsubscribe from this group and all its topics, send an email to > [email protected]. > For more options, visit https://groups.google.com/groups/opt_out. > -- Best Wishes, Andrew -- 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.
