Re: [Gumstix-users] Testing SPI in Userspace

[Kimberly T. <kim...@gm...>]

Hi Scott -

Thanks so much for your response!

I went ahead and connected all four signals (SCK, MOSI, MISO, CSB) over the
bidirectional tx channels.

I'm not sure what you mean by 3.3v ->1.65v: my understanding was that the
I/O on the 40pin header were all at 1.8V:
http://www.gumstix.net/Hardware/view/I/O-connectors-cabling/Gumstix-Summit-board-40-pin-header-SV1/112.html.
 If that is wrong, I can certainly add a voltage divider to drop down to
1.65V for the lv.  Right now I'm taking my 1.8V and 3.3V power lines
straight from the 40pin header.

So despite the changes to MISO (sorry - wrote the wrong thing yesterday),
I'm still having the same timeout problem, unfortunately.  A total of 3
times, out of about 50 runs, the board did not time out, BUT the contents of
the register 0x20 (which contains the values indirectly read from 0x00  -
 I'm expecting 0x0005, which is what was written in the indirect write),
returns either 0xFFFF or 0x0000.

I'll run down to lab later today and try observing over an oscilloscope -
I've been checking set-up and final conditions with a DMM, and those are as
expected, and I can observe changes on MISO, MOSI, and CSB as the test
program runs, but not SCK, which I believe is due to the frequency at which
the clock changes.

I spent a lot of time looking through the myspy and mcp3002ADC driver code
you posted to the list awhile back, and that helped me kind of understand
what's going on on the driver side, but I'm still struggling a bit with the
userspace side.  Do you by chance know of a test program and it's
anticipated output I could use to figure out if the right data is coming
back in?

Also - am I right in understanding that a direct register read in SPI works
like a direct register read in I2C - like:

    write(device, address, number of words in address); //write should
return the number of words in the address if successful
    read(device, data_buffer, number of words );

And if writes have the proper returns but reads are timing out, then the
error is either: 1.) in the read hardware line (ie MISO is not connected
properly), or 2.) in the sensor board, which is not properly interpreting
the read() command?

Thanks so much!
-Kim

On Tue, Mar 30, 2010 at 9:07 AM, ScottEllis
<sco...@gm...>wrote:

>
> If you have two sparkfun level converters, why didn't you use the last set
> of TX lines for MOSI?
>
> I don't think you can use the RX lines for MOSI from a gumstix. The RX
> lines
> only work from RX_HV -> RX_LV not RX_LV(MO) -> RX_HV (SI).
>
> And the voltages wouldn't be correct even for MISO. It would be 3.3v ->
> 1.65v.
>
> I'm just a software guy though.
>
> --
> View this message in context:
> http://old.nabble.com/Testing-SPI-in-Userspace-tp28078943p28082261.html
> Sent from the Gumstix mailing list archive at Nabble.com.
>
>
>
> ------------------------------------------------------------------------------
> Download Intel&#174; Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> gumstix-users mailing list
> gum...@li...
> https://lists.sourceforge.net/lists/listinfo/gumstix-users
>