■ FIGURE 4. GPS
It doesn’t matter which you use,
just pick a strategy
and stick with it so
you can port your
program to program
To finish with
the time, the local UTC offset is added to the hours and
corrected to keep the value 0 to 23. We can send the UTC
offset to the module with the “U” command; this lets us get
localized time back and not have to deal with that on the
host side. The UTC offset is always positive, so to handle a
negative offset (as in - 8 hours for Hollywood, CA), we will
add that value to 24.
As you look through the full listing, you’ll see that the
majority of the commands work like Get_Time, plucking
requested values from the GPS string and sending them
back to the host.
this limitation is dealt with by creating shadow registers of
the current TRIS states. When we use a command that
affects a pin’s I/O direction, this register is read, modified,
and then written back to the associated TRIS register
for that pin. We’re going to take advantage of this
shadow register to make those eight hacker pins look like
one contiguous port.
On receipt of an “X” command to the GPS module, the
program jumps to a section that processes one of three
secondary commands for the port: “S” for setup (set TRIS),
“W” for write bits, and “R” for read bits. Before we get to
that, let’s look at the individual pin assignments for what I’m
calling the xport:
At the top I started by saying the GPS module was
hacker-friendly, and it is, but it’s not entirely hacker-convenient. The realities of PCB design sometimes get us —
and they do with the extra “hacker pins” on the module.
Figure 4 shows the bottom of the Parallax GPS module. On
the left is the host connection port, the white connector
at the lower left goes to the GPS receiver, and you can
clearly see the SX20, the hacker pads, and the pads for
reprogramming using an SX-Key or SX-Blitz.
There are eight hacker pads and, in an ideal world,
these would have been mapped to port RB on the SX20.
In the real world, however, they’re not. My guess is that
this would have complicated the PCB. No problem, we’ll
“fix it in software” (as a product manager, I always hated
hearing that phrase, and I use it only teasingly — nothing
This “problem” actually gives us an opportunity to
explore a bit more of SX/B. In the SX20 and SX28, the
data direction (TRIS)
registers are not readable, they can only be
written. In the BASIC
Stamp and in SX/B,
I know from these assignments that it seems the bits are
all over the place. Figure 5 shows the remapping of the
xport bits — you can see the organization is set up to make
things easy to remember.
The “XS” command sequence lets us set up the xport
pins like any other SX port, and we will use SX conventions,
that is, a 0 bit indicates an output, a 1 bit indicates an input.
Here’s the code:
tmpB1 = __PARAM1
tmpB2 = TRIS_A
tmpB2.0 = tmpB1.0
tmpB2.1 = tmpB1.1
TRIS_A = tmpB2
tmpB2 = TRIS_B
tmpB2.1 = tmpB1.2
tmpB2.0 = tmpB1.3
tmpB2.7 = tmpB1.4
tmpB2.6 = tmpB1.5
tmpB2.4 = tmpB1.6
tmpB2.5 = tmpB1.7
TRIS_B = tmpB2
As you can see, there are really two sections to this
code: one for each of the SX ports (RA and RB). What we
have to do is get a copy of the TRIS shadow register, modify the appropriate bits without touching the others, and then
write it back. This is, in fact, what a lot of SX/B functions do
when there is a necessary
I/O state for an instruction. This method ensures
that the port pins not
associated with our xport
are not adversely affected.
Okay, now that the
port bits are set up, the
write and read methods
are downright trivial.
■ FIGURE 5.
GPS X Points.
GRAND IDEA STUDIO