The 8051 comes equipped with
two timers, both of which may be controlled, set, read, and
configured individually. The 8051 timers have three general
functions: 1) Keeping time and/or calculating the amount of
time between events, 2) Counting the events themselves, or
3) Generating baud rates for the serial port.
The three timer uses are distinct so we will
talk about each of them separately. The first two uses will
be discussed in this chapter while the use of timers for
baud rate generation will be discussed in the chapter
relating to serial ports.
How does a timer count?
How does a timer count? The answer to this
question is very simple: A timer always counts up. It doesnt
matter whether the timer is being used as a timer, a
counter, or a baud rate generator: A timer is always
incremented by the microcontroller.
Programming Tip:
Some derivative chips actually allow the program to
configure whether the timers count up or down. However,
since this option only exists on some derivatives it is
beyond the scope of this tutorial which is aimed at the
standard 8051. It is only mentioned here in the event that
you absolutely need a timer to count backwards, you will
know that you may be able to find an 8051-compatible
microcontroller that does it.
Obviously, one of the primary uses of timers
is to measure time. We will discuss this use of timers first
and will subsequently discuss the use of timers to count
events. When a timer is used to measure time it is also
called an "interval timer" since it is measuring the time of
the interval between two events.
First, its worth mentioning that when a
timer is in interval timer mode (as opposed to event counter
mode) and correctly configured, it will increment by 1 every
machine cycle. As you will recall from the previous chapter,
a single machine cycle consists of 12 crystal pulses. Thus a
running timer will be incremented:
11,059,000 / 12 = 921,583
921,583 times per second. Unlike
instructions--some of which require 1 machine cycle, others
2, and others 4--the timers are consistent: They will always
be incremented once per machine cycle. Thus if a timer has
counted from 0 to 50,000 you may calculate:
50,000 / 921,583 = .0542
.0542 seconds have passed. In plain English,
about half of a tenth of a second, or one-twentieth of a
second.
Obviously its not very useful to know .0542
seconds have passed. If you want to execute an event once
per second youd have to wait for the timer to count from 0
to 50,000 18.45 times. How can you wait "half of a time?"
You cant. So we come to another important calculation.
Lets say we want to know how many times the
timer will be incremented in .05 seconds. We can do simple
multiplication:
.05 * 921,583 = 46,079.15.
This tells us that it will take .05 seconds
(1/20th of a second) to count from 0 to 46,079. Actually, it
will take it .049999837 seconds--so were off by .000000163
seconds--however, thats close enough for government work.
Consider that if you were building a watch based on the 8051
and made the above assumption your watch would only gain
about one second every 2 months. Again, I think thats
accurate enough for most applications--I wish my watch only
gained one second every two months!
Obviously, this is a little more useful. If
you know it takes 1/20th of a second to count from 0 to
46,079 and you want to execute some event every second you
simply wait for the timer to count from 0 to 46,079 twenty
times; then you execute your event, reset the timers, and
wait for the timer to count up another 20 times. In this
manner you will effectively execute your event once per
second, accurate to within thousandths of a second.
Thus, we now have a system with which to
measure time. All we need to review is how to control the
timers and initialize them to provide us with the
information we need.
As mentioned before, the 8051 has two timers
which each function essentially the same way. One timer is
TIMER0 and the other is TIMER1. The two timers share two
SFRs (TMOD and TCON) which control the timers, and each
timer also has two SFRs dedicated solely to itself (TH0/TL0
and TH1/TL1).
Weve given SFRs names to make it easier to
refer to them, but in reality an SFR has a numeric address.
It is often useful to know the numeric address that
corresponds to an SFR name. The SFRs relating to timers are:
SFR Name
Description
SFR Address
TH0
Timer 0 High Byte
8Ch
TL0
Timer 0 Low Byte
8Ah
TH1
Timer 1 High Byte
8Dh
TL1
Timer 1 Low Byte
8Bh
TCON
Timer Control
88h
TMOD
Timer Mode
89h
When you enter the name of an SFR into an
assembler, it internally converts it to a number. For
example, the command:
MOV TH0,#25h
moves the value 25h into the TH0 SFR.
However, since TH0 is the same as SFR address 8Ch this
command is equivalent to:
MOV 8Ch,#25h
Now, back to the timers. First, lets talk
about Timer 0.
Timer 0 has two SFRs dedicated exclusively
to itself: TH0 and TL0. Without making things too
complicated to start off with, you may just think of this as
the high and low byte of the timer. That is to say, when
Timer 0 has a value of 0, both TH0 and TL0 will contain 0.
When Timer 0 has the value 1000, TH0 will hold the high byte
of the value (3 decimal) and TL0 will contain the low byte
of the value (232 decimal). Reviewing low/high byte
notation, recall that you must multiply the high byte by 256
and add the low byte to calculate the final value. That is
to say:
TH0 * 256 + TL0 = 1000
3 * 256 + 232 = 1000
Timer 1 works the exact same way, but its
SFRs are TH1 and TL1.
Since there are only two bytes devoted to
the value of each timer it is apparent that the maximum
value a timer may have is 65,535. If a timer contains the
value 65,535 and is subsequently incremented, it will
reset--or overflow--back to 0.
Lets first talk about our first control SFR:
TMOD (Timer Mode). The TMOD SFR is used to control the mode
of operation of both timers. Each bit of the SFR gives the
microcontroller specific information concerning how to run a
timer. The high four bits (bits 4 through 7) relate to Timer
1 whereas the low four bits (bits 0 through 3) perform the
exact same functions, but for timer 0.
The individual bits of TMOD have the
following functions:
TMOD (89h) SFR
Bit
Name
Explanation of
Function
Timer
7
GATE1
When this bit is set
the timer will only run when INT1 (P3.3) is high. When
this bit is clear the timer will run regardless of the
state of INT1.
1
6
C/T1
When this bit is set
the timer will count events on T1 (P3.5). When this
bit is clear the timer will be incremented every
machine cycle.
1
5
T1M1
Timer mode bit (see
below)
1
4
T1M0
Timer mode bit (see
below)
1
3
GATE0
When this bit is set
the timer will only run when INT0 (P3.2) is high. When
this bit is clear the timer will run regardless of the
state of INT0.
0
2
C/T0
When this bit is set
the timer will count events on T0 (P3.4). When this
bit is clear the timer will be incremented every
machine cycle.
0
1
T0M1
Timer mode bit (see
below)
0
0
T0M0
Timer mode bit (see
below)
0
As you can see in the above chart, four bits
(two for each timer) are used to specify a mode of
operation. The modes of operation are:
Timer mode "0" is a 13-bit timer. This is a
relic that was kept around in the 8051 to maintain
compatability with its predecesor, the 8048. Generally the
13-bit timer mode is not used in new development.
When the timer is in 13-bit mode, TLx will
count from 0 to 31. When TLx is incremented from 31, it will
"reset" to 0 and increment THx. Thus, effectively, only 13
bits of the two timer bytes are being used: bits 0-4 of TLx
and bits 0-7 of THx. This also means, in essence, the timer
can only contain 8192 values. If you set a 13-bit timer to
0, it will overflow back to zero 8192 machine cycles later.
Again, there is very little reason to use
this mode and it is only mentioned so you wont be surprised
if you ever end up analyzing archaeic code which has been
passed down through the generations (a generation in a
programming shop is often on the order of about 3 or 4
months).
Timer mode "1" is a 16-bit timer. This is a
very commonly used mode. It functions just like 13-bit mode
except that all 16 bits are used.
TLx is incremented from 0 to 255. When TLx
is incremented from 255, it resets to 0 and causes THx to be
incremented by 1. Since this is a full 16-bit timer, the
timer may contain up to 65536 distinct values. If you set a
16-bit timer to 0, it will overflow back to 0 after 65,536
machine cycles.
Timer mode "2" is an 8-bit auto-reload mode.
What is that, you may ask? Simple. When a timer is in mode
2, THx holds the "reload value" and TLx is the timer itself.
Thus, TLx starts counting up. When TLx reaches 255 and is
subsequently incremented, instead of resetting to 0 (as in
the case of modes 0 and 1), it will be reset to the value
stored in THx.
For example, lets say TH0 holds the value
FDh and TL0 holds the value FEh. If we were to watch the
values of TH0 and TL0 for a few machine cycles this is what
wed see:
Machine Cycle
TH0 Value
TL0 Value
1
FDh
FEh
2
FDh
FFh
3
FDh
FDh
4
FDh
FEh
5
FDh
FFh
6
FDh
FDh
7
FDh
FEh
As you can see, the value of TH0 never
changed. In fact, when you use mode 2 you almost always set
THx to a known value and TLx is the SFR that is constantly
incremented.
Whats the benefit of auto-reload mode?
Perhaps you want the timer to always have a value from 200
to 255. If you use mode 0 or 1, youd have to check in code
to see if the timer had overflowed and, if so, reset the
timer to 200. This takes precious instructions of execution
time to check the value and/or to reload it. When you use
mode 2 the microcontroller takes care of this for you. Once
youve configured a timer in mode 2 you dont have to worry
about checking to see if the timer has overflowed nor do you
have to worry about resetting the value--the microcontroller
hardware will do it all for you.
The auto-reload mode is very commonly used
for establishing a baud rate which we will talk more about
in the Serial Communications chapter.
Timer mode "3" is a split-timer mode. When
Timer 0 is placed in mode 3, it essentially becomes two
separate 8-bit timers. That is to say, Timer 0 is TL0 and
Timer 1 is TH0. Both timers count from 0 to 255 and overflow
back to 0. All the bits that are related to Timer 1 will now
be tied to TH0.
While Timer 0 is in split mode, the real
Timer 1 (i.e. TH1 and TL1) can be put into modes 0, 1 or 2
normally--however, you may not start or stop the real timer
1 since the bits that do that are now linked to TH0. The
real timer 1, in this case, will be incremented every
machine cycle no matter what.
The only real use I can see of using split
timer mode is if you need to have two separate timers and,
additionally, a baud rate generator. In such case you can
use the real Timer 1 as a baud rate generator and use
TH0/TL0 as two separate timers.
Finally, theres one more SFR that controls
the two timers and provides valuable information about them.
The TCON SFR has the following structure:
TCON (88h) SFR
Bit
Name
Bit Address
Explanation of
Function
Timer
7
TF1
8Fh
Timer 1 Overflow.
This bit is set by the microcontroller when Timer 1
overflows.
1
6
TR1
8Eh
Timer 1 Run.
When this bit is set Timer 1 is turned on. When this
bit is clear Timer 1 is off.
1
5
TF0
8Dh
Timer 0 Overflow.
This bit is set by the microcontroller when Timer 0
overflows.
0
4
TR0
8Ch
Timer 0 Run.
When this bit is set Timer 0 is turned on. When this
bit is clear Timer 0 is off.
0
As you may notice, weve only defined 4 of
the 8 bits. Thats because the other 4 bits of the SFR dont
have anything to do with timers--they have to do with
Interrupts and they will be discussed in the chapter that
addresses interrupts.
A new piece of information in this chart is
the column "bit address." This is because this SFR is
"bit-addressable." What does this mean? It means if you want
to set the bit TF1--which is the highest bit of TCON--you
could execute the command:
MOV TCON, #80h
... or, since the SFR is bit-addressable,
you could just execute the command:
SETB TF1
This has the benefit of setting the high bit
of TCON without changing the value of any of the other bits
of the SFR. Usually when you start or stop a timer you dont
want to modify the other values in TCON, so you take
advantage of the fact that the SFR is bit-addressable.
Now that weve discussed the timer-related
SFRs we are ready to write code that will initialize the
timer and start it running.
As youll recall, we first must decide what
mode we want the timer to be in. In this case we want a
16-bit timer that runs continuously; that is to say, it is
not dependent on any external pins.
We must first initialize the TMOD SFR. Since
we are working with timer 0 we will be using the lowest 4
bits of TMOD. The first two bits, GATE0 and C/T0 are both 0
since we want the timer to be independent of the external
pins. 16-bit mode is timer mode 1 so we must clear T0M1 and
set T0M0. Effectively, the only bit we want to turn on is
bit 0 of TMOD. Thus to initialize the timer we execute the
instruction:
MOV TMOD,#01h
Timer 0 is now in 16-bit timer mode.
However, the timer is not running. To start the timer
running we must set the TR0 bit We can do that by executing
the instruction:
SETB TR0
Upon executing these two instructions timer
0 will immediately begin counting, being incremented once
every machine cycle (every 12 crystal pulses).
There are two common ways of reading the
value of a 16-bit timer; which you use depends on your
specific application. You may either read the actual value
of the timer as a 16-bit number, or you may simply detect
when the timer has overflowed.
If your timer is in an 8-bit mode--that is,
either 8-bit AutoReload mode or in split timer mode--then
reading the value of the timer is simple. You simply read
the 1-byte value of the timer and youre done.
However, if youre dealing with a 13-bit or
16-bit timer the chore is a little more complicated.
Consider what would happen if you read the low byte of the
timer as 255, then read the high byte of the timer as 15. In
this case, what actually happened was that the timer value
was 14/255 (high byte 14, low byte 255) but you read 15/255.
Why? Because you read the low byte as 255. But when you
executed the next instruction a small amount of time
passed--but enough for the timer to increment again at which
time the value rolled over from 14/255 to 15/0. But in the
process youve read the timer as being 15/255. Obviously
theres a problem there.
The solution? Its not too tricky, really.
You read the high byte of the timer, then read the low byte,
then read the high byte again. If the high byte read the
second time is not the same as the high byte read the first
time you repeat the cycle. In code, this would appear as:
REPEAT:
MOV A,TH0
MOV R0,TL0
CJNE A,TH0,REPEAT
...
In this case, we load the accumulator with
the high byte of Timer 0. We then load R0 with the low byte
of Timer 0. Finally, we check to see if the high byte we
read out of Timer 0--which is now stored in the
Accumulator--is the same as the current Timer 0 high byte.
If it isnt it means weve just "rolled over" and must reread
the timers value--which we do by going back to REPEAT. When
the loop exits we will have the low byte of the timer in R0
and the high byte in the Accumulator.
Another much simpler alternative is to
simply turn off the timer run bit (i.e. CLR TR0), read the
timer value, and then turn on the timer run bit (i.e. SETB
TR0). In that case, the timer isnt running so no special
tricks are necessary. Of course, this implies that your
timer will be stopped for a few machine cycles. Whether or
not this is tolerable depends on your specific application.
Often it is necessary to just know that the
timer has reset to 0. That is to say, you are not
particularly interest in the value of the timer but rather
you are interested in knowing when the timer has overflowed
back to 0.
Whenever a timer overflows from its
highest value back to 0, the microcontroller automatically
sets the TFx bit in the TCON register. This is useful since
rather than checking the exact value of the timer you can
just check if the TFx bit is set. If TF0 is set it means
that timer 0 has overflowed; if TF1 is set it means that
timer 1 has overflowed.
We can use this approach to cause the
program to execute a fixed delay. As youll recall, we
calculated earlier that it takes the 8051 1/20th of a second
to count from 0 to 46,079. However, the TFx flag is set when
the timer overflows back to 0. Thus, if we want to use the
TFx flag to indicate when 1/20th of a second has passed we
must set the timer initially to 65536 less 46079, or 19,457.
If we set the timer to 19,457, 1/20th of a second later the
timer will overflow. Thus we come up with the following code
to execute a pause of 1/20th of a second:
MOV TH0,#76;High byte of 19,457 (76
* 256 = 19,456) MOV TL0,#01;Low byte of 19,457 (19,456 + 1 =
19,457) MOV TMOD,#01;Put Timer 0 in 16-bit mode SETB TR0;Make Timer 0 start counting JNB TF0,$;If TF0 is not set, jump back to this same
instruction
In the above code the first two lines
initialize the Timer 0 starting value to 19,457. The next
two instructions configure timer 0 and turn it on. Finally,
the last instruction JNB TF0,$, reads "Jump, if TF0
is not set, back to this same instruction." The "$" operand
means, in most assemblers, the address of the current
instruction. Thus as long as the timer has not overflowed
and the TF0 bit has not been set the program will keep
executing this same instruction. After 1/20th of a second
timer 0 will overflow, set the TF0 bit, and program
execution will then break out of the loop.
The 8051 provides another cool toy that can
be used to time the length of events.
For example, let's say we're trying to save
electricity in the office and we're interested in how long a
light is turned on each day. When the light is turned on, we
want to measure time. When the light is turned off we don't.
One option would be to connect the lightswitch to one of the
pins, constantly read the pin, and turn the timer on or off
based on the state of that pin. While this would work fine,
the 8051 provides us with an easier method of accomplishing
this.
Looking again at the TMOD SFR, there is a
bit called GATE0. So far we've always cleared this bit
because we wanted the timer to run regardless of the state
of the external pins. However, now it would be nice if an
external pin could control whether the timer was running or
not. It can. All we need to do is connect the lightswitch to
pin INT0 (P3.2) on the 8051 and set the bit GATE0. When
GATE0 is set Timer 0 will only run if P3.2 is high. When
P3.2 is low (i.e., the lightswitch is off) the timer will
automatically be stopped.
Thus, with no control code whatsoever, the
external pin P3.2 can control whether or not our timer is
running or not.
We've discussed how a timer can be used for
the obvious purpose of keeping track of time. However, the
8051 also allows us to use the timers to count events.
How can this be useful? Let's say you had a
sensor placed across a road that would send a pulse every
time a car passed over it. This could be used to determine
the volume of traffic on the road. We could attach this
sensor to one of the 8051's I/O lines and constantly monitor
it, detecting when it pulsed high and then incrementing our
counter when it went back to a low state. This is not
terribly difficult, but requires some code. Let's say we
hooked the sensor to P1.0; the code to count cars passing
would look something like this:
JNB P1.0,$
;If a car hasn't raised
the signal, keep waiting
JB P1.0,$
;The line is high which
means the car is on the sensor right now
INC COUNTER
;The car has passed
completely, so we count it
As you can see, it's only three lines of
code. But what if you need to be doing other processing at
the same time? You can't be stuck in the JNB P1.0,$ loop
waiting for a car to pass if you need to be doing other
things. Of course, there are ways to get around even this
limitation but the code quickly becomes big, complex, and
ugly.
Luckily, since the 8051 provides us with a
way to use the timers to count events we don't have to
bother with it. It is actually painfully easy. We only have
to configure one additional bit.
Let's say we want to use Timer 0 to count
the number of cars that pass. If you look back to the bit
table for the TCON SFR you will there is a bit called
"C/T0"--it's bit 2 (TCON.2). Reviewing the explanation of
the bit we see that if the bit is clear then timer 0 will be
incremented every machine cycle. This is what we've already
used to measure time. However, if we set C/T0 timer 0 will
monitor the P3.4 line. Instead of being incremented every
machine cycle, timer 0 will count events on the P3.4 line.
So in our case we simply connect our sensor to P3.4 and let
the 8051 do the work. Then, when we want to know how many
cars have passed, we just read the value of timer 0--the
value of timer 0 will be the number of cars that have
passed.
So what exactly is an event? What does timer
0 actually "count?" Speaking at the electrical level, the
8051 counts 1-0 transitions on the P3.4 line. This means
that when a car first runs over our sensor it will raise the
input to a high ("1") condition. At that point the 8051 will
not count anything since this is a 0-1 transition. However,
when the car has passed the sensor will fall back to a low
("0") state. This is a 1-0 transition and at that instant
the counter will be incremented by 1.
It is important to note that the 8051 checks
the P3.4 line each instruction cycle (12 clock cycles). This
means that if P3.4 is low, goes high, and goes back low in 6
clock cycles it will probably not be detected by the 8051.
This also means the 8051 event counter is only capable of
counting events that occur at a maximum of 1/24th the rate
of the crystal frequency. That is to say, if the crystal
frequency is 12.000 Mhz it can count a maximum of 500,000
events per second (12.000 Mhz * 1/24 = 500,000). If the
event being counted occurs more than 500,000 times per
second it will not be able to be accurately counted by the
8051.
