I've wired everything up according to directions from the above link and from the VDIP1 instructions. I followed the above directions and connected the control lines together.
The VDIP1 can communicate in several different protocols. UART serial is selected by setting the jumpers all to one side (either side works). Once you set the jumpers for your protocol you can read the pinouts from the chart in the instructions.
Currently I have AD0/AD1 wired as TX/RX (remember that TX from one device connects to the RX of the other device, and vice versa), the ground from the TX/RX side connected to common ground (there is a ground on the opposite side and I'm not sure exactly why there are two of them), 5V0 pin connected to 5V power, and CTS is wired directly to RTS (pins AD3 and AD2. This makes it so every request to send is always greet with a clear to send signal).
Currently when I power on the board I get flashing blinken lights that go back and forth a couple of times, pause and go again. According to the documentation this means I'm in serial UART and everything looks right, but that the board is waiting for a serial monitor (serial connection) to be initialized.
I am using the same code that is in the example to open the connection.
Current thoughts on the source of this problem:
-Crummy/broken connection-can be checked with multimeter.
-the control lines really should be used.
-The usb memory stick I'm using isn't compatible-can be checked by using another memory stick.
-Damaged/Defective VDIP1-always a possibility, but all signs (blinkenlights) point to no
You can discount the dodgy memory stick - the vdip would still establish a connection, but would tell you no disk present, or fil when you try to write.
What have you got connected to the vdip1 - is it an arduino, mini etc....
It can be difficult to troubleshoot as you have to hook the serial up to the arduinos serial to control it, so you can't see whats coming back. If its not a mini then you can remove the avr chip from the arduino board and use the serial chip on the board to talk directly to the vdip1 with the computer using something like z term on the mac. This means you can see what messages are being sent back.
If the only code you are sending at the moment then is the 3 lines you quote then I would expect the lights to flash and then stop - you have initialised the serial port, sent it as message to say that numbers will be in ascii - it will reply ok, and then wait for the next message from you before it does anything. No more activity will happen until you instigate it with another message.
I found softwareSerial a useful debugging tool for my limited experience with the VDIP1. I used the hardware UART to connect the ATmega to the VDIP, and used softwareSerial to send debugging/status information to another serial port attached to a host computer.
I found that the VDIP1 was almost useless without the hardware flow control lines, and that by ignoring those lines you can get all sorts of nasty results: no data file, corrupted data file, and even a completely corrupted filesystem, requiring a reformat of the USB drive to get it operational again.
I hope to have another go at it, this time including some hardware handshaking like the documentation says...
What kind of quantity of info were you sending and how often?
I was aware that disregarding the RST and CST lines might be problematic but it is working ok here at the moment - I am sending a character and number to the disk no more than 2 or 3 times a second.
I was trying to write about 100 - 120 bytes at a time. Since I had already made the (wrong) hardware design decision to leave off handshaking, I simply included delays between each byte until such time the system would reliably write the data without corrupting the data/filesystem or otherwise failing. I can't remember the delay between bytes, but the whole record took about 45 seconds to write. This was excruciatingly slow, and uselessly slow for some other projects I have in mind for the device. Getting the hardware handshaking up and running is a must for future projects with this device.
I will add to the playground page more specifically warning people about the dangers of longer data runs without hardware handshaking, and the slowness of the write process compared to the speed that the arduino could send data to be written.
Oh, and I need to point out that the playground example did not lead me astray - I made that mistake all on my own. As best I recall from some posts, we were developing at about the same time.
I finally got to working on it today. I did a multimeter test and all my connections are good/clean. I'm sure I'm in the correct mode (UART serial, all jumpers to one side).
I'm sending a data at a high data rate. Based on the demo code I figured that without the control lines I'd just be missing some data. I guess I might be wrong.
I may write some debugging code that outputs to the lcd on softserial. This should get me an idea if actual communication is taking place
I'm looking forward to more info on the proper handshaking procedures. I figure I've got the right idea but I'll continue to work on it/reread some documentation (should just be: wire cts to one digital in wire rts to another. Send handshake, get response, use a while statement to pause and wait to send data).
current code:
void setup(){
pinMode(rxPin, INPUT);
pinMode(txPin, OUTPUT);
LCDSerial.begin(9600);
//setup the accelerometer and screen
Serial.begin(9600);
Serial.print("IPA"); //to vdip logger
Serial.print(13, BYTE); //to vdip logger
//put wait code to look and see if there is a
//response from the VDIP1. If there isn't try connecting again
//read the root dir in the memstick to set the
//log file's name/number (its sequential)
Serial.print("DIR");
Serial.print(13, BYTE);
LCDSerial.print("initialized");
//read
int tfilenum = 0;
while(Serial.available() > 0){
//look for "LOG"
int input = Serial.read();
LCDSerial.print(input);
if (input == 76){ //L
input = Serial.read();
if (input == 79){ //O
input = Serial.read();
if (input == 71){ //G
//get the numers after "LOG"
input = Serial.read();
tfilenum = input - 48;
input = Serial.read();
while (input > 48 && input < 58){
input = Serial.read();
tfilenum = tfilenum * 10 + input - 48;
}
}
}
}
}
logfilecount = tfilenum + 1;
//this next line for debug only
delay(500);
backlightOn();
clearLCD();
Ok I've spent some time trying to debug this issue.
I've done the following/observed the following:
-Tested all the connections for continuity. All are good. (I measure some resistance vs no resistance when connecting one end to the other)
-Tested multiple usb sticks...same result
-I always get the blinken lights right/left and back again then pause and it starts again. This happens whether or not I have a usb stick connected or not. According to the firmware docs this means "no serial" is connected.
-CTS and RTS are directly connected. This should really have nothing to do with the lack of a serial monitor connection. RTS and CTS should only have to do with writing to disk right??
-I only have the Ground connected on the side of the CTS RTS pins. On the other side were the TX and RX lines the Ground is not connected (should it be??)
I would connect the vdip straight to a serial connection to the computer and have a look at what messages are coming out from it if anything. and have a go at sending commands using z term and see that I got the correct responses to test whether the vdip module is ok.
I tried putting a ground to the other pin and it didn't do anything.
Just so I do this right...how do I connect the VDIP1 directly to a serial connection?
I've got the serial pinout and all but serial runs on +/-12V if I'm not mistaken so. I just want to make sure I'm not messing anything else up.
I could just plug serial TX from the vdip to a serial in pin on a computer, but the device is currently installed, semipermanently, so taking it all apart to debug this would mean a lot of extra work.
In the interim I'm going to set up a few lines to just listen for what is being received by the arduino. I'll spam it to the LCD and be able to tell if anything is getting in.
I could just plug serial TX from the vdip to a serial in pin on a computer,
No, you can't. the VDIP interface is at TTL voltages/levels. The compute is at RS232 voltages/levels. You'll need a MAX232 or equivalent circuitry as a transceiver.
IIRC I tied the hanshake pins on the VDIP to ground, and certailnly every pin that says GND should be tied to ground.
Sorry - I meant to a serial usb adapter like the one on an arduino board, or a standalone one like the ones ftdi sell that will be working at 5v - not straight into a 12v one.
Followup on ground pins: I tied pins 7, 10, 12, 13, 18 on the VDIP1 to ground. I think 7 and 18 are GND, the others are handshake inputs (which, IIRC, effectively signal that the ATmega is always ready and the VDIP can send whenever it wants).
I think I may be a smidge closer to a solution. I was trying to debug some stuff by having it go to the LCD when one of the status led's stuck on. I was able to repeat this a couple of times.
I'm thinking there is a loose connection somewhere and I might as well redo all the connections while I'm at it.
I'm starting to look over the SPI documentation and it looks like it might be simpler to interface everything this way. I'm also considering buying a new vdip as I may have fried the one I have somehow.
If i'm successful I will promise to make a playground page dedicated to making this thing work via SPI.
I've hosed mine up as well, turned off the power during a firmware upgrade (thought I was powering it on, but it was already on. Oops, gotta make a serial programming rig for it now.)
The big downside I see to SPI is that the transfers are not on byte boundaries - there are 3 bit responses, IIRC. As best I can tell this is not conducive to using the ATmega SPI hardware, which seems to be built around 8 bit transfers.
The parallel interface doesn't look too bad, other than the large number of pins required.
As best I recall from some posts, we were developing at about the same time.