leddrvr - Copyright (c) 2002 Tundraware Inc., All Rights Reserved
$Id: readme.txt,v 1.4 2002/03/25 17:12:37 tundra Exp tundra $
PLEASE NOTE: Before using anything in this archive, you must read, and
agree to abide by, the licensing terms found in:
Makefile Unix-style makefile which runs under DJGPP and
should also work under MKS and Cygwin.
README.txt This file.
leddrvr-license.txt Licensing terms for using this software.
leddrvr-sch.gif leddrvr schematic in GIF format.
leddrvr-sch.png leddrvr schematic in png format.
leddrvr-sch.ps leddrvr schematic in PostScript format.
leddrvr-sch.sch leddrvr schematic in Eagle format.
leddrvr.asm leddrvr software written in PIC assembler.
leddrvr.hex The assembled leddrvr software.
leddrvr.lst leddrvr listing file generated by assembler.
leddrvr.xrf leddrvr cross-reference file generated by assmbler.
WHAT IS 'leddrvr'?
'leddrvr' is a simple 7-segment LED display driver system using PIC
technology. The idea is to use minimum parts count to drive up to 4,
7-segment LEDs. This is also a useful introduction to some of the PIC
microprocessor programming techniques insofar as 'leddrvr' exercises
many of the basic features of these chips including:
- Programming & use of the TMR0 timer & prescaler
- Timer-based interrupt handling
- Asynchronous application/interrupt interaction.
- Display multiplexing
HOW DOES THE HARDWARE WORK?
Like many PIC-based projects, this system is realized with a minimum
parts count. Besides the usual clock and MCLR pull up circuitry,
'leddrvr' is realized by having PORTA connected to the individual LED
segments and PORTB connected to the LED selects (cathodes). Several
- The convention used in both the hardware and software design is
that 'LED0' is the Least Significant Digit (LSD or rightmost)
and 'LED3' is the Most Significant Digit (MSD or leftmost).
- The schematic and software assume a "common cathode" type
7-segment display, whose individual segments are acceptably
bright at less than 25ma current.
- R2-R9 should be selected so that the PIC is never required to
deliver more than its rated current (25ma) to an LED segment.
A typical value here is probably between 150-330 ohms.
- Although not shown on the schematic, a given segment position
on each LED is wired to the corresponding position on the other
LEDs and then connected to the PIC. For example, all the 'a'
segments are connected to each other and RB0. In effect, this
means when a segment pattern is output by the PIC it is sent to
*all* the displays. However, this pattern only actually appears
on those displays selected via an 'on' bit on RA0-RA3.
- RA0-RA3 are used to select which of the digits are to display
the segment pattern currently presented on RB0-RB7. This is how
the software is able to multiplex the display. Each time a TMR0
overflow interrupt occurs (1ms intervals), the software
determines the digit to update, presents its current segment
pattern, and then selects that digit as 'on' via its
corresponding cathode transitor. Because this update takes
places very rapidly, all digits appear to be displayed
simultaneously when, in fact, only one is on at a time.
HOW DOES THE SOFTWARE WORK?
The best way to understand the software is to read the code which
contains a fair number of explanatory comments.
At a high-level, here's what's going on:
- At startup, the chip jumps to memory location 0 which contains a
jump to the mainline code ('main:'). This is necessary because
the PIC chip expects to find an interrupt handler at location 4
and we have to jump around that handler.
- The first thing done is to call the 'init:' subroutine which
initializes the hardware, the timer, and various program
variables to run properly.
- Then we sit in a loop running our 'application software'. In
this case, our 'application' does nothing more than increment at
16-bit count stored 'dsply_val' array. It then calls the
'wait:' subroutine to kill some time. This is done so that you
can actually watch the count on the display. Try removing the
call to 'wait:' and see what happens - the rightmost digits are
changing so fast you cannot distinguish the individual count.
- 'init:' setup the prescaler and TMR0 so that the timer count
overflows every 1ms - i.e., A TMR0 interrupt is generated
1000/sec. The Interrupt Service Routine (ISR) which services
these interrupts is found beginning at location 4.
- Before the ISR can do anything useful, it must save the current
state or "context" of the system. This is then restored when
we exit the ISR so that we do not clobber any registers in
use by the main program that was interrupted.
- The TMR0 ISR does two things:
1) It increments a wait count which is used by the 'wait:'
subroutine to kill time. You can set how long each call to
'wait:' will be by changing the 'count_delay' constant.
2) It determines whose turn (which digit) it is to be
displayed and does so via 'display_led'.
- Notice that the main application and ISR are 'asynchronous' to
each other. That is, they never call each other directly or
wait for one another. They work independently in time from one
another. So, they have to have a way to communicate. They do
so by sharing the 'dsply_val' array and 'wait_count' variable.
The 'led_display' routine assumes that the value it is expected
to display is stored (in binary) in the 'dsply_val' array,
starting with the Least Significant Digit and moving towards the
Most Significant Digit as it moves down the array. Any application
is free to update this array as it sees fit - in our example case,
we just count up in binary - and the Interrupt Service Routine
will see to it that the display is updated accordingly.
Similarly, the 'wait:' subroutine primes the 'wait_count'
variable with the desired waiting time and then periodically
inspects it to see if it has decremented to 0. However, it is
logic in the Interrupt Service Routine that actually does the
There are several places where timing can be tricky, which, although
not a problem here, probably should be mentioned:
- It is important that the 'wait:' subroutine be short enough so
that any change in 'wait_count' can be read before the next TMR0
interrupt happens and the variable is updated again. If this is
not the case, 'wait:' may not detect 'wait_count' decrementing
to 0 and end up waiting longer than it should. In the worst
case, 'wait:' could be just long enough so that it ends up in
sync with the code in the ISR that modifies 'wait_count'. In
that case 'wait:' would *never* see the decrement to 0 and it
would thus end up becoming an infinite wait. So long as 'wait:'
runs in much less time than the TMR0 interrupt interval, AND it
is not being interrupted so frequently by other interrupt
sources so as to miss the TMR0 interrupt which updates the
count, this is not a problem.
To avoid this problem entirely, the approach used here is to
prevent 'wait_count' count from rolling over from 0x00 to 0xff.
Even if 'wait:' misses one or more interrupts, it will eventually
detect 'wait_count' == 0 and end the timing loop.
- Commonly, the TMR0 interrupt rate (in this case 1000 per second)
is not exactly the rate at which its service routine runs. This
is because interrupts are disabled during the ISR and only
enabled again *after* the interrupt has been serviced. This
means that the effective TMR0 interrupt service interval is
slightly *more* than 1ms. It ends up being 1ms + Time To Service
TMR0 Interrupt because the TMR0 timer is not running during the
It is possible to enable selected interrupts while an ISR is
running, but this makes things much more complex because you have
to do a context save *per interrupt*. This is hard to do on a
PIC because it is not a stack-based architecture and there are
very limited amounts of dynamic memory for storing such things.
So, it is highly preferred that interrupts stay off during an ISR
thereby guaranteeing that we only need to save a single context
at a time.
Having said this, it is possible to selectively enable interrupts
while running an ISR is you are certain that:
* You will *never* see another interrupt among those you are
enabling while you are still in the ISR. This guarantees
that you only need a single context save area.
* You parse for the various kinds of interrupts coming in
and provide a separate context save area for each.
In 'lddrvr' we *enable* the TMR0 interrupt during the ISR because
we know the ISR execution time (about 70us) is far less than the
TMR0 interrupt interval (1ms). We restart the TMR0 timer before
actually servicing the interrupt to keep the timer interval as
close to 1ms as possible. If we did not do this, the TMR0
interrupt interval would end up being 1ms + ISR Computation Time.
Try it - stub out the interrupt enabling code in the TMR0 ISR and
you'll see that the effective timer rate ends up being something
around 1.07ms. (You can measure this by connecting an
oscilloscope to any one of the 2N700 gates and watching the pulse
train there. Just remember to divide those timings by 4 since
you only see every 4th interrupt at a given transistor.)
HOW COULD 'leddrvr' BE IMPROVED?
The big problem with this design is that it uses up all but one of the
available I/O pins on the 16F84A PIC. This really limits how useful
'leddrvr' is in its current form (although it can be used to build
timers and stopwatches pretty much as-is). There are a number
of ways we could solve this problem with some hardware changes:
- Use a PIC with more I/O pins.
- Use a decoder to select the LED cathode enable. With 4 LEDs
we only actually need 2 bits to select them uniquely, rather
the 4 we are currently using.
- Use an 8-bit shift register to select the segments for display.
This can be done with only 2 I/O pins instead of the 8 we
- Use a dedicated LED driver system like the Maxim MAX7219 to
offload all this work from the PIC. This requires only 3 I/O
pins total because the MAX7219 uses a serial interface.
There are also some things that could be improved in the software:
- There are probably some small optimizations possible to reduce
code size and improve speed slightly.
- There are probably bugs in this code. If you find any, let me
know. Me email address is at the end of this file.
I'D LIKE TO THANK THE ACADEMY...
Lots of nice people on Usenet answered my stupid questions as I've
been learning the PIC. Their help is very much appreciated.
You should feel free to poke around the code, change things, and
generally experiment with what is there. It's the best way I know to
learn something new. If you have any other thoughts / fixes /
questions / improvements for 'leddrvr', please let
Happy Hacking! ...