Vdrive2 SPI Problem (UART Serial OK)

I have a Vdrive2 module and a 28X1. I can communicate with it fine using Technical's sample code over the UART interface (jumper select on the Vdrive2 to 3.3V). In fact, if I disconnect all the communications, and tie the CTS pin low, the device still initializes properly--the LED goes green on the Vdrive and the LED on the flash disk comes on.

However, if I switch the jumper to SPI communications, I cannot get the drive to initialize. I've attempted to apply the clock signal, pulling the chip select either high or low, and pulling Vdrive Pin7 high or low and combinations of the above but I get the same response from the Vdrive: alternating red/green for three cycles, same as at the beginning of the serial communications, then...nothing, as opposed to green lights when its in serial mode.

I'd like to use the SPI interface since the device that I'm datalogging from is occupying the hardware serial.

Note that for the moment, my question is somewhat PICAXE-independent. However, my first attempts at using the device with the PICAXE over SPI, before I knew how the initialization looked went as follows:<code><pre><font size=2 face='Courier'>symbol usbcs = 4
symbol tmp1 = b2

'USB module comms
hspisetup spimode11e,spifast '1 MHz clock well within 12 MHz limit, spislow/medium same result
sertxd(&quot;CP1&quot;,10,13) 'This shows up

high usbcs
sertxd(&quot;CP2&quot;,10,13) 'This shows up

hspiout (13)
sertxd(&quot;CP3&quot;,10,13) 'This doesn't show up

hspiin (tmp1)
sertxd(&quot;CP4&quot;,10,13) 'Neither does this
low usbcs </font></pre></code> Possibly more interesting is that after about two seconds, the PICAXE resets, sending both CP1 and CP2 messages again, and it repeats this process until I've unplugged it.

For this test, pinouts on the Vdrive are:
Vdrive Pin 1 (GND) -&gt; GND,
Vdrive Pin 2 (SDO) -&gt; PICAXE Pin 15 (SDI),
Vdrive Pin 3 (5V0) -&gt; +5V,
Vdrive Pin 4 (SDI) -&gt; PICAXE Pin 16 (SDO),
Vdrive Pin 5 (SCK) -&gt; PICAXE Pin 14 (SCK),
Vdrive Pin 6 (CS) -&gt; PICAXE Pin 25 (Out4/usbcs).

It's not a simple matter of having SDO and SDI swapped, since that's how I started off (oops) and it didn't work any better.

--Patrick

One of the features of the 'hardware SPI port' is that the internal PIC hardware does not allow the hspiout command to be completed (ie the byte to be sent) if the hardware spi input pin is in the unexpected status (ie high when it should be low etc). This is probably the issue here.

After 2.3 seconds of being unable to hspiout the PICAXE will timeout and reset.

You may have more luck when 'experimenting' using the bit-busted spiin / out commands using normal inputs/outputs which are not so fussy - spiout will work regardless of the input pin status When you have it working them move back to the hardware SPI port.

We've not yet tried SPI with the VDRIVE2/VMUSIC2.

Edited by - Technical on 03/06/2007 00:36:47

I'm getting somewhere. I switched from hardware SPI to bit-bang SPI, and stared at the FTDI datasheet for a while. I realized that there is a strict dataframe: 3 bits from the master (preamble), 8 bits either in or out (body), and one bit from the slave (OK/END). I've gotten that going well enough that the drive initializes (green LED+flash drive LED), though I still haven't figured out the details--I need to determine if I'm feeding in the correct preamble, and the code should act on the OK/END bit rather than ignoring it as I currently am.<code><pre><font size=2 face='Courier'>#picaxe 28x1

'SPI device select
symbol usbcs = 4
symbol spiclk = 0
symbol spisdo = 1
symbol spisdi = 6

'Some variables
symbol tmp1 = b2
symbol tmp2 = b3
symbol tmp3 = b4
symbol tmp4 = b5

'USB module comms

main:
'This is currently unrolled, it should be moved into two subs
high usbcs

spiout spiclk, spisdo,3, (%10000000/3,&quot;E&quot
spiin spiclk,spisdi,3, (tmp1/1)

low usbcs
pause 10 'These may be unneeded or too long, not sure yet

high usbcs
spiout spiclk, spisdo,3, (%10000000/3,cr)
spiin spiclk,spisdi,3, (tmp1/1)

low usbcs
pause 10

high usbcs
spiout spiclk,spisdo,3, (%11000000/3)
spiin spiclk,spisdi,3, (tmp1,tmp2/1)

low usbcs
pause 10

high usbcs
spiout spiclk,spisdo,3, (%11000000/3)
spiin spiclk,spisdi,3, (tmp3,tmp4/1)

low usbcs
pause 10

debug
goto main </font></pre></code> There's still quite a bit more to do here. Right now the output generally consists of the bytes &quot;Q&quot; and &quot;X&quot;, with occasional &quot;[&quot;, &quot;;&quot;, and &quot;a&quot;. But I am getting something, just need to work out details.

Questions for the audience: is there any way to send or receive non-8-bit messages using the hardware SPI? Is the software SPI fast enough that the data isn't corrupted? I don't have a logic analyzer so I can't watch the output.

I'm going to be playing more with this either this evening or tomorrow, and I'll keep you posted.

You can only send 8 bit numbers via the hardware SPI port. But most SPI systems can be setup to ignore any extra trailing bits.

Speed is not a major issue with SPI, as the PICAXE generates the clock pulses anyway. This means that the slave device will only output at the PICAXE speed of operation (ie the PICAXE generated SPI clock speed).

Edited by - Technical on 06/06/2007 15:10:50

Re: hardware SPI, I'll try that once I get software working.

Re: clock speed, ah, yes, that makes sense.