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!

On Tue, Mar 30, 2010 at 9:07 AM, ScottEllis <scottellis.developer@gmail.com> 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 ->

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.
gumstix-users mailing list