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] <javascript:>>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/+/ >>>>> 74f15aa73e1d999368e3a8287cdb85718e987d48/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/ >>>>>>>>> groups/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] <javascript:>. >> 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.
