Issue
158 September 2003
The
XY-Plotter
Drive
High-Resolution LCDs For Less
Mad
Dash for Flash Cash Contest Winner
PROTOTYPE
ASSEMBLY
I
built a simple PCB for this project (see Photo 2). All
the components fit easily because I wanted the size
of the PCB to be identical to the LCD. Note that the
front panel components, including the push buttons and
RS-232 connector, are soldered on the bottom. All of
the trimmers are easily accessible with a screwdriver,
because they are laterally shifted from one to the other.
|
(Click
here to enlarge)
|
Photo
2—The analog front end is on the upper left with
its nine trimmers, the power supplies are on the
top right, and the PIC is in the middle. The PCB
has plenty of empty space because the LCD’s dimensions
dictated its size. |
FIRMWARE
DESIGN
The
hardware side of this project was straightforward, so
if you’re imaging that the firmware was more difficult,
you’re right. Figure 6 illustrates the overall architecture.
In order to comply with the requirement of seven instructions
per nibble, I didn’t use an interrupt. I built a fully
sequential program flow.
|
(Click
here to enlarge)
|
Figure
6—The most critical section of this chart, which
shows the architecture and timing of the firmware,
is the graphic display routine. Basically, 71 nibbles
must be sent in 30 µs, giving 422 ns per nibble
or four PIC instructions per nibble (even at 40
MHz). |
A
main loop is executed every 15.8 ms. It starts with
a frame-batch routine that manages the push buttons,
and more importantly reads the auxiliary inputs (analog
and digital) and generates the text that will be displayed
in the first lines. The text is stored as ASCII characters
in RAM using 90 bytes (3 × 30).
If
you want to study the binary-to-decimal conversion routine,
which I found on the ’Net, refer to the Resources section
at the end of this article. The frame-batch routine
also manages the UART by way of a simple protocol. Then
a loop is executed for each of the 240 columns in the
display. At each iteration, a line-batch routine is
first executed. This routine reads and manages the x
and y analog values (storing y minimum, maximum, and
sample values for each x value in three 256-byte RAM
areas). The display blanking (i.e., y is not stored
when x is reducing) is also managed.
The
last step is tricky. For each line, the firmware must
generate the nibbles to send the LCD on the fly. It
must first send the nibbles corresponding to the graphic
area (the back of the screen depicted in Figure 1) and
then the ones for the three text lines at the top. Now
let’s discuss the details.
GRAPHIC
DISPLAY
How
can you generate the graphic display on the fly? The
fixed parts (e.g., borders and scales) are easily sent
to the LCD with the proper timing. The graph is built
in real time from the minimum, maximum, and sample values.
It also depends on the display mode (see Figure 7).
|
(Click
here to enlarge)
|
Figure
7—Four display modes are supported by the XY-Plotter.
Sample mode simply plots the first y value acquired
for each x value. The Maximum mode plots the highest
y for a given x. The Mean mode isn’t in fact a true
mean; it simply displays the midpoint of the minimum
and maximum values. Last but not least is Peak mode,
which displays a line showing all of the y values
measured for a given x. |
The
LCD is used in Vertical mode (320 pixels high), so the
scan is vertical, too. Thus, the successive nibbles
sent to the LCD correspond to successive vertical blocks
of four pixels. In order to generate them, an optimized
algorithm is implemented based on another trick: For
each column, there is only one black line surrounded
by whites. First, the black line’s two extremities (ystart
and ystop) are calculated based on the operating mode.
Then, a loop sends an optimal number of fully blank
nibbles followed by (depending on the ystart and ystop
values) precalculated bitmaps that correspond to the
different situation and are stored in a precalculated
table as well as full black or full white nibbles in
good quantity. For reasons of efficiency, the flash
memory-based table is cached at startup in a RAM page.
Figure 8 provides visual description of the algorithm.
|
(Click
here to enlarge)
|
Figure
8—The 4-bit nibbles are generated in real time for
each of the LCD’s scan lines based on the position
of the first and last black pixel on that column.
The firmware first calculates how many 0000s must
be sent, and then two things can happen: If all
the black pixels to draw are in the same nibble,
then a combined white/black/white nibble is extracted
from a table and sent to the display (on the right).
Otherwise, one white/black transition nibble is
sent, followed by the required number of full black
nibbles, and followed by one black/white transition
nibble (on the left). |
