'LCD Display Options'
I am new to the PICLIST and have a general design question. I am
interested in designing an application using a PIC to, among other
things, control graphic display on one of the newer type graphic
(possibly with touch screen) LCD displays. Does this seem possible
using a PIC, given the high density of data for the required graphic
images? Should it be possible with a few EPROMS for the display
Obviously I am in the initial design stage and need to consider all
the most feasible options before jumping right in. The purpose of the
display is to provide feedback from monitored sensors, probably
handled by a separate PIC. Any input is greatly appreciated.
Bill <So much to do, So little time> Kichman
|I am new to the PICLIST and have a general design question. I am
|interested in designing an application using a PIC to, among other
|things, control graphic display on one of the newer type graphic
|(possibly with touch screen) LCD displays. Does this seem possible
|using a PIC, given the high density of data for the required graphic
|images? Should it be possible with a few EPROMS for the display
I think the answers to your question will depend upon two major
 What you want to display (and at what resolution)
 How much CPU time you can afford keeping the display up
If your goal is to have, e.g., a 240x64 dot matrix screen which
will be used to display 30 or 40 column text, then you may be
able to get by with one of the larger PICs and no external mem-
ory (the text alone, at 30x8 characters, would be 240 bytes. If
you want fewer, bigger charactacters (e.g. 20x4) then even more
moderate-sized PICs may suffice. Note that since you'll be def-
ining character shapes yourself, you will be able to obtain a
fair number of graphical effects (e.g. with box-drawing characters
as used on the PC and many machines before it).
As for display speed, figure that at minimum you'll want 40 frames
per second (and almost certainly more). Most displays take in data
4 bits at a time; on a 240x64 display, that would be 60 clumps of
data per row, times 64 rows, or 3840 clumps per frame. At a frame
rate of 40fps, that yields a data rate of 153,600 clumps/second.
Not beyond the realm of possibility, but it doesn't give much time
for the PIC to do anything else.
Once you have a display (e.g. 240x64) the first thing you'll need
to determine is how it's mapped. There are two ways I've seen
or heard of LCD panels wired:
 Each group of 4 bits you clock represents four consecutive
pixels on the screen. This is the ideal format for your
applications, but not all displays are wired like this.
 Each group of 4 bits you clock in represents four non-consec-
utive pixels on the screen (e.g. on a 240-dot screen, the
first group of pixels clocked in may be pixels 0, 60, 120, and
180, the second group may be 1, 61, 121, and 181, etc. Your
code may have to do some tricky data manipulations to crank out
a text display in real time with such a panel.
 The display is divided into four quadrants, and one bit from
each foursome serves each quadrant. These displays are elect-
rically the same as a display twice as wide and half as tall
which "wraps back" for the bottom half. If the screen lay-
out is amenable to this (e.g. if no characters need to be drawn
across the "seam") this is no problem. Otherwise it may be a
Note that while it's possible to add RAM external to a PIC to hold
the current screen data, in practice once you get to that point
you're probably better off using a premade assembly with a control-
ler built-in. Unless you want to do a controller yourself for the
sheer thrill of doing it, you're probably better off focusing on
the rest of your application.
More... (looser matching)
- Last day of these posts
- In 1998
, 1999 only
- New search...