MANAGING YOUR MOBILE MONKEY
recommend that as the user manual never mentions that
possibility. You’ve already figured out that the uDrive’s I/O
pins include a VCC pin, a GND pin, a TX pin, and an RX pin.
The fifth and remaining I/O pin is an active-low RESET pin,
which is tied high internally.
The uDrive “talks” to us by way of a pair of LEDs. When
power is applied, a green LED is illuminated. A red LED tells us
that the memory element mounted on the uDrive is being
accessed. In order for it to talk to us, we must first talk to it.
Talking to the uDrive-uSD-G1
will always return an ACK byte when a valid command is
received. The ACK is represented by a hexadecimal 06
(0x06). Upon receipt of an unknown command, the uDrive
will respond with a hexadecimal 15 (0x15). The 0x15
represents a NAK, or negative acknowledgement.
We want to always try to do things that force us to
process ACK characters and eliminate the need for the
uDrive to pass NAK characters back to the PIC. So, we will
write our application program interface (API) to insure that
complete and recognized commands are always transmitted
to the uDrive by our PIC18F2620.
The device uses standard start-bit-data-stop-bit RS-232
protocol to communicate with a host microcontroller.
However, instead of using true mark (negative voltage
= one) and space (positive voltage = zero) RS-232 voltage
levels, the uDrive’s TX and RX pins tie directly to the serial
port of the host microcontroller it is to support. No
RS-232 converter IC is included in the uDrive-uSD-G1-to-
microcontroller communications link. Thus, a simple three-wire (TX,RX, and GND) TTL serial interface is all that is
required for talking to the uDrive. The serial data format
used is also a defacto standard: (8N1) eight data bits, no
parity, and one stop bit. The uDrive’s and PIC18F2620’s
physical communication link connections can be seen in
Schematic 1. The uDrive is designed for easy implementation.
A native Command Set is part of the internal programming.
The Command Set consists of a General Command Set and a
Disk Drive Operation Command Set.
Commands and data are transferred without any delimiting
characters. In other words, there are no carriage returns, commas, or spaces in the command and data transfer sequences.
The uDrive does not check for correct command syntax.
Therefore, we must make sure that each command is sent
correctly. For instance, a command that is made up of five
bytes will not return an error if only four of the five bytes are
sent. In addition, there are no command timeouts. Considering
our example with four of five command bytes sent, the
uDrive will wait silently — and forever — for that fifth byte.
With the exception of the version command, the uDrive
Building a PIC-Based
uDrive-uSD-G1 System
Before we can write and test our API, we’ll need to
build up some supporting hardware. I’ve already turned your
head towards Schematic 1. So, swivel your noggin to Photo
2 for now. Working our way left to right, the pair of voltage
regulators you see in Photo 2 are a matched set. The LM2940
is a + 5.0 volt low-dropout linear regulator. The voltage
regulator sitting at the LM2940’s output pin is a low-dropout + 3. 3 volt linear regulator. The LM3940 is designed
to stand at the LM2940’s output to provide + 5.0 VDC to
+ 3. 3 VDC voltage conversion. The complementary pair of
voltage regulators can supply up to 1A of current without
the need for an external heatsink. We won’t get anywhere
near the 1A current consumption figure in our design and no
formal heatsinks have been added to the hardware design.
As per the schematic, we will power our uDrive with
+ 5.0 VDC. Since I have chosen the PIC18F2620 instead of
the PIC18LF2620, we must jumper the + 5.0V portion of
the PIC voltage select jumper (JP2). The PIC18F2620 cannot
reliably operate at voltages below + 4. 5 VDC.
At power-up or at forced reset, the uDrive-uSD-G1 will
look for the host to attempt an autobaud detect operation.
To assure that the uDrive does not sense a false start bit, we
must pull the RX line logically high at power-up. I have
done this with pullup resistor R5. Note that I pulled up the
PIC18F2620’s TX I/O pin on the PIC side of the 200Ω
limiting resistor (R4). The placement of R5 insures
that we won’t destroy the integrity of the uDrive’s
+ 5.0 volt I/O tolerance that is provided by resistor
R4. If this were a + 3. 3 volt system, we would
properly jumper JP2 for + 3. 3 volt operation and
place a shorting jumper across JP1 as the + 5.0 volt
I/O tolerance would not be required. Regardless of the
position of JP2, the device is always powered by the
PHOTO 2. What you see here is a simple dual-voltage
linear power supply feeding a minimal PIC18F2620
microcontroller configuration. The uDrive-uSD-G1 stands
out at the far right of the shot. The six-pin header at the
top of the shot is the PIC ICSP programming/debugging
interface. A three-pin voltage selector jumper (JP2)
positioned between the power supply and the
PIC18F2620 is jumpered for + 5.0 volt operation. The
two-pin jumper (JP1) that lies between the PIC and the
uDrive-uSD-G1 is open, allowing the 200ΩRX series
resistor to come into play as this is a + 5.0 volt system.
52 SERVO 05.2008
