The attached file contains the definition of a class to manage an FTDI VDrive2 module. The class implements a familiar "file system" interface to the content of the USB memory stick, allowing you to open/create files and then read/write/seek the files. Multiple files may be open at once.
The vdrive.bas module contains a simple test driver that will display the directory listing of the drive.
ZBasic O-O Example: VDrive Class
ZBasic O-O Example: VDrive Class
- Attachments
-
- vdrive.zip
- (6.53 KiB) Downloaded 2171 times
- Don Kinzer
ZBasic O-O Example: VDrive Object
Have you done any tests concerning the maximum sustained write speed with one file open? Two files open?
On 2/3/2010 5:15 PM, Files wrote:
On 2/3/2010 5:15 PM, Files wrote:
The attached file contains the definition of a class to manage an FTDI VDrive2 module. The class implements a familiar "file system" interface to the content of the USB memory stick, allowing you to open/create files and then read/write/seek the files. Multiple files may be open at once.
The vdrive.bas module contains a simple test driver that will display the directory listing of the drive.
- Don Kinzer
Attachments:
vdrive.zip
Re: ZBasic O-O Example: VDrive Object
No. It's going to be fairly slow. The serial interface essentially has to be run at 9600 baud (the VDrive's default rate). Although you can tell the device to switch to a different rate, there is no way to tell it to revert to the default rate other than by cycling its power. This deficiency causes a problem if the ZX is reset (therefore assuming the default speed) and the VDrive's speed was previously changed but it hasn't been power-cycled. I suppose that you could try sending commands at different rates until you hit upon one that returns a correct response.twesthoff wrote:Have you done any tests concerning the maximum sustained write speed with one file open? Two files open?
The VDrive itself actually only allows one file to be open at a time. The way that the class achieves the multi-file capability is that it actually keeps the files closed, opening ta file for an operation and then closing it again. These extra commands further tax the throughput. If one only needed the capability for one file open at a time, the class could be modified to keep a file open until it is explicitly closed. The class could also be modified to operate in the "always open" mode unless multiple files were opened at one time.
The VDrive is documented to support an "SPI" interface. Although the signals of the interface are reminiscent of SPI, the timing and data interchange is nothing like any SPI device I've seen. I did try to get it to work by bit-banging the interface and had some limited success. The VDrive seemed to get into strange modes where it woudn't respond to a sequence as it had just a short time before. Unfortunately, FTDI's support department was of little help. When I asked for example code they gave me SPI interface code for a completely different device.
- Don Kinzer
ZBasic O-O Example: VDrive Class
Thanks Don,
I appreciate your work in this area...
Tom W
On 2/3/2010 6:20 PM, Files wrote:
I appreciate your work in this area...
Tom W
On 2/3/2010 6:20 PM, Files wrote:
twesthoff wrote: Have you done any tests concerning the maximum sustained write speed with one file open? Two files open? No. It's going to be fairly slow. The serial interface essentially has to be run at 9600 baud (the VDrive's default rate). Although you can tell the device to switch to a different rate, there is no way to tell it to revert to the default rate other than by cycling its power. This deficiency causes a problem if the ZX is reset (therefore assuming the default speed) and the VDrive's speed was previously changed but it hasn't been power-cycled. I suppose that you could try sending commands at different rates until you hit upon one that returns a correct response.
The VDrive itself actually only allows one file to be open at a time. The way that the class achieves the multi-file capability is that it actually keeps the files closed, opening ta file for an operation and then closing it again. These extra commands further tax the throughput. If one only needed the capability for one file open at a time, the class could be modified to keep a file open until it is explicitly closed. The class could also be modified to operate in the "always open" mode unless multiple files were opened at one time.
The VDrive is documented to support an "SPI" interface. Although the signals of the interface are reminiscent of SPI, the timing and data interchange is nothing like any SPI device I've seen. I did try to get it to work by bit-banging the interface and had some limited success. The VDrive seemed to get into strange modes where it woudn't respond to a sequence as it had just a short time before. Unfortunately, FTDI's support department was of little help. When I asked for example code they gave me SPI interface code for a completely different device.
- Don Kinzer