Hi Adam, a quick reply -- I am sure there are others here that know way more than me and can correct anything I'm mistaken about.

1) You mention PWM -- I'm going to assume RC servos?  If that's a bad assumption sorry.  Last fall (time flies!) Scott from jumpnowtek helped me get started on PWM and timers.  I was attempting to drive servos from a generica overo GPIO line using the hrtimer + interrupts to schedule the line state changes.  However, I never could get sufficient clock resolution to drive the servo positions stably.

2) After giving up on that I spent some time making the 4 overo outputs that support PWM signal generation in hardware working.  I believe some of the core of my changes made it back into Scott's demo driver.  Essentially what I worked on was doing all 4 channels from a single driver and getting the pulse resolution down to 0.1us (with the servo pulse range from approximately 900us to 2100us with 1500us being approximately center.)  0.1us resolution on the hardware signal, but I believe most RC servos wouldn't show a this fine grained of a difference -- but what the heck -- since I had my head buried in the code, I figured I'd try to squeeze the best I could out of it.  This again is targeted towards generating PWM signals appropriate for driving an RC servo.

3) I'm just now trying to get SPI running betwen the overo and an IMU (vectornav).  If anyone else has this combination working, I'd love to hear from you.  I've been attempting to use sparkfun level converters to convert the 1.8v signals to 3.3v and visa versa, but I'm not getting any reliable communication.  I hope the problem is that these level converters just aren't up to snuff in this voltage range (they are primarily optimized for 3.3v to 5v level conversion.)  I have a different level converter on order (8 channel bi-directional break out board from adafruit) -- hopefully that will be here be the end of the week and I can resume hacking on this.

4) I did build the whole open-embedded tree here.  There is some sensitivity to dependencies and there are issues.  It's hard to fault open-embedded on all of them, although I think they could work harder to keep everything current.  As the version of gcc and system libraries continually march forward on people's systems, the versions of software ported to open-embedded start becoming harder to build for many different reasons.  Linux distributions can be very dynamic as they race to keep up with all the latest versions of all the tools and kernels and everything else out there.

5) with the whole open-embedded tree in place, you will have cross compilers for your system which are what you want to call when you compile driver code or application code for the overo.  Are the cross compiler tools available as a download from gumstix?  That's a question -- seems like I've seen reference to this, but I've never tried to actually find them or make them work myself.

Hope that helps, and hope others can fill in the gaps in my knowledge or clarify my misconceptions. :-)



On Wed, Mar 7, 2012 at 1:33 PM, Adam McLeod <mcleod.a@gmail.com> wrote:

 I'm trying to use an Overo as a basic motion controller, and to do
that I need to utilize the Overo's SPI and PWM capabilities.  I've
never developed for an Overo before (but I did do some work with a
Gumstix Basix back in 2007), and I'm having trouble getting oriented.
I hope someone can answer a couple basic questions for me:

1.) I gather that SPI functionality requires an SPI driver, which I
should make myself by modifying the code hosted at jumpnowtek.com.
Must I have OpenEmbedded installed to develop this driver?

2.) I tried to build an image with OpenEmbedded, and the process
seemed very shaky, and failure prone.  Building the Overo image took
days, and quit every couple of hours due to not being able to find a
package.  I frequently had to go find the package myself and put it in
the OE package directory.  When the build finally completed, the
entire setup had balooned to 30Gb.  Is this how it's supposed to work?

3.) Likewise with PWM, I'm not sure of what my workflow should be.  Do
I need a full OpenEmbedded environment to get PWM functionality, or
can I get away with downloading some libraries from somewhere
(Angstrom?), compiling my code natively or via a cross-compiler, and
loading kernel modules dynamically?

Thanks for any help.  I think that once I'm sure of the high-level
steps in the process of developing an Overo application that uses SPI
and PWM, I can get a lot more out of the documentation available


Virtualization & Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing
also focuses on allowing computing to be delivered as a service.
gumstix-users mailing list

Curtis Olson:
http://www.atiak.com - http://aem.umn.edu/~uav/
http://www.flightgear.org - http://gallinazo.flightgear.org