Getting Started

The serial interface on the VDIP2 is similar to a standard RS232 port on a PC, but the voltages are different. In fact, you could cause damage to your PC and/or the VDIP2 if you connected them directly. This issue is solved by using a level converter. It acts as a middle-man between the computer's RS232 serial port and the VDIP2's serial interface, converting the voltages on-the-fly. They can be purchased online from a number of places. I bought the "RCL1" level converter here.

The first order of business was to make sure that the hardware works. Instead of doing a bunch of soldering and then hoping for the best, I used a breadboard. It's a good quick way to test things before committing to a final design.

[Breadboard Wiring] When wired according to the documentation on the VDIP2 datasheet, I couldn't get it to work. Through experimentation, I found that if I swapped the RTS and CTS lines, things worked fine. I'm not sure why.

The wiring for the VDIP2 module was done as follows:

Pin
---
2  -- +5V
3  -- RCL1 Pin1 (Vcc)
12 -- Ground
13 -- RCL1 Pin2 (GND)
14 -- RCL1 Pin3 (TX)
16 -- RCL1 Pin4 (RX)
17 -- RCL1 Pin6 (CTS)
18 -- RCL1 Pin5 (RTS)

The firmware on my VDIP2 module was VDAP v3.04, which is pretty old. There are several ways to upgrade the firmware. I used the existing connection from COM1->RCL1->VDIP2. I went to Vinculum's download site, downloaded and unzipped the VPROG Re-Flash Utility (COM port version), then downloaded the most current version of the VDAP firmware (bootloader/ROM).

The upgrade process:

[Breadboard Wiring for Firmware Flashing] [Upgrading Firmware] Disconnect power from the VDIP2, then connect the PROG# pin (Pin 31 on the VDIP2) to one of the ground pins (I used pin 26). Power up the VDIP2, and launch VPROG_COM.EXE. Select the COM port that the VDIP2 module is connected to, then select the .ROM file that you just downloaded. Click "Program", then pray. Once the flasher program is done writing the new firmware, it'll try to verify. When I tried it, the program hung. I disconnected power, disconnected PROG# from ground, and closed the flasher program. The flash was successful, but it would be nice if the verification could have run. I'm not sure if I did something wrong, or if there's a bug in their flasher program.

Testing:

The first tests were done by manually sending commands, using HyperTerminal. HyperTerminal was configured to use 9600 baud, 8 data bits, no parity, 1 stop bit, and hardware flow control. Then, under File->Properties -> Settings->ASCII Setup there's two checkboxes to check: "Echo typed characters locally" and "Append line feeds to incoming line ends." [Hyperterminal config] [Hyperterminal config]


[Hyperterminal commands] [Hyperterminal command] With HyperTerminal configured, it was time to start issuing commands. The first command is IPA. This tells the VDIP2 to use ASCII characters in response to the commands sent. Next I issued the QP1 and QP2 commands. These commands tell the VDIP2 to report the status of any USB devices that are connected. The results are shown in the picture on the left. Because no USB devices were connected, the result was $00 $00 for both ports.

Next I connected a Logitech Precision Gamepad to port 1 on the VDIP2, then re-issued the QP1 and QP2 commands. The results are shown in the picture on the right. The first byte is the device type. The second byte is always zero. $08 means that a HID-class device is connected (HID stands for Human Interface Device). This is expected, since most gamepads, joysticks, keyboards and mice are HID-class devices.

[Hyperterminal command] Another useful command is QD. This stands for "query device." It returns 32 bytes worth of information about the device connected. The results after issuing the QD 0 command are shown on the left. Although it looks like a bunch of jibberish, it does have meaning. The fourth byte, $08 tells us that we can expect up to 8 bytes of data every time we read from the gamepad. The tenth byte, $01, tells us that the device is physically connected to port 1 on the VDIP2. The twelth byte, $03, tells us the device class. As expected, in the USB Class Codes $03 is a HID (Human Interface Device). Bytes 16 and 15 are the vendor ID. Bytes 18 and 17 are the product ID. A big list of USB IDs is available here. As expected, $046D $C21A is a "Logitech, Inc Precision Gamepad."


Last Update: 8-21-2008