Issue
112 November 1999
Tuning
into the HA Channel
Command
Parsing
The
PIC-TV uses the same serial routines outlined in my
PIC-DIO article (Circuit Cellar 110). Even though
the PIC-TV screen size is 308 characters, the buffer
size is still 128 bytes because the HCS-II can’t
send more than 96 characters in a single network packet.
The
code architecture is similar to the PIC-DIO. Packets
are received and processed during serial interrupts
and network packets are processed in a main() loop with
case statements.
Because
the PIC-TV’s main function is to display text on
a TV, most of the processing code revolves around handling
string packets from the HCS-II. All control commands
are embedded inside a string command.
The
PIC-TV understands about 35 commands that are sent inside
an output-string command (S=). Table 2 lists the PIC-TV
display command set. Compared to the BOB-II command
set, you’ll notice some commands are just reformatted
and sent directly to the BOB-II.
| Table
2—The PIC-TV command set is based on the
original LCD-Link command set. Commmands are sent
embedded in strings from an HCS-II XPRESS program. |
However,
many of the commands require more processing before
being sent to the BOB-II. Many commands are preceded
by an optional row/column pair, making the command parser
a little involved.
Listing
1 outlines the routine used to parse escape commands
(\e[). As you can see, it is a big case statement with
sections for each command. This technique means the
code is easy to read and didn’t waste much ROM
space for the jump table.
| Listing
1—Much
of the PIC-TV code is dedicated to processing escape
commands embedded in strings sent from the HCS-II.
Functions such as module mode, cursor movement,
and color commands are handled here. Some similar
commands have been removed for brevity. |
The
tricky part is pulling out the optional row and column
numbers. They may or may not be there, and if they are,
they can be one or two digits. If they aren’t there,
they must default to 0.
Once
the numbers are scanned for and stored in the idx and
scratch variables, the command letter is checked. Based
on this command letter, snippets of code are called
to perform the requested function.
idx
and scratch may seem like odd variable names, but this
code was originally done for an LCD interface project
squeezed into a smaller PIC. RAM space was at a premium
so I reused variables whenever possible.
Once
I moved up to a bigger PIC with more RAM, I never switched
to unique variable names. Why waste resources just because
they’re available?
Cursor
Control
The
BOB-II’s cursor control command is limited to moving
the cursor to a specific x,y location.
This provides plenty of flexibility, but only if you
know your position at all times. Tracking a cursor position
in XPRESS would be next to impossible.
To
use these ANSI cursor commands, the PIC-TV chip tracks
the cursor position. When a cursor movement command
is received, the cursor variables are altered and the
BOB-II is sent the cursor’s new x,y
position.
This
way, the PIC-TV can move the cursor using relative (up
x, down y) or absolute values (go to row
y). Another feature is the ability to save and
restore the current cursor position.
Some
commands check the boundary limits, while others do
not. This was done from a usefulness versus extra-cycles-needed
viewpoint.
With
the cursor commands using relative movements, it made
sense to check the boundaries because you wouldn’t
always know exactly where you are in your XPRESS code.
However,
with the absolute position commands, it didn’t
seem worth the cycles needed to check the boundaries.
The BOB-II ignores cursor positions that are out of
bounds. When coding your XPRESS program, knowing that
the limits are 11,27 is sufficient.
