vdrive2 speed

[Ttelmah]

Read the manual....

set_uart_speed(xxxxx);

Just setup the uart with #use rs232 to use 9600bps.

Print the speed change command to the Vdrive.
putc(0x1A);
putc(0);
putc(0);

Then either just delay for 2 character times (2.08mSec), or poll the TRMT bit in the UART.

set_uart_speed(115200);

Robert's your Father's brother....

[DanielTPE]

[Ttelmah]

You can't change speed with #USE RS232 like this. #USE RS232, is a _preprocessor_ directive, _not_ a line of code. This is why I said use 'set_uart_speed'.

[DanielTPE]

I've tried it with the set_uart_speed command as well. Still the VDrive gets stuck and lets the green LED stay on.

Maybe the problem lays with the use of the RTS and CTS pins? In my program the RTS pin is set high (and the CTS low), otherwise the VDrive doesn't do anything at all.

Btw, i'm using an external 20MHz crystal so the clock speed of the PIC controller is very accurate.

[DanielTPE]

It is just that if I don't write the new baud rate to the VDrive, then everything works just fine. As soon as the putc(..) is written to the VDrive, it just stops working

[Ttelmah]

I wouldn't push the timing so much.

You are assuming that as soon as the processor starts, the Vdrive is ready to accept commands. Generally PIC's start faster than many devices like this. You should either be connecting the CTS line to see when the device is ready, or wait till the device sends the 'Ready' prompt, before starting to send it commands. The unit sends the message 'Ver something Vxxx On-Line:' before it is ready to accept commands.
Then similarly after the rate switch. The 2080uSec, is the minimum for the TX hardware to finish sending the command. The device responds with a couple of bytes reply at this point, and I waited for these before attempting to send any more commands.
Then when each command is sent, you should wait for the Vdrive to acknowledge before sending the rest. Simply reading the incoming data, and looking for carriage return is the easiest. Running faster, you have to ensure the drive has finished with a command, before sending the next.

[DanielTPE]

Alright, so I moved the set baud rate code. Now it sets the baudrate after the push button is pushed so enough time has passed for the VDrive to initialise the USB and let the green LED show. Now I can clearly see a short blink in the green LED right after the button is pushed so commands are recieved by the VDrive and written to the USB.
Only there is still no .txt file on the USB with the written data.
The code i use now is the following:

[DanielTPE]

Keeping in mind all the requirements needed for high speed bauds, the code is still the problem here.
If I manually set the baudrate to 9600 with the code from my last post, the VDrive still freezes. Same for double baud 19200 and 115k2 baud. And if I do nothing and only set the #rs232 to 9600 it works perfectly.

[temtronic]

hmm.. I'll have to dig out the vdrive stuff and code but I did have mine running at 115K200, without handshaking 2-3 years ago. I did reprogram the Vinculum using their PC software,then downloaded it. 'Fun' part is that I have 2 of them and got 'confused' which was high speed and which wasn't. Arrgh a simple mark on the high speed one would have saved a few hours of frustration.

jay

[DanielTPE]

Hello Jay,

Thanks for your response!
Luckily, there is no need for multiple baudrates in my application. Right now my code works just fine. But 9600 is just too slow, because it takes 12.4ms to write a 8-bit integer to the VDrive.
My goal is to set the baud to 115k2.

Ttelmah pointed out that the baud can be changed with just a few lines of PIC code, that's why I'm going down this road.

As you can see I've tried to up the baud by sending the Set Baud Rate (SBD) command. No luck there, unfortunately. The VDrive gets stuck because of the newly added code.

Maybe I can up the baudrate by reprogramming the VDrive, as you pointed out. It just isn't my favorite option because different USB disks are going to be used.

[Ttelmah]

As I said as the last line of my previous post:

"Then when each command is sent, you should wait for the Vdrive to acknowledge before sending the rest. Simply reading the incoming data, and looking for carriage return is the easiest. Running faster, you have to ensure the drive has finished with a command, before sending the next."

At the higher baud rates, you _must_ start reading the reply, and not sending another command, till each is accepted. The actual timing for the individual commands does not improve much over 9600bps, but what changes massively is how fast you can send the actual data.

[DanielTPE]

Ttelmah, right now the problem is in the code which sets the baud rate of the VDrive. The moment I set the baudrate by sending the SBD command with the associated putc(), the VDrive freezes. Not only at 115k2, but also at 9600.
I blame the code because without it, the VDrive works perfectly (at standard 9600 of course). And as soon as i set the baud manually with SBD to 9600, the VDrive stops working.

[Ttelmah]

What firmware version are you on?.
Try doing a search on this version online, and seeing if there are any known issues.

[DanielTPE]

My PCW Compiler has recently been updated to Version 5.026.
I've done some googling but no fellow programmers seems to have this issue.
There must be a fault in the code I posted. I'm going to keep trying different approaches. If i get it working with pic code, i'll let you all know.
If someone finds a solution in the meantime, please let me know

[Ttelmah]

Not compiler version, _firmware_. The code in the Vdrive.