Hi All
I`m assuming its probably the right place to put this since its USB related. Has anyone done any work with the Vdrive2 module from FDI?.
Cheers Pete
Hi All
I`m assuming its probably the right place to put this since its USB related. Has anyone done any work with the Vdrive2 module from FDI?.
Cheers Pete
It looks to me that FDTI make several related products from the one hardware and code set.
I placed some sample code for the VDIP1 in the "Code Examples" section of this site some months ago that might help.
HTH
Brian
Hi Brian
Thanks, I`ve got a copy of this now. There is an error on the Vdrive2 sheet I have also found. The link for SPI/UART is incorrect on both the overlay and the example with a micro. The 0v and 3V3 are transposed, in the example for microcontroller the link is in the position for SPI and not UART mode which is being used.
Cheers Pete
I have built a logger using the Vdrive2 and wrote a blog on it. At the blog I posted schematics and code for both a 8 bit and 10 bit version. The logger uses a DS1307 for a time stamp and saves data at 1 per second using a 16F688 pic and Pic Pro Basic.
The VMusic2 is also cute.
Russ
N0EVC, xWB6ONT, xWN6ONT
"Easy to use" is easy to say.
For Bill/mark Sherman at BOTSMAKER
Thanks for taking the trouble to put your VDRIVE2 project on the web.
I'm just starting with my VDRIVE2 and have been trawling through your PIC Basic Pro code to learn how to do it.
I'm not clear why your 'write' command works? According to the FTDI notes the command is:
"WRF", $hhhh
Where $hhhh is a word that is the number of BYTES following that are to be written to the currently open file.
Your format seems to be:
"WRF",$00,$00,$00,$15,$0d,DEC yy10.........
Why does this work please?
Regards Bill Legge
Whats wrong with it? $00 $00 $00 $15 = 21 in decimal. This tells the vinculum that 21 bytes will follow to be written. If you add up the bytes, you get 21.
Thanks for your reply.
I thought the VDrive2 would take the first four hex numbers after the "WRF" and read zero bytes to follow?
What are the $00 doing?
Regards Bill legge
WRF is reading a long word of 32 bits, starting with MSB first. So if the first 3 bytes are zero, you must read in a zero. You can't take a short cut and just send $15.
Thanks,
I'd not seen that the VDrive2 was looking for a LONG.
Regards Bill Legge
This also works
The above prepares the VDIP for 24 characters. The next command would be something like thisCode:SEROUT2 VRXD, 188,["WRF 24",13]
Code:SEROUT2 VRXD, 188,["X",DEC2 HH,DEC2 MM,DEC2 SS,_ DEC2 ND,DEC2 NM,DEC3 NMD,DEC3 WD,DEC2 WM,DEC3 WMD,13,10]
And the VDIP is not looking for a LONG as in PBP LONG. The VDIP just needs to know how many characters it is expected to write.
Dave
Always wear safety glasses while programming.
Thank you, thats good to know, I'm making too much work out of it.
DSN is to monitor disk serial number
can i know how the return value can be readen from 16f688 and doing a comparison ?
i am using c language writing the software
is they any sample i can refer?
WE are using VDRIVE2 with Firmware Ver 03.66VDAPF.We are interfacing it with our USB device which is a fingerprint sensor Morphosmart MSO CBM.Details of the Slave Device (fingerprint sensor):
- Communication Class Device in accordance with USB Device Class Specifications version 2.0
- The Device use full speed transfer rate of 12Mbits/s
- Compatible with USB 1.1 and USB 2.0 hosts and hubs
WE tested our sensor with a GET DESCRIPTOR string using the command mode. We are getting desired response when we send the 'DRD' command. But, on our application we don't want the command interface. We want to send/receive data transparently (i.e. w/o using any commands).
The GET DESCRIPTOR string is a data that we send to the sensor , after which the sensor replies:
SYNCïÿìName: CBM
Mobi5 Serial Number: 0944
This is our GET DESCRIPTOR string (18 Bytes):
$53$59$4E$43$04$00$00$00$FB$FF$FF$FF$05$01$00$2F$4 5$4E
In the above string $53 is a hex value, so we are sending 18 bytes written above in HEX format. We send these values using a Windows XP PC serial PORT. On the PC we are using Terminal v1.9b software (Bray++) and we send hex data using the transmit macros field in Terminal software.
Now while testing, we used the device in command mode initially. Selected the device SC 1 and then pulled the DATAREQ line (pin 36 of VNC1L) low (0V), after that the DATAACK line also became low. So now vdrive2 is in DATA MODE. But, now if we send the GET DESCRIPTOR string then we DON'T get the desired response. Rather we don't get any response from the device. Thus, we fail to interface the sensor in data mode.
But the same can be done successfully using command mode only and the following is the device log:
Command mode successful trial log:
Commands:
ipa
qp2
qd 0
qd 1
sc 1
dsd 18
%%%%%%%% Comment: send the GET DESCRIPTOR string (18 Bytes) using the transmit macros field in Terminal software. %%%%%%%%%%%%
drd
Responses:
D:\>
$10 $00
D:\>
$01 $20 $81 $10 $00 $00 $00 $10 $01 $02 $00 $02 $02 $01 $9B $07 $47 $00 $00 $01 $01 $00 $00 $00 $00 $00 $00 $00 $00 $00 $00 $00
D:\>
$01 $20 $83 $40 $02 $40 $03 $00 $01 $02 $01 $0A $00 $00 $9B $07 $47 $00 $00 $01 $01 $00 $00 $00 $00 $00 $00 $00 $00 $00 $00 $00
D:\>
$40
SYNCïÿìName: CBM
Mobi5 Serial Number: 0944D:\>
Our objective is to interface without using any commands after we select the device (i.e. after sc 1). We want to send our data (for eg. the GET DESCRIPTOR string ) directly to the sensor and get the response from the sensor without using any commands. P.S.:We have also tried the VCDC firmware and failed in a similar manner i.e. we didn't get any reply from the sensor.
I got inconsistent responses with different usb flash drives so I gave up using the Vinculum for use as a data logger. I will be looking into using a SD card or a Datakey from Datakey Electronics. http://www.datakeyelectronics.com/ With the Datakey, the interface is made to go with the key. With USB sticks, you don't know what your getting.
Bookmarks