Re: [beagleboard] GPIO poll for interrupts fails

[clarkbriggs101]

Jason,
Good input. Out of respect for your big picture view point, it is in 
progress.
librobotcontrol currently uses chardev ioctl. I got that working for my 
simple single interrupt response demonstrator since he has all that worked 
out. Then I went on to gpiod and I think I have gpiod working in that 
simple single gpio interrupt test environment. For Blue. 
StrawsonDesign & the resulting librobotcontrol has used sysFS for access to 
non-gpio stuff, specifically pwms. What do you see for such other non-gpio 
stuff in sysFS?
My original submission here included an argument for doing this task with 
RPis too. The code base using any of the three gpio access methods seems to 
work on RPi. The gpio configuration environment in Raspbian is quite 
different however. They specifically don't expose pinmux functionality. I 
still struggle with how in the heck that community deals with gpio 
configurating. The mode map is well exposed, but how to take advantage of 
it isn't. What physical header pin does what in what mode is well 
documented, but how to set things up for that mode isn't.  I find that 
commandeering pins by enabling kernel drivers works. I can pick pins for 
the software rotary-encoder driver in the boot config and apparently get 
them. Same with the pwm driver. There isn't such a mechanism for free gpio 
pins to use for exercises such as the simple gpio interrupt response 
demonstrator.
You and others in BB territory may not have much interest in figuring out 
the RPi equivalent to the (wonderful, highly functional, really nice) 
Beaglebone environment unless we adopt my proposed make-it-do-both 
approach. The alternative of asking the RPi community doesn't appear to be 
promising because they focus on so many other IoT applicatios and are not 
pursing bots in any similar fashion. 
BeagleBoard might well not be interested, but a number of potential 
university adoptors of BB appear to be. Our friends at UCSD seem to. And 
his efforts to export to other universities has found professors with a 
pre-existing base in RPis. Where I am now, we are struggling with focussing 
on one or hedging our bets with the two.
What guidance would you provide on this front?
Clark

On Friday, June 19, 2020 at 4:06:09 PM UTC-6, Jason Kridner wrote:
>
>
>
> On Fri, Jun 19, 2020 at 5:18 PM > 
> wrote:
>
>> Folks,
>> Any help would be appreciated. I've Googled, studied, and stared for many 
>> hours.
>> Problem: Using poll to watch a GPIO pin for change, poll returns 
>> "immediately" and persistently, with no value change, with POLLPRI set.
>>
>
> Please consider using libgpiod. 
>
> Background: This is a prep stage for implementing a software encoder 
>> counter where 2 GPIOs are connected to an external rotary encoder with 
>> leads A and B. I am working on a user space quadrature encoder routine 
>> based on the Linux driver rotary_encoder.c logic. It didn't work and I 
>> traced it to failing to respond to the GPIO edge events using poll. I made 
>> a single GPIO interrupt response demonstrator (shown excerpted below) and 
>> it doesn't work either. Further, it doesn't work on either Beaglebone Blue 
>> or Raspberry Pi 3.
>> Hardware: The Blue shows ' uname -a
>> Linux blue1 4.19.94-ti-r42 #1buster SMP PREEMPT Tue Mar 31 19:38:29 UTC 
>> 2020 armv7l GNU/Linux'
>> The RPi shows ' uname -a
>> Linux raspberrypi 4.19.93-v7+ #1290 SMP Fri Jan 10 16:39:50 GMT 2020 
>> armv7l GNU/Linux'
>> Both have the same wheel encoders (Pololu Romi encoders  item #3542 or 
>> its 2.7v version). Both bots will correctly read the encoders. The Blue 
>> using the hardware encoder and the RPi via the software driver 
>> rotary-encoder. For this demonstrator, the Blue uses other GPIOs, 
>> specifically GP0.3 and GP0.4. Signal changes on these GPIOs are read 
>> correctly in the gpioN/value register via manual testing. The RPi uses the 
>> same GPIOs (2 or 3) as the encoder driver, but with the driver disabled to 
>> eliminate the competition.
>> Furthermore: This has been a long standing software challenge. Googling 
>> shows many things one needs to know. GPIOs in sysFS are deprecated, but 
>> they still work. Setting an edge is what enables polling on the value to 
>> pick up the transition. Initial reads are required to clear initial 
>> spurious values. sysFS requires POLLPRI events, since POLLIN always returns 
>> for sysFS. sysFS always returns POLLERR which can be ignored. One must 
>> LSEEK on the value fd before reading the value. One must read the value, 
>> wanted or not.
>> Notes on the demonstrator code: I have been working on a common hardware 
>> interface module to support bots built on Blue and RPi. I have long been 
>> following StrawsonDesign's librobotcontrol. This code uses a few routines 
>> from Strawson. One is a function to tell whether the hardware is Beaglebone 
>> or RPI and another to launch a thread. I don't show them here. I have 
>> elided all the error handling snippets, replacing them with "gripe" 
>> 

[beagleboard] GPIO poll for interrupts fails

[clarkbriggs101]

Folks,
Any help would be appreciated. I've Googled, studied, and stared for many 
hours.
Problem: Using poll to watch a GPIO pin for change, poll returns 
"immediately" and persistently, with no value change, with POLLPRI set.
Background: This is a prep stage for implementing a software encoder 
counter where 2 GPIOs are connected to an external rotary encoder with 
leads A and B. I am working on a user space quadrature encoder routine 
based on the Linux driver rotary_encoder.c logic. It didn't work and I 
traced it to failing to respond to the GPIO edge events using poll. I made 
a single GPIO interrupt response demonstrator (shown excerpted below) and 
it doesn't work either. Further, it doesn't work on either Beaglebone Blue 
or Raspberry Pi 3.
Hardware: The Blue shows ' uname -a
Linux blue1 4.19.94-ti-r42 #1buster SMP PREEMPT Tue Mar 31 19:38:29 UTC 
2020 armv7l GNU/Linux'
The RPi shows ' uname -a
Linux raspberrypi 4.19.93-v7+ #1290 SMP Fri Jan 10 16:39:50 GMT 2020 armv7l 
GNU/Linux'
Both have the same wheel encoders (Pololu Romi encoders  item #3542 or its 
2.7v version). Both bots will correctly read the encoders. The Blue using 
the hardware encoder and the RPi via the software driver rotary-encoder. 
For this demonstrator, the Blue uses other GPIOs, specifically GP0.3 and 
GP0.4. Signal changes on these GPIOs are read correctly in the gpioN/value 
register via manual testing. The RPi uses the same GPIOs (2 or 3) as the 
encoder driver, but with the driver disabled to eliminate the competition.
Furthermore: This has been a long standing software challenge. Googling 
shows many things one needs to know. GPIOs in sysFS are deprecated, but 
they still work. Setting an edge is what enables polling on the value to 
pick up the transition. Initial reads are required to clear initial 
spurious values. sysFS requires POLLPRI events, since POLLIN always returns 
for sysFS. sysFS always returns POLLERR which can be ignored. One must 
LSEEK on the value fd before reading the value. One must read the value, 
wanted or not.
Notes on the demonstrator code: I have been working on a common hardware 
interface module to support bots built on Blue and RPi. I have long been 
following StrawsonDesign's librobotcontrol. This code uses a few routines 
from Strawson. One is a function to tell whether the hardware is Beaglebone 
or RPI and another to launch a thread. I don't show them here. I have 
elided all the error handling snippets, replacing them with "gripe" 
comments.
The program follows the StrawsonDesign librobotcontrol rc_test examples. In 
this case, the main checks inputs, sets up hardware, launches a worker 
thread, then waits for the user to quit via Ctrl-C. Here the worker thread 
sets up a repeated poll loop. In the eventual quadrature application, the 
GPIO events feed the quadrature state machine of rotary-encoder.c. A short 
timeout is set for my use so the thread can be readily killed by the main 
application, independent of GPIO arrivals. The version here leaves the 
GPIOs set up upon completion so we can inspect the state of things. The 
Blue has pinmux helpers for the user GPIOs on GP0 and GP1 which are used to 
set them to GPIO mode. The RPi doesn't do that. Apparently user GPIOS are 
pre-set up.
The code produces the same result on both machines. The read after poll 
always fails with return -1. The event is 0x0a which is POLLPRI | POLLERR. 
While it  does stream fast, I can never see a response to manually fiddling 
with the physical inputs. It never reports time out.
OBTW, if you can see into what is going on here, think about how this works 
when I switch to SCHED_FIFO. All my bot threads run in this 'realtime' 
mode. For a software encoder that responds to GPIO interrupts, I think this 
doesn't present any problem that isn't already presented by all the other 
threads. On RPi, tho, the kernel catches the GPIO interrupts and runs the 
quadrature logic, only letting the user's poll get control after a complete 
turn of +1 or -1 occurs. I presume the rotary-encoder driver runs at kernel 
priority level, which is below the worker thread. At least, if my app 
consumes too much CPU, the kernel can't keep with its many functions, one 
of which is this driver. I have done that in the past. Let's get this code 
to work, then I'd like help thinking through this and its impact on CPUs 
like Blue and RPi. Because I'm getting lots of input about the CPU load of 
a software rotary encoder.
So, needless to say, I don't get it. I hope someone can see what I'm 
missing. I need to get past this and get back to making bots go.
/**
 * @excerpts from my_test_gpio_interrupts.c
 * as of 19 June 2020
 *
 * Demonstrates use sysFS to respond to  
 * gpio interrupts. Instructions are printed to the screen when called.
 */


#include 
#include 
#include 
#include  // for atoi
#include 
#include  //usleep, nanosleep
#include// read event thread
#include  // interrupt events in read event thread

int running = 

[beagleboard] Re: BBB USB WiFi

[clarkbriggs101]

After fiddling around, this works with newer BBB boards and the same 
dongle. The connmanctl instructions in /etc/network/interfaces work just 
fine, with newer boards. Any idea what is different about older BBBs? I did 
this on a power plug. They all have Robotics Capes and the newer ones will 
do WiFi when running off the battery.
Clark

On Thursday, March 22, 2018 at 3:32:09 PM UTC-7, Hugh Briggs wrote:
>
> Yes I know this is an old topic, or chronic. I am trying to revive a batch 
> of BBBs. I got the current image and am running them off an SD card. I have 
> the USB Wifi dongles from back in the day. By memory we got them to work ok 
> enough. Where can I find the current BBB wifi setup instructions? This has 
> changed a number of times over the migration to current Debian. The dongle 
> isn't technically on the supported list. It is labeled Comfast CF-WU720N. 
> The manufacturer's web site says it uses the Raylink 5370 chipset. On boot 
> it is identified and invokes the rt2800usb kernel module. The dongle has a 
> little blue activity or power light that doesn't come on now. By memory, 
> this all worked but we had some initial issues with power management or 
> something that controlled turning it on. I'd really like to use them. 
> Pointers would be appreciated.
> Clark
>
>

-- 
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 beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/a9a3ffd8-98df-48ee-bb71-f6c8e3b8e2f4%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] USB networking

[clarkbriggs101]

(my apologies. I originally posted this under Beagle Board. If you can 
clean that up, please delete it.)
Did it ever get figured out how to make a network via USB?  That is, I'd 
use a USB hub to lash up several (BBBs which I have passel of) as a single 
subnet.  This is in lieu of either a real Enet or wifi subnet. It seems the 
formula has to do with who (BBB or PC) owns the DHCP server and feels like 
a gateway. Where is that stuff configured on the BBB side. I might leave 1 
BBB doing that, and config the others to be clients. I never figured out 
how to configure the PC side, but maybe that isn't an issue.  For example, 
I don't expect to get the PC to do routing for the USB subnet out to the 
bigwideworld.  Getting a BBB with WiFi also to do routing might be a worth 
while follow on exercise.
Clark

-- 
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 beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/4e6cc91f-a0d3-4131-a05d-cf4d0da8391b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] USB networking

[clarkbriggs101]

Did it ever get figured out how to make a network via USB?  That is, I'd 
use a USB hub to lash up several (BBBs which I have passel of) as a single 
subnet.  This is in lieu of either a real Enet or wifi subnet. It seems the 
formula has to do with who (BBB or PC) owns the DHCP server and feels like 
a gateway. Where is that stuff configured on the BBB side. I might leave 1 
BBB doing that, and config the others to be clients. I never figured out 
how to configure the PC side, but maybe that isn't an issue.  For example, 
I don't expect to get the PC to do routing for the USB subnet out to the 
bigwideworld.  Getting a BBB with WiFi also to do routing might be a worth 
while follow on exercise.
Clark

-- 
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 beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/9baede1d-e30d-4443-b59b-09e57e70b4fd%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] BBB USB WiFi

[clarkbriggs101]

Yes I know this is an old topic, or chronic. I am trying to revive a batch 
of BBBs. I got the current image and am running them off an SD card. I have 
the USB Wifi dongles from back in the day. By memory we got them to work ok 
enough. Where can I find the current BBB wifi setup instructions? This has 
changed a number of times over the migration to current Debian. The dongle 
isn't technically on the supported list. It is labeled Comfast CF-WU720N. 
The manufacturer's web site says it uses the Raylink 5370 chipset. On boot 
it is identified and invokes the rt2800usb kernel module. The dongle has a 
little blue activity or power light that doesn't come on now. By memory, 
this all worked but we had some initial issues with power management or 
something that controlled turning it on. I'd really like to use them. 
Pointers would be appreciated.
Clark

-- 
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 beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/7eae76ad-7110-4d68-af59-f63a32953008%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Running off an SD card

[clarkbriggs101]

Folks,
I am trying to revive a batch of old BBBs. I put the current image on an SD 
card for it to live on. The original handshake of hold the user button 
while booting is required to make it boot from the SD card. It does that 
and I expanded the fs to the whole card size, etc.
But on most boots, I still have to hold that button.  Back when they were 
fresh, it seemed like it let go of that behavior. How do I get it to just 
boot the SD card automatically?
Clark
Clark Briggs

-- 
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 beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/a3abbc59-d03d-478f-b679-7fa3fe42e963%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] recommendation for a symbolic debugger

[clarkbriggs101]

John,
Thanks. It does sound like you know the TI CCS stuff. While the TI market 
place exposed several high level products, I can't figure out how to drill 
down to the compiler. In particular, I think I installed for the AM33xx BBB 
processor when I first put CCS in, but can't find any trace of the 
processor family in the configuration.  Further, I don't find any settings 
for the target OS.  I am using CCS on Windows and targeting Debian on the 
BBB.
Like I said, this is a complex and maybe unusual configuration (source 
debugging remotely but compiling natively on the target), so I wanted to 
try a cross compile for helloworld.c but can't find the TI compiler in the 
development environment. I figured if that worked, the right gdb would be 
there and I could try living with a (nicely set up by TI) cross development 
environment.
So...how to put just the right cross compiler in this existing CCS install?
Thanks,
Hugh/Clark

On Tuesday, August 1, 2017 at 2:24:49 PM UTC-7, john3909 wrote:
>
> You need arm-linux-gnueabihf-gdb and it needs to be the same as your 
> compiler version used to build your executable. 
>
> Regards,
> John
>
>
>
>
> On Aug 1, 2017, at 1:44 PM, clarkbr...@gmail.com  wrote:
>
> William etal,
> Pointing to Molloy was a good hint. I watched him do it and around minute 
> 31 he starts into remote debugging. He uses Eclipse and some cross tool 
> chain, but I didn't watch that. I am using the TI CCS v7.2 on Windows 7x64 
> which is Eclipse based, but not cross compiling with their included tools.
> My configuration is somewhat different from Molloy's. He is cross 
> compiling so the sources AND the binary are present on the dev machine with 
> Eclipse. I have only the sources on my dev machine since I compile on the 
> BBB.
> Issue 1. When creating a remote debug configuration in CCS/Eclipse the 
> Main tab field "C/C++ Application:" apparently wants the local binary on 
> the dev machine. It isn't happy without it and won't move forward at all. 
> If I drag the binary from the BBB back to the dev workspace and point at 
> it, it will go on. 
> What is the correct way to configure this environment (source and dbg on 
> Win dev host; source, binaries and gdbserver on BBB)?
> Issue 2. So with a copy of the application binary on the dev host, 
> launching a remote debugging session leads to a gripe from the gdbserver 
> about not understanding the MI command list-features.  The console shows 
> the connection on the BBB target successfully launches gdbserver with the 
> configured port, the absolute path to the executable and the arguments. 
> After the "listening on port 2345" echo it terminates with the gripe about 
> the MI command.
> Groping der google suggests this is often due to not having the correct 
> architecture gdb on the dev host selected. When installing CCSv7 I picked 
> only the arm tools for the AM33xx family processor. In the debug 
> configuration debugger tab main tab GDB debugger is the default setting 
> "gdb".  There is a Browse button to go looking through the installed 
> ti/ccsv7/tools/compiler, but the only gdb in the TI tools I can find is 
> C:\ti\ccsv7\tools\compiler\gcc-arm-none-eabi-6-2017-q1-update\bin\arm-none-eabi-gdb.exe.
>  
> that gdb echoes as it starts "This GDB was configured as 
> "--host=i686-w64-mingw32 --target=arm-none-eabi"." then warns "warning: A 
> handler for the OS ABI "GNU/Linux" is not built into this configuration of 
> GDB. Attempting to continue with the default arm settings." It then quits 
> with a complaint that no source was available.
> Maybe this is really a TI CCS specific setting. Earlier John pointed to 
> CCS so maybe he can provide some direction.
> Thanks,
> Hugh
>
> On Thursday, July 27, 2017 at 4:14:58 PM UTC-7, William Hermans wrote:
>
>>
>>
>> On Thu, Jul 27, 2017 at 4:13 PM, William Hermans  
>> wrote:
>>
>>> This is probably the best guide you're going to find on the subject.
>>>
>>> https://www.youtube.com/watch?v=T9yFyWsyyGk
>>>
>>> Never used it myself( I do not cross compile ), but I'm confident DR 
>>> Molly's instructions work.
>>>
>>
>> Just in case it's not clear, R Molly shows how to setup remote debugging 
>> towards the end I think. Been a while since I've watched this. 
>>
>>
> -- 
> 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 beagleboard...@googlegroups.com .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/beagleboard/fa591c36-14bb-4237-8286-0076e36c4407%40googlegroups.com
>  
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>
>
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You 

Re: [beagleboard] Blue booting as Robot controller vs. booting as Linux computer

[clarkbriggs101]

I found Jason's hint to be a bit short on explanations, so here is what 
Robert Nelson led me through. It is was I reported that I did with a BBB + 
Robotic Cape but didn't know if it would work with a Blue. I take Jason's 
answer to be yes it will work with a Blue.
On July 11 Robert wrote in my earlier email stream titled "where is 
capemgr?"

It's not a service file, it's the device tree binary: 

https://github.com/RobertCNelson/dtb-rebuilder/blob/4.4-ti/src/arm/am335x-boneblack-roboticscape.dts#L19
 

Change: 

#include "am335x-bone-common-no-capemgr.dtsi" 

to: 

#include "am335x-bone-common.dtsi"

He also led me through how to compile it and boot it, etc. I won't try to 
repeat that here from memory.
Then do the usual capemgr boot line directive with partno=BB-ADC

I still believe that this configuration can live with the rc_* apps and 
services, as long as you only use one at a time.
Turns out we haven't been hearing from James (the rc_* creator) on this 
because he is way way way out of the county for the summer.
Clark



On Thursday, August 3, 2017 at 9:25:18 PM UTC-7, Jason Kridner wrote:
>
>
>
> On Aug 3, 2017, at 4:57 PM, Mark A. Yoder  > wrote:
>
> Sounds like a good idea.  How do I turn on the ADC drivers?
>
>
>
> https://github.com/RobertCNelson/dtb-rebuilder/blob/4.4-ti/src/arm/am335x-boneblack-custom.dts#L56
>
>
> --Mark
>
> On Thursday, August 3, 2017 at 2:45:44 PM UTC-4, Jason Kridner wrote:
>>
>>
>>
>> On Aug 3, 2017, at 2:32 PM, Mark A. Yoder  wrote:
>>
>> It looks like when the Blue comes out of the box, running a current image 
>> it's all set up to run the Robotics stuff. You can access the ADCs, servos, 
>> etc. through the robot interface.
>>
>> When I teach my Embedded Linux class I would also like my students to 
>> access the ADCs, PWM, etc in the Linux way.  
>>
>> *How do I configure the Blue to boot up in "Embedded Linux" mode rather 
>> than "Robot Linux" mode*?
>>
>>
>> If we get the integration right, IMO, we'll boot up so that we can use 
>> the Linux userspace interfaces and the libroboticscape interfaces. The 
>> libroboticscape setup should do whatever is needed to disable Linux kernel 
>> drivers at runtime in order to enable its userspace accesses. 
>>
>> Turn on the ADC kernel drivers and look how libroboticscape fails. Then, 
>> report that as a bug. 
>>
>>
>>
>> --Mark
>>
>>
>> On Wednesday, August 2, 2017 at 11:15:40 AM UTC-4, Mark A. Yoder wrote:
>>>
>>> It sounds like I can either have a Blue that boots as a robot, or boots 
>>> as an embedded processor, but not both at the same time.
>>> I need to see what it would take to remove the ADC from the robots 
>>> control.
>>>
>>> --Mark
>>>
>>> On Tuesday, August 1, 2017 at 4:57:09 PM UTC-4, Hugh Briggs wrote:

 I have lived on BBB + Robotics Cape in James' world for some time. 
 While I haven't done this with a Blue, I suspect what I did can work there 
 too. I did do his installation (for a Rev C BBB and a Rev D Robotics 
 Cape). 
 With Robert's help I put the Capemgr back in the DTs and added the capemgr 
 partno boot line for BB-ADC.  This seems to be a workable combination of 
 the two worlds. My premise is that I don't try to do both at once.  That 
 is, I don't run any of the rc_* apps or services while trying to read the 
 ADCs from /sys/bus/iio. So far it seems to work for me.
 Hugh

 On Monday, July 31, 2017 at 11:44:09 AM UTC-7, Mark A. Yoder wrote:

> Yup, this is the Blue.
> In there short term is there an easy way to turn off the robotics 
> stuff and get easy access to the analog in?
>
> In the long term, what will it take to convert James' robot stuff to 
> libiio?  I might take a shot at it if it isn't too hard.
>
> --Mark
>
> On Friday, July 28, 2017 at 5:56:30 PM UTC-4, RobertCNelson wrote:
>>
>> On Fri, Jul 28, 2017 at 4:40 PM, Mark A. Yoder  
>> wrote: 
>> > How do I read AIN on the latest images?  I don't know where to find 
>> it in 
>> > /sys/ 
>>
>> Hi Mark, 
>>
>> This is with the Blue right? 
>>
>> James' got the ADC tied up in mmap for the Robotic's cape library.. 
>>
>>
>> https://github.com/StrawsonDesign/Robotics_Cape_Installer/blob/master/libraries/mmap/rc_mmap_gpio_adc.c
>>  
>>
>> We need to convert his library to use libiio, then we can just enable 
>> the ADC's as an iio device and share usage with the library.. 
>>
>> https://analogdevicesinc.github.io/libiio/ 
>>
>> Regards, 
>>
>> -- 
>> Robert Nelson 
>> https://rcn-ee.com/ 
>>
> -- 
>> 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 

Re: [beagleboard] Reading analog in on the stretch (9.1) images

[clarkbriggs101]

I have lived on BBB + Robotics Cape in James' world for some time. While I 
haven't done this with a Blue, I suspect what I did can work there too. I 
did do his installation (for a Rev C BBB and a Rev D Robotics Cape). With 
Robert's help I put the Capemgr back in the DTs and added the capemgr 
partno boot line for BB-ADC.  This seems to be a workable combination of 
the two worlds. My premise is that I don't try to do both at once.  That 
is, I don't run any of the rc_* apps or services while trying to read the 
ADCs from /sys/bus/iio. So far it seems to work for me.
Hugh

On Monday, July 31, 2017 at 11:44:09 AM UTC-7, Mark A. Yoder wrote:

> Yup, this is the Blue.
> In there short term is there an easy way to turn off the robotics stuff 
> and get easy access to the analog in?
>
> In the long term, what will it take to convert James' robot stuff to 
> libiio?  I might take a shot at it if it isn't too hard.
>
> --Mark
>
> On Friday, July 28, 2017 at 5:56:30 PM UTC-4, RobertCNelson wrote:
>>
>> On Fri, Jul 28, 2017 at 4:40 PM, Mark A. Yoder  
>> wrote: 
>> > How do I read AIN on the latest images?  I don't know where to find it 
>> in 
>> > /sys/ 
>>
>> Hi Mark, 
>>
>> This is with the Blue right? 
>>
>> James' got the ADC tied up in mmap for the Robotic's cape library.. 
>>
>>
>> https://github.com/StrawsonDesign/Robotics_Cape_Installer/blob/master/libraries/mmap/rc_mmap_gpio_adc.c
>>  
>>
>> We need to convert his library to use libiio, then we can just enable 
>> the ADC's as an iio device and share usage with the library.. 
>>
>> https://analogdevicesinc.github.io/libiio/ 
>>
>> Regards, 
>>
>> -- 
>> Robert Nelson 
>> https://rcn-ee.com/ 
>>
>

-- 
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 beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/e2d3829f-6af9-4c00-b63d-4ec891db2be7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] recommendation for a symbolic debugger

[clarkbriggs101]

William etal,
Pointing to Molloy was a good hint. I watched him do it and around minute 
31 he starts into remote debugging. He uses Eclipse and some cross tool 
chain, but I didn't watch that. I am using the TI CCS v7.2 on Windows 7x64 
which is Eclipse based, but not cross compiling with their included tools.
My configuration is somewhat different from Molloy's. He is cross compiling 
so the sources AND the binary are present on the dev machine with Eclipse. 
I have only the sources on my dev machine since I compile on the BBB.
Issue 1. When creating a remote debug configuration in CCS/Eclipse the Main 
tab field "C/C++ Application:" apparently wants the local binary on the dev 
machine. It isn't happy without it and won't move forward at all. If I drag 
the binary from the BBB back to the dev workspace and point at it, it will 
go on. 
What is the correct way to configure this environment (source and dbg on 
Win dev host; source, binaries and gdbserver on BBB)?
Issue 2. So with a copy of the application binary on the dev host, 
launching a remote debugging session leads to a gripe from the gdbserver 
about not understanding the MI command list-features.  The console shows 
the connection on the BBB target successfully launches gdbserver with the 
configured port, the absolute path to the executable and the arguments. 
After the "listening on port 2345" echo it terminates with the gripe about 
the MI command.
Groping der google suggests this is often due to not having the correct 
architecture gdb on the dev host selected. When installing CCSv7 I picked 
only the arm tools for the AM33xx family processor. In the debug 
configuration debugger tab main tab GDB debugger is the default setting 
"gdb".  There is a Browse button to go looking through the installed 
ti/ccsv7/tools/compiler, but the only gdb in the TI tools I can find is 
C:\ti\ccsv7\tools\compiler\gcc-arm-none-eabi-6-2017-q1-update\bin\arm-none-eabi-gdb.exe.
 
that gdb echoes as it starts "This GDB was configured as 
"--host=i686-w64-mingw32 --target=arm-none-eabi"." then warns "warning: A 
handler for the OS ABI "GNU/Linux" is not built into this configuration of 
GDB. Attempting to continue with the default arm settings." It then quits 
with a complaint that no source was available.
Maybe this is really a TI CCS specific setting. Earlier John pointed to CCS 
so maybe he can provide some direction.
Thanks,
Hugh

On Thursday, July 27, 2017 at 4:14:58 PM UTC-7, William Hermans wrote:

>
>
> On Thu, Jul 27, 2017 at 4:13 PM, William Hermans  > wrote:
>
>> This is probably the best guide you're going to find on the subject.
>>
>> https://www.youtube.com/watch?v=T9yFyWsyyGk
>>
>> Never used it myself( I do not cross compile ), but I'm confident DR 
>> Molly's instructions work.
>>
>
> Just in case it's not clear, R Molly shows how to setup remote debugging 
> towards the end I think. Been a while since I've watched this. 
>
>

-- 
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 beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/fa591c36-14bb-4237-8286-0076e36c4407%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] recommendation for a symbolic debugger

[clarkbriggs101]

John,
Thanks a lot.
I am debugging a user space app.
I guess I didn't realize I could use Eclipse on my host and debug on the 
target without the binaries on the host. I do have the sources on my host 
anyway.
I have never heard of CCSV7 but a quick look at 
http://www.ti.com/tool/ccstudio is attractive. I'll check it out.
Thanks,
Clark

On Wednesday, July 26, 2017 at 4:57:41 PM UTC-7, john3909 wrote:

> Are you debugging user space app or kernel code like drivers, kernel 
> modules, etc?
>
> If you are debugging user space app, you have two solutions:
> 1) use gdbserver on your BBB and Code Composer Studio (CCSV7) or Eclipse 
> on your host, which uses gdb for debugging. You will need your BBB source 
> code on your host. I recommend that you use NFS to host your BBB rootfs on 
> your host machine. 
> 2) use USB200 JTAG debugger and use CCSV7 for debugging.
>
> For kernel code debugging, you can use 2) above, but the debugging is 
> limited because CCSV7 isn’t kernel aware. 
>
> Regards,
> John
>
>
>
>
> On Jul 26, 2017, at 4:34 PM, clarkbr...@gmail.com  wrote:
>
> I really need to have a symbolic interface to gdb running on my BBBs.  
> Here is my situation.
> I keep build copies of the software on the BBB and compile them on the BBB.
> I edit them on my PC, keeping the masters in a local repo. I manually move 
> them over after editing to compile them on the BBB.
> I have tried debugging on the BBB with gdb and its command line interface 
> but the code has gotten too complicated nowadays.
> I am running the 2017-03-19 image with updates. I am concerned about the 
> file space remaining on the BBB so I don't want a big app on the BBB.
> I can do X to my desktop, so an X frontend to dbg seems like the best 
> answer.
> In other situations, I have used Eclipse CDT on my dev station (that was a 
> Ubuntu box) but cross compiling and remote debugging were a problem. I 
> ended up pushing the sources over and compiling over on the BBB and never 
> remote debugged.
> Now I have a Windows dev station and I could put Eclipse on it, but things 
> like cross compiling would be a disaster.
> I push the BBB pretty hard with my app. The BBB is only a single 
> processor.  Whatever the front end it shouldn't take a lot of cpu. I guess 
> during debugging sessions, the cpu load is excusable tho.
> I don't think the file space for putting Eclipse CDT on the BBB is 
> affordable, otherwise I like running Eclipse on the BBB. I can teach 
> Eclipse where my repo is. I could run it via X from my PC.
> I could rebuild the bots but use a big SD card so file space isn't a 
> problem. I guess I haven't accreted s much stuff that rebuilding would 
> be a set back.
> So what to do?
> Thanks,
> Clark
>
> -- 
> 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 beagleboard...@googlegroups.com .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/beagleboard/08df6016-8563-4d7a-98be-1feffb97e20a%40googlegroups.com
>  
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>
>
>

-- 
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 beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/6feb4433-64ca-488a-94da-7859f82a6442%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] recommendation for a symbolic debugger

[clarkbriggs101]

I really need to have a symbolic interface to gdb running on my BBBs.  Here 
is my situation.
I keep build copies of the software on the BBB and compile them on the BBB.
I edit them on my PC, keeping the masters in a local repo. I manually move 
them over after editing to compile them on the BBB.
I have tried debugging on the BBB with gdb and its command line interface 
but the code has gotten too complicated nowadays.
I am running the 2017-03-19 image with updates. I am concerned about the 
file space remaining on the BBB so I don't want a big app on the BBB.
I can do X to my desktop, so an X frontend to dbg seems like the best 
answer.
In other situations, I have used Eclipse CDT on my dev station (that was a 
Ubuntu box) but cross compiling and remote debugging were a problem. I 
ended up pushing the sources over and compiling over on the BBB and never 
remote debugged.
Now I have a Windows dev station and I could put Eclipse on it, but things 
like cross compiling would be a disaster.
I push the BBB pretty hard with my app. The BBB is only a single 
processor.  Whatever the front end it shouldn't take a lot of cpu. I guess 
during debugging sessions, the cpu load is excusable tho.
I don't think the file space for putting Eclipse CDT on the BBB is 
affordable, otherwise I like running Eclipse on the BBB. I can teach 
Eclipse where my repo is. I could run it via X from my PC.
I could rebuild the bots but use a big SD card so file space isn't a 
problem. I guess I haven't accreted s much stuff that rebuilding would 
be a set back.
So what to do?
Thanks,
Clark

-- 
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 beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/08df6016-8563-4d7a-98be-1feffb97e20a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] where is capemgr?

[clarkbriggs101]

After watching the great progress, I started in. I have the 3/19/2017 
latest image with apt-get upgrades running on a Rev C BBB with a Rev C 
Robotics Cape. All in all, the process worked well.  But I can't find 
capemgr. I went looking for it because I want to access analog I/O and 
other stuff. Recent emails from here-ish say capemgr is supposed to be in 
/sys/devices/platform but not.  To get analog I/O, I put 
"cape_enable=bone_capemgr.enable_partno=BB-ADC" in uEnv.txt, but no 
/sys/bus/iio.
some info
debian@sim15:~$ uname -a
Linux sim15 4.4.54-ti-r93 #1 SMP Fri Mar 17 13:08:22 UTC 2017 armv7l 
GNU/Linux
debian@sim15:~$ cat /etc/dogtag
BeagleBoard.org Debian Image 2017-03-19
debian@sim15:~$ systemctl status capemgr.service
● capemgr.service - Cape Manager Service
   Loaded: loaded (/lib/systemd/system/capemgr.service; enabled; vendor 
preset: enabled)
   Active: inactive (dead) since Tue 2017-07-11 18:46:54 UTC; 32min ago
  Process: 4598 ExecStart=/bin/sh /opt/scripts/boot/capemgr.sh 
(code=exited, status=0/SUCCESS)
 Main PID: 4598 (code=exited, status=0/SUCCESS)
Jul 11 18:46:53 sim15 systemd[1]: Starting Cape Manager Service...
Jul 11 18:46:54 sim15 systemd[1]: Started Cape Manager Service.

Ideas?
Clark
Clark Briggs
ATA Engineering

-- 
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 beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/87b88838-9b47-4de9-86e5-a0831d27adc5%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: I2C and Invensense MPU6050 Driver

[clarkbriggs101]

I understand the frustration with the Invense driver.  I want to repeat my 
post from earlier (May 6) that the I2C based chips are quite usable with 
direct I2C reads and writes.  I don't like the remaining I2C latency, but 
the chips are quite nice.  We progressed beyond our initial implementation 
(which used the IMU filtered gyros and accels with our own combinatory 
filter) to using the onboard fusion motion processor.  Our fast loop is 
timed by the DMP 200Hz interrupt and directly reads the fused quaternion 
angles via I2C reads.  This moves a lot of arithmetic off of the Black's 
processor.
I think this approach is better than avoiding their products and got us 
moving.
Clark
On Wednesday, October 1, 2014 12:25:17 PM UTC-7, thomas.g...@gmail.com 
wrote:

 Hi, 
 well currently I am working on other projects. 

 To get the invensens driver up and running was a matter of either filling 
 the data necessary for the driver in the platform data (old school) or make 
 the driver aware of device tree information.
 I have quickly had a look at the current implementation of the driver in 
 the current 3.17-rc7 kernel and it still does not support the device tree 
 information, so you will have to do that bit for yourself. 
 Take my patch as a first startup and that should get you working :) 

 have fun, 
 Thomas

 Am Mittwoch, 1. Oktober 2014 15:22:37 UTC+2 schrieb samuel@gmail.com:

 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, thomas.g...@gmail.com 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_multi47670  0 
 libcomposite   14299  1 g_multi
 mt7601Usta601404  0 

 ls /sys/bus/iio/devices/iio:device0/
 buffer in_accel_scale  in_accel_z_rawin_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 

[beagleboard] Re: I2C and Invensense MPU6050 Driver

[clarkbriggs101]

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, kd@gmail.com 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, clarkbr...@gmail.com 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 beagleboard+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: I2C and Invensense MPU6050 Driver

[clarkbriggs101]

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, clarkbr...@gmail.com 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  f0123456789abcdef
 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 

Re: [beagleboard] Re: I2C and Invensense MPU6050 Driver

[clarkbriggs101]

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, clarkbr...@gmail.comwrote:

 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, clarkbr...@gmail.comwrote:

 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 
 jkri...@beagleboard.org wrote: 
  
  On Thu, Oct 17, 2013 at 6:12 PM,  clarkbr...@gmail.com 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 
   herewww.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, 
 clarkbr...@gmail.com 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 
   

Re: [beagleboard] Re: I2C and Invensense MPU6050 Driver

[clarkbriggs101]

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, clarkbr...@gmail.comwrote:

 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 jkri...@beagleboard.org 
 wrote: 
  
  On Thu, Oct 17, 2013 at 6:12 PM,  clarkbr...@gmail.com 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 
   herewww.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, 
   clarkbr...@gmail.comwrote: 
   
   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: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
 

Re: [beagleboard] Re: I2C and Invensense MPU6050 Driver

[clarkbriggs101]

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 
 jkri...@beagleboard.orgjavascript: 
 wrote: 
  
  On Thu, Oct 17, 2013 at 6:12 PM,  clarkbr...@gmail.com javascript: 
 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 
   herewww.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, 
   clarkbr...@gmail.comwrote: 
   
   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 

Re: [beagleboard] I2C and Invensense MPU6050 Driver

[clarkbriggs101]

J.
Ok, but I did the new_device, got a directory entry for 1-0068 (my new 
address), but didn't get anything I recognized as the MPU6050 driver 
functions. Can you guess what caused that? Do they show up in this 1-0068 
dir or somewhere else in the /sysfs? or over in /dev/i2c? If I am 
successful, do you see any reason this will be faster than just file i/o 
thru /dev/i2c?   --Clark
On Tuesday, October 15, 2013 5:33:15 PM UTC-7, Jacek Radzikowski wrote:

 You're barking at a wrong tree. /sys/devices/bone_capmgr.9/slots is used 
 to load device tree overlays and has nothing to do with devices on I2C bus. 
 The correct place to write to instantiate a new i2c device is 
 /sys/bus/i2c/devices/i2c-X/new_device (substitute X with bus number to 
 which the chip is connected). The echo command in your case would look like 
 something like this:

 echo inv-mpu6050 0x68  /sys/bus/i2c/devices/i2c-X/new_device

 j.



 On Tue, Oct 15, 2013 at 6:02 PM, clarkbr...@gmail.com javascript: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. 
 **

 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 beagleboard...@googlegroups.com javascript:.
 For more options, visit https://groups.google.com/groups/opt_out.




 -- 
 Given a choice between two theories, take the one which is funnier 


-- 
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 beagleboard+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[beagleboard] I2C and Invensense MPU6050 Driver

[clarkbriggs101]

 

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. 

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 beagleboard+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.