| |
 |
The 8051
|
|
|
|
| |
|
| |
|
| |
Serial Communication |
| |
|
| |
All communication we have dealt with up to now has been parallel.
Data being transferred between one location and another (R0 to the accumulator,
for example) travel along the 8-bit data bus. Because of this data bus,
data bytes can be moved about the microcontroller at high speed. |
| |
However, parallel communication has the disadvantage of requiring
at least eight separate lines (in an 8-bit system) and in most cases extra
lines to synchronize the data transfer (in the case of the microcontroller,
the control bus). |
| |
Serial communication has the advantage of requiring only
one line for the data, a second line for ground and possibly a third line
for the clock. Therefore, because serial communication requires less physical
wires, it is more suitable for transmitting data over longer distances. |
| |
The obvious disadvantage of serial communication, compared
with parallel, is the reduction in the data transfer rate. If we imagine
a system where it takes 1us for data to settle on the data bus, we could
say it takes 1us to transfer a data byte using parallel communication. If
we imagine the same timeframe for data bits settling on the serial line,
it would take 8us to transfer a data byte using serial communication (1us
for each bit). |
| |
|
| |
Synchronous Serial Communication |
| |
Synchronous serial communication requires an extra line for
the clock signal. For serial communication, the 8-bit parallel data byte
must be shifted down the serial line (in transmission). Therefore, one bit
is followed by another. Some kind of system must be used to determine how
long each bit is on the line. For example, the serial system designer may
decide each bit will be on the line for 1us and, as explained above, transmission
of the full eight bits would take 8us. |
| |
With synchronous communication, the clock signal is transmitted
on a separate line, as shown in the diagram below. |
| |
|
| |
 |
| |
|
| |
In this way, the receiver is synchronized with the transmitter.
As we shall see, the 8051 serial port in mode 0 is an example of synchronous
serial communication. |
| |
|
| |
|
| |
Asynchronous Serial Communication |
| |
A good example of asynchronous serial communication is the
interface between a keyboard and a computer. In this case, the keyboard
is the transmitter and the computer is the receiver. With asynchronous communication,
a clock signal is not sent with the data. There are a number of reasons
why this form of communication might be desirable over synchronous communication.
One advantage is the fact that the physical line for the clock is not needed.
Also, asynchronous communication is better over long distances. If we try
to synchronize a remote receiver by sending the clock signal, due to propagation
delays and interference, the validity of the clock is lost. |
| |
Another reason for not transmitting the clock arises when
the data rate is erratic. For example, data rate from a keyboard to a computer
is dependent upon the typist. The user may type at a rate of sixty words
per minute, but at other times he/she may type a lot less. And for long
periods there may be no data sent at all. Because of this erratic data rate
an asynchronous communication system is suitable. |
| |
|
| |
Serial Communication Protocol |
| |
In any communication system, the receiver must know what
kind of data to expect and at what rate the data will arrive. In both synchronous
and asynchronous serial communication, the receiver needs to know with which
bit the transmitter begins. In most systems the LSB is the first bit transmitted.
|
| |
For an asynchronous system, the number of bits transmitted
per second must be known by the receiver. Since the clock signal is not
transmitted, the receiver needs to know what clock frequency the transmitter
is using so that it can use the same. |
| |
The receiver also needs to know how many bits per word the
transmitter is using (in most cases we deal with 8-bit words, but we will
see cases where nine bits are transmitted per word). |
| |
And the receiver needs to know where the data begins and
where the data stops. |
| |
All these parameters make up the protocol. If the receiver
uses the same protocol as the transmitter is should receive the data correctly
(although errors can occur and we will look at how we catch these errors
at a later date). If the receiver uses a protocol other than the one used
by the transmitter, then the two devices are effectively speaking two different
languages and the data received will be garbage. |
| |
|
| |
Start Bits and Stop Bits |
| |
In asynchronous communication, at least two extra bits are
transmitted with the data word; a start bit and a stop bit. Therefore, if
the transmitter is using an 8-bit system, the actual number of bits transmitted
per word is ten. |
| |
In most protocols the start bit is a logic 0 while the stop
bit is logic 1. |
| |
Therefore, when no data is being sent the data line is continuously
HIGH. |
| |
The receiver waits for a 1 to 0 transition. In other words,
it awaits a transition from the stop bit (no data) to the start bit (logic
0). Once this transition occurs the receiver knows a data byte will follow.
|
| |
Since it knows the data rate (because it is defined in the
protocol) it uses the same clock as frequency as that used by the transmitter
and reads the correct number of bits and stores them in a register. For
example, if the protocol determines the word size as eight bits, once the
receiver sees a start bit it reads the next eight bits and places them in
a buffer. |
| |
Once the data word has been read the receiver checks to see
if the next bit is a stop bit, signifying the end of the data. If the next
bit is not a logic 1 then something went wrong with the transmission and
the receiver dumps the data. |
| |
If the stop bit was received the receiver waits for the next
data word, ie; it waits for a 1 to 0 transition. |
| |
|
| |
|
| |
The 8051 Serial Port |
| |
The 8051 includes an on-chip serial port that can be programmed
to operate in one of four different modes and at a range of frequencies.
In serial communication the data is rate is known as the baud rate, which
simply means the number of bits transmitted per second. In the serial port
modes that allow variable baud rates, this baud rate is set by timer 1. |
| |
|
| |

(The
8051 Microcontroller, 3rd Edition - I. Scott MacKenzie) |
| |
|
| |
|
| |
The 8051 serial port is full duplex. In other words, it can
transmit and receive data at the same time. The block diagram above shows
how this is achieved. If you look at the memory
map you will notice at location 99H the serial buffer special function
register (SBUF). Unlike any other register in the 8051, SBUF is in fact
two distinct registers - the write-only register and the read-only register.
Transmitted data is sent out from the write-only register while received
data is stored in the read-only register. There are two separate data lines,
one for transmission (TXD) and one for reception (RXD). Therefore, the serial
port can be transmitting data down the TXD line while it is at the same
time receiving data on the RXD line. |
| |
The TXD line is pin 11 of the microcontroller (P3.1) while
the RXD line is on pin 10 (P3.0). Therefore, external access to the serial
port is achieved by connecting to these pins. For example, if you wanted
to connect a keyboard to the serial port you would connect the transmit
line of the keyboard to pin 10 of the 8051. If you wanted to connect a display
to the serial port you would connect the receive line of the display to
pin 11 of the 8051. This is detailed in the diagram below. |
| |
|
| |
 |
| |
|
| |
Transmitting and Receiving Data |
| |
Essentially, the job of the serial port is to change parallel
data into serial data for transmission and to change received serial data
into parallel data for use within the microcontroller. |
| |
- Serial transmission is changing parallel data to serial data.
- Serial reception is changing serial data into parallel data.
- Both are achieved through the use of shift registers.
|
| |
As discussed earlier, synchronous communication requires
the clock signal to be sent along with the data while asynchronous communication
requires the use of stop bits and start bits. However, the programmer wishing
to use the 8051 need not worry about such things. To transmit data along
the serial line you simply write to the serial buffer and to access data
received on the serial port you simply read data from the serial buffer. |
| |
For example: |
| |
- MOV SBUF, #45H - this sends the byte 45H down the serial line
- MOV A, SBUF - this takes whatever data was received by the serial
port and puts it in the accumulator.
|
| |
|
| |
How do we know when the complete data byte has been sent? |
| |
As mentioned earlier, it takes a certain length of time for
a data byte to be transmitted down the serial line (determined by the baud
rate). If we send data to SBUF and then immediately send more data to SBUF,
as shown below, the initial character will be overwritten before it was
completely shifted down the line. |
| |
- MOV SBUF, #23H
- MOV SBUF, #56H
|
| |
Therefore, we must wait for the entire byte to be sent before
we send another. The serial port control register (SCON) contains a bit
which alerts us to the fact that a byte has been transmitted; ie; the transmit
interrupt flag (TI) is set by hardware once an entire byte has been transmitted
down the line. Since SCON is bit-addressable we can test this bit and wait
until it is set, as shown below: |
| |
|
| |
MOV SBUF, #23H; send
the first byte down the serial line
JNB TI, $; wait for the entire byte to be sent
CLR TI; the transmit interrupt flag is set by hardware but must
be cleared by software
MOV SBUF, #56H; send the second byte down the serial line
|
|
| |
|
| |
|
| |
How do we know when data has been received? |
| |
Similarly, we need to know when an entire byte has been received
by the serial port. Another bit in SCON, the receive interrupt flag (RI)
is set by hardware when an entire byte is received by the serial port. The
code below shows how you would program the controller to wait for data to
be received and to then move that data into the accumulator. |
| |
|
| |
JNB RI, $;
wait for an entire byte to be received
CLR RI; the receive interrupt flag is set by hardware but must be
cleared by software
MOV A, SBUF; move the data stored in the read-only buffer to the
accumulator
|
|
| |
|
| |
|
| |
Why is there an extra register on the receive side? |
| |
If you look at the block diagram of the serial port above
you will notice the RXD line is applied to a shift register and the contents
of this register are moved, in parallel, into the read-only buffer. The
reason for this is to ensure received data is not lost. |
| |
Once an entire byte is received (ie; shifted along RXD into
the shift register) the RI bit is set and the data byte is moved into the
read-only buffer. |
| |
If another data byte is being received, it will be shifted
into the shift register. |
| |
However, if the controller moves the data from the read-only
buffer (for example, MOV A, SBUF) before the next byte has been entirely
received, then no data is lost. |
| |
|
| |
|
| |
SCON |
| |
| Bit |
Symbol |
Address |
Description |
| 7 |
SM0 |
9FH |
serial port mode bit 0 |
| 6 |
SM1 |
9EH |
serial port mode bit 1 |
| 5 |
SM2 |
9DH |
serial port mode bit 2 - will be dealt with at a later date |
| 4 |
REN |
9CH |
receiver enable - this bit must be set to receive data |
| 3 |
TB8 |
9BH |
transmit bit 8 - this is the ninth bit transmitted in the 9-bit
UART modes |
| 2 |
RB8 |
9AH |
receive bit 8 - this is the ninth bit received in the 9-bit UART
modes |
| 1 |
TI |
99H |
transmit interrupt flag - this bit is set by hardware when an
entire byte has been transmitted - it must be cleared by software |
| 0 |
RI |
98H |
receive interrupt flag - this bit is set by hardware when an entire
byte has been received - it must be cleared by software |
|
| |
The serial control register is bit-addressable and each bit
is described in the table above. |
| |
We have already looked at bits 1 and 0 (TI and RI respectively).
Bits 5, 3 and 2 we will deal with at a later stage. |
| |
Bit 4, as indicated, must be set if data is to be received.
Therefore, the above code for reading a byte from the serial port into the
accumulator would first have to include a line for setting REN, as shown
below. |
| |
|
| |
SETB REN; set
bit 4 of SCON so that data can be received
JNB RI, $; wait for an entire byte to be received
CLR RI; the receive interrupt flag is set by hardware but must be
cleared by software
MOV A, SBUF; move the data stored in the read-only buffer to the
accumulator
|
|
| |
|
| |
Bits 7 and 6 are used for putting the serial port into one
of the four modes, as detailed in the table below. |
| |
|
| |
| SM0 |
SM1 |
Mode |
Description |
Baud Rate |
| 0 |
0 |
0 |
shift register |
fixed - system clock frequency divided by 12 (machine cycle frequency) |
| 0 |
1 |
1 |
8-bit UART |
variable - set by timer 1 |
| 1 |
0 |
2 |
9-bit UART |
fixed - system clock frequency divided by 12 or divided by 64 |
| 1 |
1 |
3 |
9-bit variable baud rate UART |
variable - set by timer 1 |
|
| |
As can be seen, modes 2 and 3 are 9-bit - in these modes
TB8 (SCON.3) is the ninth bit transmitted while the ninth bit received is
stored in RB8 (SCON.2). We will deal with these modes at a later stage. |
| |
In modes 0 and 2 the baud rate is determined by the system
clock frequency, therefore it is fixed. In modes 1 and 3 the baud rate can
be set by using timer 1 (again, we will deal with this at a later date). |
| |
|
| |
Mode 0 |
| |
As detailed in the table above, mode 0 is simply a shift
register. To put the serial port into mode 0 you clear both SM0 and SM1.
The diagram below illustrates the serial port in mode 0. |
| |
|
| |
 |
| |
|
| |
As can be seen in the diagram above, the terms TXD and RXD
are misleading in mode 0. TXD serves as the clock while RXD is used for
both receiving and transmitting data. In mode 0, the serial port is only
half duplex; it cannot transmit and receive data at the same time because
the same line (RXD) is being used for both transmit and receive. |
| |
The serial port in mode 0 is an example of synchronous communication;
the clock signal is sent with the data on the TXD line. TXD pulses at the
same frequency as the machine cycle. In other words, TXD runs at 1/12th
the frequency of the system clock. If we are using a 12MHz system clock,
then the frequency of TXD is 1MHz, which implies its cycle length is 1us.
Therefore, each bit is active on the RXD line for 1us. To shift the entire
8-bit word along RXD takes 8us. |
| |
|
| |
|
| |
Mode 1 |
| |
As can be seen from the table above, the serial port in mode
1 operates as an 8-bit UART (Universal Asynchronous Receive/Transmit). This
is asynchronous communication, therefore no clock signal is sent with the
data. Instead, a single start bit (always logic 0) and a single stop bit
(always logic 1) encapsulate the data (8 bits). Therefore, in total, ten
bits are sent per byte of data. |
| |
Data is transmitted on TXD. Transmission is initiated by
a write to the serial buffer (eg; MOV SBUF, R0). Once the stop bit is transmitted
TI is set, alerting the processor to the fact that the entire byte has been
transmitted. When no data is being transmitted the TXD line is constantly
held HIGH (ie; a constant stream of stop bits). |
| |
Received data arrives on RXD. When the stop bit is received
the RI flag is set, alerting the processor to the fact that an byte has
been received. |
| |
If no data is being received RXD will be a constant HIGH
(because the transmitter, working off the same protocol, will hold its TXD
line HIGH when not transmitting data). Therefore, the receiver waits for
a 1 to 0 transition. This signals the arrival of a start bit, which indicates
a data byte is following. The start bit is skipped and the eight data bits
are fed into the serial port shift register. When all eight bits have been
shifted into the register the following occur: |
| |
- The stop bit is copied to RB8 in SCON.
- The data in the shift register is moved (in parallel) into SBUF (read-only).
- RI is set.
|
| |
Why is the stop bit copied into RB8? |
| |
Once RI is set the program moves on to reading the received
data from SBUF. However, the programmer may first wish to test the stop
bit to ensure it is a logic 1. If the stop bit is not a logic 1 then something
went wrong in the transmission of the data and the program can be written
to ignore the erroneous data. Therefore, since the stop bit is stored in
RB8, the programmer can write code to test this bit after RI is set. |
| |
|
| |
False Start Bit Detection |
| |
Interference (noise) on the transmission line can cause a
stream of stop bits (ie; no data) to momentarily drop to logic 0. To the
receiver, this spike may look like a start bit (ie; a 1 to 0 transition).
To combat this, on a 1 to 0 transition the receiver waits for one half bit
length and then tests the RXD line again. If RXD is still at logic 0 then
this qualifies as a genuine start bit and the receiver shifts the eight
data bits into the shift register. If the RXD line has gone back to logic
1 (because the transition was a spike caused by noise) the receiver ignores
the transition and begins waiting for the next transition. The diagram below
illustrates this. |
| |
|
| |
 |
| |
|
| |
The above diagram shows an entire data frame - start bit,
eight data bits and a stop bit. Notice the start bit is always 0 and the
stop bit is always 1. The data bits D0 to D7 can be either 1 or 0. Also
notice the point at which the receiver tests the state of RXD to see if
it is still at 0 and a valid start bit has been received. The diagram below
shows an invalid 1 to 0 transition that could be caused by noise. |
| |
|
| |
 |
| |
|
| |
|
| |
Setting the Baud Rate in Mode 1 |
| |
The serial port in mode 1 can be operated over a range of
baud rates (ie; bits/sec). There are a number of standard baud rates that
many device serial ports operate at. These are listed in the table at the
end of the document. |
| |
If the designer of an 8051 system is required to transmit
data from the serial port to a device (eg; a monitor) he/she needs to discover
what baud rate the device's serial port operates at and configure the 8051
serial port to operate at the same baud rate. |
| |
In mode 1, the baud rate is determined by the overflow of
timer 1. However, since the timer operates at a relatively high frequency
(compared to serial port baud rates) the timer 1 overflow frequency is divided
by either 32 or 16, as shown in the diagram below. |
| |
|
| |

(The 8051 Microcontroller - I. Scott MacKenzie) |
| |
|
| |
|
| |
By default, the baud rate is equal to the timer 1 overflow
frequency divided by 32. This is because a special bit in the power control
(PCON) SFR called SMOD is cleared on system reset. If this bit is set the
baud rate is doubled because the timer 1 overflow is now divided by 16 rather
than 32, as shown in the above diagram. |
| |
|
| |
To configure the port to a specific baud rate we therefore
need to configure timer 1 to give us an overflow at an appropriate interval.
This can be achieved by setting up timer 1 as an 8-bit auto-reload interval
timer. Then, if we put the correct value into TH1 the overflow signal will
have the appropriate frequency to give us the baud rate we desire. |
| |
To find the correct value to load into TH1 we use the following formula:
|
| |
TH1 = 256 - ((system frequency / (12 * 32)) / baud)
|
| |
|
| |
For example, to achieve a baud rate of 1200 using a system
clock frequency of 12MHz and with SMOD = 0: |
| |
TH1 = 256 - ((system frequency / (12 * 32)) / baud)
TH1 = 256 - ((12MHz / (12 * 32)) / 1200)
TH1 = 256 - 26.04
TH1 = 256 - 26 (rounding down => error of 0.04)
TH1 = 230
|
| |
|
| |
The value 230 in TH1 will result in timer 1 counting continuously
from 230 to 255. TF1 will be set every time the count rolls over from 255
back to 230. Since we are using a system clock frequency of 12MHz, the timer
changes state every 1us (remember, the timer clock frequency is the system
clock frequency divided by 12 - hence the divide by 12 in the above equation).
This results in an overflow every 26us which implies a timer overflow frequency
of 1 / 26us = 38.46kHz. The baud rate is the timer overflow frequency divided
by 32 (hence the divide by 32 in the above equation) which, in this case
is 38.46kHz / 32 = 1202 bits/sec. While this is not exactly the desired
1200 bits/sec (due to the rounding down error of 0.04) it is close enough
to meet the requirements of the receiving serial port. |
| |
|
| |
The code below shows how to configure both timer 1 and the
serial port to transmit data at 1200 baud. |
| |
|
| |
CLR
SM0
SETB SM1 ;clear SM0 and set SM1 to put the serial port in mode 1
MOV TMOD, #20H ;put timer 1 in mode 2 interval timing
MOV TH1, #230 ;put the reload value in TH1 - this results in a baud
rate of 1200
SETB TR1 ;start timer 1
MOV SBUF, A ;send data in the accumulator down the serial line
.
.
.
|
|
| |
|
| |
Notice in the code above the assembler accepts, by default,
data in decimal form (MOV TH1, #230) - if you want to enter data in HEX
form you must add the letter H to the end (MOV TMOD, #20H). |
| |
Also note the fact that once the timer is started the programmer
does not need to do anything else with it. The serial port itself monitors
(through hardware) the overflow signal and every 32nd overflow (16 if SMOD
is set) a bit is transmitted. |
| |
|
| |
|
| |
Why does SMOD exist? |
| |
We briefly looked at the SMOD bit and have seen how it effectively
doubles the baud rate by causing the timer 1 overflow frequency to be divided
by 16 rather than 32. But why would such a feature be required when we could
double the baud rate by changing the value in TH1. |
| |
We can best understand the SMOD function through an example. |
| |
One of the standard baud rates is 19200. To achieve this
we calculate a value for TH1 with a system frequency of 12MHz and SMOD =
0. |
| |
TH1 = 256 - ((system frequency / (12 * 32)) / baud)
TH1 = 256 - ((12MHz / (12 * 32)) / 19200)
TH1 = 256 - 1.6
TH1 = 256 - 2 (rounding up => error of 0.4)
TH1 = 254
|
| |
|
| |
However, if we set SMOD the calculation becomes: |
| |
TH1 = 256 - ((system frequency / (12 * 16)) / baud)
TH1 = 256 - ((12MHz / (12 * 16)) / 19200)
TH1 = 256 - 3.25
TH1 = 256 - 3 (rounding down => error of 0.25)
TH1 = 253
|
| |
|
| |
In the first case the error was 0.4 while in the second case,
with SMOD set, the error was only 0.25. Therefore, when calculating the
value for TH1 to obtain a particular baud rate we need to try both cases
(SMOD = 0 and SMOD = 1) and then pick the case with the least error. |
| |
|
| |
How do we set SMOD? |
| |
SMOD is the MSB of the PCON register. However, if you look
at the memory map you will
notice that PCON, at address 87H, is not bit addressable. Therefore we cannot
simply use the SETB instruction to set SMOD. The code below shows how you
read-modify-write PCON in order to set SMOD without changing the other seven
bits in the register. |
| |
|
| |
MOV A, PCON
;copy PCON to the accumulator
SETB ACC.7 ;set the accumulator MSB
MOV PCON, A ;copy the accumulator back to PCON
|
|
| |
|
| |
|
| |
| Standard Baud Rate |
System Frequency |
SMOD |
TH1 Value |
| 19200 |
12MHz |
1 |
253 |
| 9600 |
12MHz |
0 |
253 |
| 2400 |
12MHz |
0 |
243 |
| 1200 |
12MHz |
0 |
230 |
|
| |
The above table shows some standard baud rates together with
the required TH1 value to achieve this baud rate with the 8051 serial port
in mode 1. |
| |
|
| |
|
| |
Sending Text Down the Serial Line |
| |
The assembly code below shows how to send the text abc
down the serial port line at a baud rate of 9600 with a system clock frequency
of 12 MHz. The subroutine sendText takes the start address (ie; the
location in RAM of the first character in the text) in R0. The length of
the text need not be given - the subroutine continues to send data until
0 is found. Therefore, the text stored in RAM is terminated with a 0 in
the same way that a C string is terminated with a 0. |
| |
|
| |
CLR
SM0
SETB SM1 ;clear SM0 and set SM1 to put the serial port in mode
1
MOV TMOD, #20H ;put timer 1 in mode 2 interval timing
MOV TH1, #253 ;put the reload value in TH1 - this results in a
baud rate of 9600
SETB TR1 ;start timer 1
MOV 40H, #'a'
MOV 41H, #'b'
MOV 42H, #'c' ;store the text in memory starting at address 40H
MOV 43H, #0 ;terminate the text with 0
MOV R0, #40H ;put the start address in R0
CALL sendText
|
|
| |
|
| |
The main program is show above, which calls the subrotine
as detailed below. |
| |
|
| |
|
sendText:
|
MOV A, @R0 ;move
data pointed to by R0 into A
JZ finish ;if contents of A are equal to 0 jump to finish
|
| loop: |
MOV SBUF, A
;move contents of A to the serial buffer - this initiates the transmission
down the serial line
INC R0 ;increment R0 to point to next character
JNB TI, $ ;wait for entire character (ie; the current character
that was sent to SBUF) to be sent down serial line
CLR TI ;clear the transmit overflow
JMP loop ;go back to send next character
|
| finish: |
RET
|
|
| |
|
| |
|
| |
Adding a Parity Bit to ASCII Data |
| |
If you look at the ASCII
table you will notice the codes go from 0 to 7FH. Therefore, only seven
bits are needed to code the basic ASCII characters. This leaves the 8th
bit free - we can use this spare bit as a parity bit. |
| |
The 8051 maintains even parity with the accumulator, ie;
the number of ones in the accumulator together with the parity bit (in the
program status word) is always even. |
| |
Therefore, before we send data, we can move it to the accumulator
and then copy the parity bit into the accumulator MSB. Now the data in the
accumulator has an even number of ones. An example may help to clarify this. |
| |
Let's say we wish to transmit the character Q - by
looking in the ASCII table we see the code for Q is 51H. If we move this
to the accumulator its status, together with the parity bit will be as shown
below |
| |
|
| |
The parity bit (P) is 1 because there are an uneven number
of 1s in the accumulator. If we now copy the parity bit to the accumulator
MSB it will have an even number of ones. |
| |
|
| |
Another example: transmitting the character S - ASCII
code for S is 53H. If we load this into the accumulator we get the
following: |
| |
|
| |
This time the parity bit is 0 because there are an even number
of ones in the accumulator. This time, copying the parity bit to ACC.7 does
not effect the accumulator contents, implying it still has an even number
of ones. |
| |
|
| |
In either case, moving the character to be transmitted into
the accumulator and then copying the parity bit to ACC.7 results in the
accumulator having an even number of ones. |
| |
|
| |
We can then transmit the ASCII character along with the parity
bit to the receiver. If the receiver is working from the same protocol it
will expect an ASCII character with an even parity bit in the MSB. The receiver
counts the number of ones in the received data and if there is not an even
number of ones it knows something went wrong during transmission and it
ignores the data. If there are an even number of ones in the received data
is clears the MSB and processes the received ASCII character. |
| |
The code below shows how to transmit and receive ASCII characters
with even parity. |
| |
|
| |
MOV A, 30H;
move the ASCII character stored in location 30H to the ACC
MOV C, P ;copy the parity bit to the carry bit
MOV ACC.7, C ;then move it from the carry bit to the ACC MSB
MOV SBUF, A ;transmit the character along with the parity bit down
the serial line
JNB TI, $; wait for the byte to be sent
CLR TI
.
.
.
|
|
| |
The above code moves the ASCII character stored in location
30H to the accumulator. It then copies the parity bit to the carry bit because
there are only two bit move instructions - move to the carry and move from
the carry. The carry is then moved into the accumulator MSB and the whole
byte (8 bits) is sent down the serial line. |
| |
|
| |
The receiver must be able to count the number of ones in
the received data. If an 8051 was being used to receive even parity ASCII
data on the serial line it could test the data validity as shown below: |
| |
|
| |
|
waitForByte:
|
JNB RI, $ ;wait
for a byte to be received
CLR RI
MOV A, SBUF ;move the received byte to the accumulator
JB P, waitForByte
;if the parity bit is set, data transmission error => ignore
data
CLR ACC.7 ;valid data - therefore clear the parity bit
.
.
|
|
| |
|
| |
The above code waits for a byte to be received. Once a byte
arrives it moves it into the accumulator. If the number of ones in the accumulator
is odd then the parity bit in the PSW will be set (to make the overall number
of ones even). Therefore, the program tests the status of the parity bit.
If it is 1 it means a bit in the transmitted data was altered. This has
to be the case since the transmitter included a parity bit in the MSB of
the transmitted byte to ensure the number of ones was even. If the receiver
sees an odd number of ones then something went wrong. |
| |
The above program ignores the data if it is invalid by jumping
back to wait for the next byte. |
| |
If the data received has an even number of ones then the
receiver clears the received parity bit so that it is simply left with the
seven bit ASCII character. |
| |
|
| |
|
| |
|
| |
|
| |
|
| |
Copyright
(c) 2005-2006 NyCelt LLC
|