VDrive2 with hspi on 28X1

BCJKiwi · Oct 21, 2007

One component of the current project I'm working on involves data logging which after much research I decided would best be achieved on a VDrive2. hspi is the chosen protocol.
I have searched the forum and studied all the code used so far by others but that doesn't seem to help with the issues here. FTDI and Vinculum sites don't seem to have anything that helps me (or I just don't understand what their documentation says).

I have the device now and am working with a 28X1 fw verA.1

1. spifast simply won't work. Simulator reports "hardware pins have not been setup to use this command" and there is no response from the VDrive2 if the program is downloaded. Clock speed has no effect. spimedium is OK
2. can get the standard startup output from the VDrive2 using the following test code;

Code:

#PicAXE 28X1
setfreq m8
main:
hspisetup spimode00,spimedium 
'high cs
'low cs
'high cs ' enable chip select
'hspiout (%00000100,$01,$0D) 
'low cs
high cs
hspiout (%00000110)
hspiin (b0)
low cs
pause 25
sertxd(b0)
goto main

3. The spimode 00, 10, and 11 all seem to work but 01 does not, nor do any of the e versions work. Analysis of the wave forms in the VDrive2 manual and the Microchip datasheet suggest that SMP=0, CKE=1 and CKP=0 is what should work which equates to spimode00 so am mystified that 10 and 11 also work.

4. cs must be taken high for any read or write but must be taken low for one cycle at the end of any read or write before commencing another.

5. However if I attempt to send any commands to the VDrive2 to do anything, such as;

Code:

high cs
low cs
high cs ' enable chip select
hspiout (%00000100,$01,$0D) ' directory listing
 
or 
 
high cs
low cs
high cs ' enable chip select
hspiout (%00000100)
low cs
high cs 
hspiout ($01,$0D) ' directory listing
low cs

There is no reply on the terminal.
Any assistance would be appreciated.

Also as this unit is running firmware ver03.54 I have tried to upgrade to Ver 03.58 using the internal bootloader process as described by technical. The code is found and attempts to load but then just loops around repeatedly never achieving anything. Does anyone have any other suggestions on this issue. I appreciate the update might be achieved via serial and the vProg program but that won't work for me once the system is in its final configuration.
Anyone have any joy with this upgrade method?

Thanks

BCJKiwi · Oct 28, 2007

Well, I'm a little disappointed that there has been zero response to my post!

I would be interested to know if this is because no one else is using a VDrive2, or if my query was not clear.

I have continued to work on this problem with no joy.
Have tested hardware serial which works OK but I won't have the pins available in my application as they will be required for another device that only supports serial comms.

Have tried bitbang spi with the same problems/results as hspi.

Any comments / help would be much appreciated.

Thanks

Technical · Oct 28, 2007

Most people tend to use rs232 not spi on these vdrive2/vmusic2 modules.

hippy · Oct 28, 2007

When I investigated VDRIVE2 I couldn't find anything on how SPI was actually used.

@ BCJKiwi : Do you have a link for the specification of the SPI comms format for VDRIVE2 ? When I do my project ( one day, soon hopefully ) I'm hoping to use SPI to avoid the problem of data coming back too quickly so do not mind taking a look to see if I can help out.

BCJKiwi · Oct 28, 2007

@Technical:
The project I am working on already uses hser for another device (OBDII that does not have any other option) and the only workable comms for this device is hSPI as with all the other stuff that's happening in the project and program I can't have anything that will stop and wait. I'm also running out of pins for bitbanging (which I couldn't get working either - same problem as hspi).
DS1307 - edited as issue was a breadboard wiring fault.

I am wondering if there is an issue with the 28X1 FW A.1 that I'm using as it appears that neither hsPi nor hi2c can write but both can read and they do use the same parts in the PIC. Can you confirm this chip with this FW is good for these protocols.

@Hippy
There is basic programming documentation on their (Vinculum/FTDI) site but it is not VDRIVE2 (or VMusic2) specific but refers to their core chip and is oriented toward assembler which is probably clear to you but I'm sorry to say is not at all clear to me although I do get the basics. While this gives all the specific routines it does not appear to actually string them together into a working example.
There is also an app note and other VDrive2 specific info which shows the pinouts/waveforms for SPI and gives a flow chart of the sequence of events.

Not at the "project office" at present (have to earn a living somehow dammit!) so will add the links this evening

Thanks

lbenson · Oct 29, 2007

On a 28X1 with firmware version A.0 I am successfully reading a DS1307 connected on pins 14 (I2C scl) and 15 (I2C sda). Coding as follows.

To initialize:
i2cslave %11010000, i2cslow, i2cbyte

To read:
readi2c 0, (b0, b1, b2) ' read sec, min, hour

to write:
writei2c 0, ($45,$09,$13,$05,$26,$10,$07,$10) ' sec,min,hour,dayofweek,day,mo,yr,sectick

BCJKiwi · Oct 29, 2007

@ Hippy:
VDrive2 Docs;

VDRIVE2 specific documents (as reported by support1 at FTDICHIP dot com)
http://www.vinculum.com/documents/datasheets/DS_VDRIVE2.pdf
http://www.vinculum.com/documents/schematics/VDRIVE2%20Schematic%20Prints.pdf

VDRIVE2 specific firmware documentation is not provided because the firmware is not specific to the VDRIVE2
http://www.vinculum.com/documents/fwspecs/Vinculum%20Firmware%20User%20Manual%20V2.1%20Rev%202.pdf
Vinculum chip document:
http://www.vinculum.com/documents/datasheets/DS_VNC1L-1A.pdf
We do have SPI example code for a PIC16F688 on the web.
http://www.vinculum.com/projects.html

There is also an appnote which was attached to an email from ftdichip as SPItoVNC1L.pdf (59Kb) but I can't find a link to that on their site and can't post it here.
Their full range of documentation is at http://www.vinculum.com/documents.html

DS1307
Well here are some of the variations on the code I tried.
It seems that if I change the values in time set I do get back a different value in some fields but they never change - as if the clock isn't ticking even though the LED on SQWE is winking each second.

Code:

#picaxe 28x1
SetFreq m8
 
Main:
'DS1307 CODE
pause 2000
hi2csetup i2cmaster,%11010000,i2cslow_8,i2cbyte
hi2cout 0, ($01,$09,$13,$05,$26,$10,$07,$10)
DS1307:
pause 1500
hi2csetup i2cmaster,%11010000,i2cslow_8,i2cbyte
hi2cin 0,(b0,b3,b6,b9,b12,b15,b18) ' read 
bcdtoascii b0,b1,b2 'secs
bcdtoascii b3,b4,b5 'mins
bcdtoascii b6,b7,b8 'hrs
bcdtoascii b9,b10,b11 'DayofWeek
bcdtoascii b12,b13,b14 'Date
bcdtoascii b15,b16,b17 'Month
bcdtoascii b18,b19,b20 'Year
 
sertxd ("The Time Is:- Yr ",b19,b20," Mnth ",b16,b17," Date ",b13,b14," DoW ",b11," Hr ",b7,b8," Min ",b4,b5," Sec ",b1,b2,cr,lf)
goto DS1307
 
 
OR
Main:
'DS1307 CODE
pause 2000
i2cslave %11010000, i2cslow_8, i2cbyte
writei2c 0, ($45,$09,$13,$05,$26,$10,$07,$10) 
DS1307:
pause 1500
i2cslave %11010000, i2cslow_8, i2cbyte
readi2c 0, (b0,b3,b6,b9,b12,b15,b18) ' read sec, min, hour
bcdtoascii b0,b1,b2 'secs
bcdtoascii b3,b4,b5 'mins
bcdtoascii b6,b7,b8 'hrs
bcdtoascii b9,b10,b11 'DayofWeek
bcdtoascii b12,b13,b14 'Date
bcdtoascii b15,b16,b17 'Month
bcdtoascii b18,b19,b20 'Year
 
sertxd ("The Time Is:- Yr ",b19,b20," Mnth ",b16,b17," Date ",b13,b14," DoW ",b11," Hr ",b7,b8," Min ",b4,b5," Sec ",b1,b2,cr,lf)
goto DS1307

I get back;
The Time Is:- Yr 00 Mnth 01 Date 01 DoW 1 Hr 00 Min 00 Sec 80
repeated and never changing but all the hile the SQWE LED is winking each second.

Perhaps I should add that all this is on a breadboard at present so I guess there may be issues with the crystal as it is not on a grounded shield but that would not explain why the values written (e.g. 07 for the year) don't come back the same when read (e.g. 00 for the year).

So if there's anything you could suggest that would be much appreciated.

BCJKiwi · Oct 29, 2007

Well this code works;

Code:

#picaxe 28x1
SetFreq m8
 
Main:
'DS1307 CODE
pause 2000
hi2csetup i2cmaster,%11010000,i2cslow_8,i2cbyte
hi2cout 0, ($00,$09,$13,$06,$26,$10,$7,$10)
DS1307:
pause 1500
hi2cin [%11010000],6,(b0) ' Year 
bcdtoascii b0,b1,b2
sertxd ("Date/Time:- Yr:",b1,b2)
 
hi2cin 5,(b0) ' Month
bcdtoascii b0,b1,b2
sertxd (" Mo:",b1,b2)
 
hi2cin 4,(b0) ' Day
bcdtoascii b0,b1,b2
sertxd (" Day:",b1,b2)
 
hi2cin 3,(b0) ' DoW
bcdtoascii b0,b1,b2
If b2="1" then sertxd (" DoW:","Su")
elseif b2="2" then sertxd (" DoW:","Mo")
elseif b2="3" then sertxd (" DoW:","Tu")
elseif b2="4" then sertxd (" DoW:","We")
elseif b2="5" then sertxd (" DoW:","Th")
elseif b2="6" then sertxd (" DoW:","Fr")
elseif b2="7" then sertxd (" DoW:","Sa")
EndIf
 
hi2cin 2,(b0) ' Hour
bcdtoascii b0,b1,b2
sertxd (" Hr:",b1,b2)
 
hi2cin 1,(b0) ' Minute
bcdtoascii b0,b1,b2
sertxd (" Min:",b1,b2)
 
hi2cin 0,(b0) ' Second
bcdtoascii b0,b1,b2
sertxd (" Sec:",b1,b2,cr,lf)
'goto DS1307
 
'COMPASS CODE
' hi2csetup i2cmaster,$C0,i2cfast_8,i2cbyte
' hi2csetup i2cmaster,%11000000,i2cfast_8,i2cbyte
Compass:
pause 1000
hi2cin [%11000000],0,(b22) ' Read CMPS03 Software Revision
hi2cin 2,(b27,b26) ' Read compass bearing as a word (0-3599 for full circle)
' CMPS03 Register 2=HighByte, 3=LowByte. w2(b3)=highbyte, (b2)=Low byte 
w12 = w13/10 ' /10 to get whole degrees
pause 500
sertxd ("FW Rev: ",#b22," Compass Bearing: ",#w12,cr,lf)
' Goto Compass 'Loop for continuous display
Goto DS1307 'Loop for continuous display

Why does it work now - well much humble pie being consumed here this evening! Have this test set up on two breadboards clipped together with CMPS03 and DS1307 on one board and the 28x1 on the other. Carefully applied links for +V & 0V rails between the boards at the top but not the bottom! So there was actually no 0v for the DS1307!

Apologies for the inconvenience I may have caused - the real miracle is that I actually found this fault at 1am!

hippy · Oct 30, 2007

BCJKiwi said:
Why does it work now - well much humble pie being consumed here this evening! ... Carefully applied links for +V & 0V rails between the boards at the top but not the bottom! So there was actually no 0v for the DS1307!

Apologies for the inconvenience I may have caused - the real miracle is that I actually found this fault at 1am!

The ones that are staring you in the face are always the hardest to see. The worst are when it works, change code and it fails, revert back and it's okay again, even though it's the same faulty hardware. It's so easy to misdiagnose where the error is because it's equally easy to discount where a problem may be. The answer usually appears, blindingly obviously, at some odd time, more often than not when looking at something else, or in my case, frequently while drifting off to sleep.

BCJKiwi · Nov 9, 2007

Well I have been persisting with the hspi and the Vdrive2.

1. I still don't have an answer from FTDI on how to upgrade the firmware (It just loops without loading) so I'm stuck on fw Ver3.54

2. I am able to read successfully from the VDrive2 but not send it any instructions other then the CR which returns the "D:>" prompt or the "No Disk" message depending on whether the USB 'disk' is inserted or not.
Any other instruction including the echo "E" returns a "Bad Command" response.

This suggests that the PICAXE and SPI are working and communicating at a basic level but not at any level that is useful.

Current basic test code

Code:

'####################################################################################
'# PICAXE 28X1   FTDI/VINCULUM  VDRIVE2        #
'####################################################################################
; Hardware Setup for hspi
; VDrive2  - PICAXE-28X1
; 1 Black  GND  -  0V   Leg 8,19
; 2 Brown  SDO  -  spiSDI input4  C4 Leg 15 Note SDO on VDrive2 --> spiSDI on PICAXE
; 3 Red    V+  -  V+   Leg 20
; 4 Orange SDI  -  spiSDO input5  C5 leg 16 Note SDI on VDrive2 --> spiSDO on PICAXE  
; 5 Yellow SCLK  -  spiSCL input3  C3 Leg 14
; 6 Green  CS  -  spiCS  output0 B0 Leg 21
; 7 CONNECTOR KEY
; 8 Blue RI  -  not connected
; Tested with an Imation nano 1GB USB stick.
; set PICAXE type
#PICAXE 28x1
setfreq m8
symbol first_byte = b0
symbol temp = b2
symbol CS0 = Output0  'CS0 = VDrive2 Chip select 
#terminal 9600
setup:
'setup spi hardware 
'CS0 is chip select
'HSPISETUP mode,speed
'HSPIIN (data,data)
'HSPIOUT (data,data)
'
hspisetup spimode00,spimedium  'slow or medium OK, Fast won't work at any clock speed
 'spi mode 00 (CKP=0,CKE=1,SMP=0), middle of clock
 'CKP --> Clock Polarity 1 = idle high 0 = idle low
 'CKE --> Clk Select on 1 = active->idle, 0 = idle->active
 'SMP --> Sample data 1 = end of clock 0 = Middle of Clock
init:
' Send E's until the unit responds correctly
pause 1500
high cs0      ' enable chip select
hspiout (%00000100,cr)    ' 100 - set up for write
'hspiout (%01000101,cr)
'hspiout ("E",cr)
hspiout (cr)
low cs0
sertxd ("<Sent> E ",CR,LF)   ' log what's happening
gosub get_response
if first_byte <> "E" then init
end
get_response:
pause 100       ; wait a while 
  high cs0
   hspiout (%00000110) ' 110 - set up for read
   hspiin (first_byte)  ; get first byte returned
  low cs0
   sertxd ("First Byte  ",first_byte,cr,lf)  ; transmit it
   sertxd ("Temp bytes  ")
do
  high cs0
   hspiout (%00000110) ' 110 - set up for read
   hspiin (temp)   ; get remaining byte unitl CR
  low cs0
   sertxd (temp)   ; transmit it
'debug
loop while temp <> CR     ; if not CR loop
sertxd (LF)      ; Add a LF to the received CR
sertxd (CR,LF)      ; Do another blank line
return

Any suggestions welcome.

Technical · Nov 9, 2007

At a quick glance your SPI commands do not seem to match the datasheet which probably means the bytes transmitted are corrupt. A disadvantage of the PIC's internal hardware SPI module is that it only works in 8 bit chunks, whilst this device specifies 11 bits of interest. The bit-busted 'shiftin/out' commands can have a number of bits specified so may be easier to work with.

For a write, from the timing diagrams in ds_vdrive2.pdf,
directly after CS goes high you need to write

1-0-0-D7-D6-D5-D4-D3-D2-D1-D0

This is 11 bits , but as hspi only works with bytes you need to pad with 5 x 0s at the end e.g. to send data byte d the stream is

cs high
100ddddd ddd00000
cs low

you are currently padding 0s at the start e.g.
cs high
00000100 dddddddd
cs low

which is why we think your sent data may be corrupt. Basically you have to split your data byte over the two bytes by a bit of maths.

BCJKiwi · Nov 10, 2007

I have spent untold hours on this, researching the web, analysing the sample C code from FTDI and trying to find all the alternate programs and techniques others are trying to use.

I also tried the bitbang approach just sending 11 bits and did not get as good a result as I have with hspi.

I have no idea what the math would look like to send a sequence of bytes (i.e. a file name or strings of data) in the manner suggested. It would appear to be a very cumbersome approach as every byte would have to be split into 5 bit/3 bit groups and joined to the preceeding/following groups all the way along the chain of data. I am willing to try - do you have a pointer on how to do this math for me please.

However after much study of the 11 bit vs 8 bit issue I came to the conclusion (supported by others in different searches on the net) that the preceding bits (the extra 0's padded at the front) would be ignored and only the last three bits would be acted on hence the 0000 0100 format - i.e. 0000 0100 dddd dddd would be seen as 100dddddddd as the preceding 00000 would be ignored.

This appears to be borne out in practise as it works for the read sequence and also works for the CR which generates the D:> and No Disk responses.

hippy · Nov 10, 2007

It might be worth looking at other Viniculum code people have produced for SPI control. This suggests there may be extra clock pulses needed to keep things in synch and to read the status after each transfer -

http://forums.parallax.com/forums/default.aspx?f=15&m=189123

BCJKiwi · Nov 11, 2007

Hippy,
Have studied the vinculum code and various other code samples like the one in the parallax forum you linked to.
None of those translate in any meaningful way to hspi as there is no control (as advised by Technical). These samples are all low level bitbanging approaches where every element of the comms is under program control. This control is not available with the PICAXE (unless this can be acheived by the non-X1 bitbang approach but I get nil useable response when I try the sample code). The X1 code (see below) does allow control over the number of bits sent and you can pulsout the clock but most other aspects are selected via the mode switches.

Have been back to have another look at spiin/out (shiftin/out).
There are two different types of code offered in Manual 2 - X1 and non-X1.

I have had no joy whatsovever with the non-X1 version.

After much work on the X1 version I have acheived partial success - what do I mean by partial success - well I have managed to acheive nearly the same results as I currently acheive with hspi!!!!. The difference is that I don't get a 'Bad Command' response when trying to send anything other than a CR.

The test program

Code:

; Interfacing a VDrive2 module to PICAXE-28X1
; Hardware Setup
; VDrive2  - PICAXE-28X1
; 1 Black GND  -  0V   Leg 8,19
; 2 Brown  SDO  -  Input7 C7    Leg 18 spiSDI Note SDO VDrive2 --> spiSDI PICAXE
; 3 Red V+   -  V+   Leg 20
; 4 Orange SDI  -  Output2 B3    Leg 23 spiSDO Note SDI VDrive2 --> spiSDO PICAXE  
; 5 Yellow SCLK  -  Output1     B1 Leg 22 spiSCL
; 6 Green  CS0  -  Output0  B0 Leg 21
; 7 CONNECTOR KEY
; 8 Blue RI  -  not connected
; Tested with an Imation nano 1GB USB stick.
init:
; set picaxe type
#picaxe 28x1
setfreq m8
#terminal 9600
symbol CS0 = 0   'Chip select
symbol sclk = 1    'leg 22  Output 1  
symbol sdata_out = 2   'leg 23  Output 2  
symbol sdata_in = 7   'leg 18   Input 7 
symbol var_in = b5  'data variable used during shiftin
symbol var_out = b6  'data variable used during shiftout
symbol set_bits = 3  'send only first 3 bits of byte for start,address,r/w
symbol data_bits = 8   'number of data bits (8 is default)
 
setup:
'Vdrive2
main:
; Send E's until the unit responds correctly
'var_out = %10000000 'set up for SPI write
'SPIOUT  sclk,sdata,mode,(data{/ bits}, {data{/ bits},...}) 
high cs0     ' enable chip select
spiout sclk,sdata_out,1,(%10000000/3) '1=MSB First Idle Low,5=MSB First Idle High (0,1,4,5)
'spiout sclk,sdata_out,1,("E")
spiout sclk,sdata_out,1,(cr)
pulsout sclk,10
low cs0
sertxd ("<Sent> E",CR,LF)
 
do
 high cs0
 spiout sclk,sdata_out,1,(%11000000/3) 'MSB First Idle Low
 spiin sclk,sdata_in,0,(var_in)  'MSB 1,3,5,7, LSB 0,2,4,6 
 pulsout sclk,10     '0 LSBPre_L (LSB first, sample before clock, idles low)
 low cs0
 sertxd (var_in)
loop while var_in <> cr
sertxd (cr,lf)
pause 1000
goto main

shows some interesting anomolies.
1. an additional pulse on sclk is required after the data byte to satisfy the Vdrive2 requirements. Additional sclk before and/or after data bytes and/or chip select don't make any difference.
2. spiin (shiftin) only provides clean output to sertxd when set up with mode 0 (LSB first, sample before clock, idles low).
3. However both modes 1 and 5 (and no others) work with spiout to enable spiin to function. modes 1 and 5 are both MSB first - the opposite to the only mode that works for spiin.

Obviously there is something seriously wrong with this whole setup. I have no idea where the issues are. FTDI have been silent on how to upgrade the firmware for over two weeks - other than to confirm the request 'You request is in the queue' (sic).
At this stage I'm not going to put any further time in on this until I can get a firmware upgrade into the unit (unless someone can offer some code that works).
I should also add that I don't have a spare input for the bit bang approach anyway with the current project design - hence the need to get hspi to work if at all possible.

hippy · Nov 11, 2007

I'm afraid I'm not really able to help much not having any hardware to try with myself.

The only thing I can say is that if bit banging works with other micros then it should work with a PICAXE.

Creating a standalone test circuit to do bit-banging where you don't need to worry about lack of I/O and translating known working code line for line is perhaps the best way to move forward. I don't see any Reset signal in your code, although I don't know how essential that is.

http://forums.parallax.com/forums/attach.aspx?a=12015

BCJKiwi · Nov 11, 2007

Thanks for persisting with this thread Hippy.

I'm sorry but I do not comprehend how to turn these low level programming examples into a working PicAxe program. These programs are manipulating the core chip directly on the programmers development demo board. The Vdrive2 has a different set of higher level commands which do include a reset.

I really don't think I will get much further until FTDI and Technical get together and sort out how to make these things work together with SPI.

sevs3 · Nov 12, 2007

I have started playing around with running this with spi also. I have had it running with uart, but i would prefer spi because i know i havnt missed a byte somewhere.

This is my code at the moment, though it isnt working. Just thought id show the direction im heading in.

Code:

symbol RSRWMask = b0
symbol databyte = b1
symbol readbyte = b2
symbol temp = b24
symbol cs = 0
symbol RSRWMask1 = w4

#terminal 4800
hspisetup spimode00, spimedium

Initialisation:
	gosub CheckUSBStatus



Read_Data:
	RSRWMask = %00000110
	gosub SendDataByte
	return


Read_Status:
	RSRWMask = %00000111
	gosub SendDataByte
	return


Write_Data:
	RSRWMask = %00000100
	gosub SendDataByte
	return


Write_Status:
	RSRWMask: = %00000101
	gosub SendDataByte
	return


SendDataByte:
	high cs
	hspiout (RSRWMask1, $0D)
	low cs
	if pin5 = 1 then goto SendDataByte
	return

	
ReadDataByte:
	high cs
	hspiout (RSRWMask)
	hspiin (readbyte)
	low cs
	if pin4 = 1 then goto ReadDataByte
	'do
	  high cs
	  hspiout (RSRWMask)
	  hspiin (temp)
	'loop while temp <> CR
	if pin4 = 1 then goto ReadDataByte
	return
	


CheckUSBStatus:
	RSRWMask1: = %1010100010100000
	RSRWMask = %00000010
	databyte = "E"
	sertxd ("Sending Data", cr, lf)
	gosub SendDataByte
	sertxd ("Data Sent", cr, lf)
	RSRWMask = %11100000
	gosub ReadDataByte
	sertxd ("Data Read: ", #readbyte, cr, lf)
	sertxd ("temp byte: ", #temp, cr, lf)
	pause 1000
	if readbyte = "E" then
	sertxd ("Syncronised", cr, lf)
	else
	goto CheckUSBStatus
	endif

I only seem to be able to a consistant result having the pad 0's at the end like technical suggested.

with this code i get a constant reply of "64", although the module tells me that i am reading new data.

I will continue to work on this and see what i can get to happen. I dont have my hopes up high though, im working in areas i havnt looked at before. Still, thats the best way to learn. Will keep you posted.

BCJKiwi · Nov 12, 2007

Thanks for the input Sevs
Would you please advise which PICAXE chip are you using and what firmware rev you have on both the PICAXE and VDrive2?

Since I can't update the VDrive2 from V3.54 and they are now up to v3.60 I suspect there may be an issue with the VDrive2 but since it works in regular serial mode I'm not sure.

As advised above I do get responses when padding before but no joy when padding after - the complete opposite of your experience.

Look forward to your progress reports.

BCJKiwi · Nov 12, 2007

I've managed to get some sensible transmission and response at last with the following code - very basic at this point but it does prove the communication mechanisms required with HSPI.

Code:

; Interfacing a VDrive2 module to PICAXE-28X1
; Hardware Setup for hspi
; VDrive2  - PICAXE-28X1
; 1 Black  GND  -  0V   Leg 8,19
; 2 Brown  SDO  -  spiSDI input4  C4 Leg 15 
; 3 Red    V+  -  V+   Leg 20
; 4 Orange SDI  -  spiSDO input5  C5 leg 16  
; 5 Yellow SCLK  -  spiSCL input3  C3 Leg 14
; 6 Green  CS  -  spiCS  output0 B0 Leg 21
; 7
; 8 Blue RI  -  not connected
; Note SDI on VDrive2 connects to spiSDO on PICAXE
; Note SDO on VDrive2 connects to spiSDI on PICAXE
 
; Tested with an Imation nano 1GB USB stick.
symbol first_byte  = b0
symbol temp        = b2
symbol CS0         = Output0  'CS0 = VDrive2 Chip select
 
; set picaxe type
#picaxe 28x1
setfreq m8
#terminal 9600
setup:
; setup spi hardware 
'CS0 is chip select
'HSPISETUP mode,speed
'HSPIIN (data,data)
'HSPIOUT (data,data)
'
hspisetup spimode00,spimedium  'spimedium as Fast won't work!
 'spi mode 00 (CKP=0,CKE=1,SMP=0), middle of clock
 'CKP --> Clock Polarity 1 = idle high 0 = idle low
 'CKE --> Clk Select on 1 = active->idle, 0 = idle->active
 'SMP --> Sample data 1 = end of clock 0 = Middle of Clock
init:
' Send E's until the unit responds correctly
pause 2000
high cs0      ' enable chip select
hspiout (%00000100)    ' 100 - set up for write
hspiout ("E")     ' data byte
hspiout (%00000100)    ' 100 - set up for write
hspiout (cr)     ' databyte - cr = end of data
hspiout (%00000000)    ' Force more clocks by sending empty byte
low cs0
sertxd ("<Sent> E ",CR,LF)   ' log what's happening
gosub get_response
if first_byte <> "E" then init
Main:
 
'Check Drive present
Drive:
pause 2000
high cs0
hspiout (%00000100)    ' 100 - set up for write
hspiout (cr)     ' databyte - cr = drive status
hspiout (%00000000)    ' Force more clocks by sending empty byte
low cs0
gosub get_Diskresponse
if first_byte <> "D" then Drive  ' D = D:\> if Disk Inserted, N = No Disk 
'if first_byte = "N" then Drive 
goto Drive
 
get_response:
pause 100 ; wait a while 
high cs0
   hspiout (%00000110) ' 110 spiin
   hspiin (first_byte)  ; get first byte returned
low cs0
   sertxd ("First Byte_Temp bytes ",first_byte,"_")  ; transmit it
do
  high cs0
   hspiout (%00000110)
   hspiin (temp)   ; get remaining byte unitl CR
  low cs0
   sertxd (temp)   ; transmit it
loop while temp <> CR     ; if not CR loop
sertxd (LF)      ; Add a LF to the received CR
sertxd (CR,LF)      ; Do another blank line
return
 
get_Diskresponse:
pause 100       ; wait a while 
high cs0
   hspiout (%00000110) '110 - set up for read
   hspiin (first_byte)  ; get first byte returned
low cs0
   sertxd ("First Byte  ",first_byte,cr,lf)  ; transmit it
   sertxd ("Temp bytes  ")
do
high cs0
   hspiout (%00000110)
   hspiin (temp)   ; get remaining byte unitl CR
low cs0
   sertxd (temp)   ; transmit it
loop while temp <> "D"     ; if not File system Prompt loop
sertxd (LF)      ; Add a LF to the received CR
sertxd (CR,LF)      ; Do another blank line
return

The key to the write process appears to be to send each databyte individually, i.e. with its own write command.
The read process already achieves this as it reads one byte per loop - no additional clks required?

high cs0 ' enable chip select
hspiout (%00000100) ' 100 - set up for write
hspiout ("E") ' data byte
hspiout (%00000100) ' 100 - set up for write
hspiout (cr) ' databyte - cr = end of data
hspiout (%00000000) ' Force more clocks by sending empty byte
low cs0

The second critical step in the write process is to send the additional empty byte to force more clocks before deslecting the chip.

This is obviously just a proof of concept and will require much more work to achieve functional code.
I trust you will also note that the start byte has the '0's padded at the beginning so they do get ignored!
Ref comment in post #12
However after much study of the 11 bit vs 8 bit issue I came to the conclusion (supported by others in different searches on the net) that the preceding bits (the extra 0's padded at the front) would be ignored and only the last three bits would be acted on hence the 0000 0100 format - i.e. 0000 0100 dddd dddd would be seen as 100dddddddd as the preceding 00000 would be ignored.

sevs3 · Nov 12, 2007

Nice work BCJKiwi! I tried this with my circuit and it works, although some of the message is scrambled. Perhaps what i was getting with having the padding at the end was some random error message from the USB module.

I'm using a 28X1 with version A.0 on it and the USB module is Ver 3.55VDAPB.

BCJKiwi · Nov 12, 2007

Interesting, the gear I'm testing with is a 28X1 with fw A.1 and the VDrive2 has fw 3.54.
The main issue with the scrambled/garbage data being returned seems to relate to handling the responses from the VDrive2. There is no consistent response - i.e. depending on what commands are sent, and what errors are returned, different info comes back without a fully consistent end character and if you are looking for something that doesn't arrive then you just read what appears to be random data.
Hence my comment "will require much more work to achieve functional code"!
Next steps;
1. Sort out all the returned data formats, their end characters and how to check for them all.
2. Develop a universal subroutine for sending commands that will handle varying numbers of bytes.
3. Sort out the handling of the 'status' bit.
4. Sort out how to switch into the short command set and to use the short command. If step 2 turns out OK this may not be needed.
5. Get to use the ?#!& thing - like actually create a file with a date coded filename and write data to the file!

BCJKiwi · Nov 30, 2007

Progress report

I have continued working on VDrive2 with HSPI for some time on and off.
PLEASE NOTE this is an HSPI discussion ONLY.
HSerial behaviour on the VDrive2 is quite different.

I have tried both normal and short command modes. Short should reduce code space and be more efficient.
I have to report that at this time and without some sort of new revelationary insights, as far as I'm concerned, VDrive2 and PICAXE with HSPI is not a feasible combination.

Reasons?
1. The only way found to send/receive commands/data via HSPI is one byte at a time which means it is;
a) slow
b) requires a lot of code space.
2. Each time the unit is powered up it puts out a bunch of status data which seems to sit in a buffer of some sort and must be read out.
3. Once the SPI bus is set up, then another bunch of status data is output which also sits in the buffer and must be read out.
4. It takes a long time for the unit to initialise (anywhere from 5 to 8 seconds and potentially longer if there are files on the drive).
5. The responses appear inconsistent and have proved very difficult to test for as the timing seems inconsistent.
e.g. if you send 'E' to get status and then test for the response and get the correct response, then you move on the the next command and test for its response there are still 'E' responses coming in out of sync.
6. The Short command responses seem to to be inconsistent - i.e. different if the drive is inserted or not inserted.
7. There are extra null bytes appearing between the 'advertised' response bytes. These may be the status bit but when one attempts to to read these in, what comes in is usually the next regular byte.
8. Whenever the write/read/test sequence gets out of sync somewhere (a very regular occurrence) there is no way to regain communication with the VDrive2 which goes into a loop which can only be broken with a re-power of the VDrive2 - a reset of the PICAXE is not sufficient.

I would like to think I have missed some critical factor in all this and that the device is not as bad as it appears to be but at this stage I just can't find a way through.

Hi2c and HSPI
Also have found that working with hi2c and hSPI on the same bus system does have some issues.
Have a DS1307 Clock utilising hi2c and the VDrive2 utilising hspi.
It appears that each time you switch from the i2c device to the spi device then the hspisetup initialisation commands need to be reissued before the VDrive2 can be accessed. I do not know if this behaviour is specific to the VDrive2 as it is the only SPI device I have tested.

So I have 2 options for data logging on this project
Find another removable storage device, or, find a practical way to use two separate serial devices via hserial off the same 28X1 while both are active.

VDrive2 with hspi on 28X1

Senior Member

Senior Member

Technical Support

Technical Support

Senior Member

Senior Member

Senior Member

Senior Member

Technical Support

Senior Member

Technical Support

Senior Member

Technical Support

Senior Member

Technical Support

Senior Member

Member

Senior Member

Senior Member

Member

Senior Member

Senior Member