Re: [Gumstix-users] Some 'getting started' questions regarding Overo SPI/PWM

[Curtis O. <cur...@gm...>]

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. :-)

Thanks!

Curt.


On Wed, Mar 7, 2012 at 1:33 PM, Adam McLeod <mcl...@gm...> wrote:

> Hello,
>
>  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
> online.
>
> Thanks.
>
>
> ------------------------------------------------------------------------------
> 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.
> http://www.accelacomm.com/jaw/sfnl/114/51521223/
> _______________________________________________
> gumstix-users mailing list
> gum...@li...
> https://lists.sourceforge.net/lists/listinfo/gumstix-users
>



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