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? 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.
USING TIMERS TO MEASURE TIMEObviously, 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.
How long does a timer take to count?
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:
When you enter the name of an SFR into an assembler, it internally converts it to
a number. For example, the command:
moves the value 25h into the TH0 SFR. However, since TH0 is the same as SFR address
8Ch this command is equivalent to:
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:
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:
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:
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:
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:
... or, since the SFR is bit-addressable, you could just execute the command:
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:
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:
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:
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:
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.
USING TIMERS AS EVENT COUNTERS
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:
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.
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
MOV TH0,#25h
MOV 8Ch,#25h
TH0 * 256 + TL0 = 1000
3 * 256 + 232 = 1000
TMOD (89h) SFR
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:
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
TxM1 TxM0 Timer Mode Description of Mode 0 0 0 13-bit Timer. 0 1 1 16-bit Timer 1 0 2 8-bit auto-reload 1 1 3 Split timer mode
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
TCON (88h) SFR
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.
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
MOV TCON, #80h
SETB TF1
MOV TMOD,#01h
SETB TR0
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.
REPEAT: MOV A,TH0 MOV R0,TL0 CJNE A,TH0,REPEAT ...
MOV TH0,#76;High byte of 19,457 (76 * 256 = 19,456)
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.
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
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.
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
Previous: Low-Level Information/Timing
Tutorial Contents
Next: Serial Port Operation