IEEE 488 specifications for parallel communication state that the cabling between equipment can be no more than 20 meters total, with no more than 2 meters between any two devices; serial, however, can extend as much as 1200 meters.

Typically, serial is used to transmit ASCII data. Communication is completed using 3 transmission lines:

(1) Ground.

(2) Transmit.

(3) Receive.

Since serial is asynchronous, the port is able to transmit data on one line while receiving data on another. Other lines are available for handshaking, but are not required. The important serial characteristics are baud rate, data bits, stop bits, and parity. For two ports to communicate, these parameters must match

8051 has an integrated UART, also known as SERIAL PORT. Because of the integrated serial port we can easily send & receive data, controller takes care of the SERIAL PROTOCOL i.e. sending each bit. All we have to do is to configure the serial port operation mode & the baudrate. And once these settings are made the controller will let us know when it has finished sending the byte that we had written in SBUF (Serial Buffer) as well as when it has received a new byte  we just have to write the byte that we have to send in the SBUF or read the received byte from the SBUF.

The transmit data pin (TXD) is specified at P3.1, and the receive data pin (RXD) is at P3.0. The serial signals provided on these pins are TTL signal and must be boosted and inverted through a suitable converter(MAX 232) to comply with RS232 standard.

The SCON SFR allows us to configure the serial port. I wont go into much details about the SCON SFR but if you want to know about it please check over here. Basically there are four modes we will be using MODE 1 which is a 9 bit UART mode consisting of start bit (0), 8 data bits (LSB first), a parity bit, and a stop bit (1). We will be loading 50h into the  SCON SFR (MOV SCON,#50h).

BAUD RATE CALCULATIONS

The baudrate is determined by the crystal frequency we will be using 11.0592 MHz crystal for calculation. You must be thinking why such a odd value, why 11.0592Mhz? & why not 12MHz. The reason we use 11.0592 MHz crystal is it generates baudrate that is compatible with PC's baudrates i.e. it can generate exact baudrates of 300, 1200, 4800, 9600, 19200 bps whereas if we use other crystal values then those exact baudrate cannot be generated. This dosent mean that we cannot use other crystals for serial communication the error gennerated is very small & hence can be used if data to be send is not very large.

In mode 1 the baudrate is determined by how frequently TIMER 1 overflows. Higher the overflow rate higher the baudrate. We use the TIMER in TIMER MODE 2 i.e. 8 bit auto reload mode i.e. the timer is automatically reloaded upon overflow. To determine the value that must be placed in TH1 to generate a given baud rate, we may use the following equation:

TH1=256-{(OSC freqn/32)/Baudrate}  if PCON.7=0

which is the default condition on power ON or

TH1=256-{(OSC freqn/16)/Baudrate}  if PCON.7=1

as you know 1 OSC Freqn i.e. 1 Machine Cycle = Crystal Frequency/12

so the above equations can also be written as:

TH1=256-{(Crystal freqn/384)/Baudrate}  if PCON.7=0

     OR

TH1=256-{(Crystal freqn/192)/Baudrate}  if PCON.7=1

Below is a table for different PC compatible baudrates for 11.0592MHz crystal & PCON.7=0

BAUDRATE INITIALIZATION

• baudrate:
•  mov scon,#50h                        //Initialize serial communication
•  mov tmod,#20h                       // Timer 1 Mode 2         
•  mov th1,#0fdh                        //9600 baudrate
•  setb tcon.6                              //Start Timer 1
•  ret

 The above subroutine is for serial PORT initialization, firstly we initialze the serial port for MODE 1 i.e. 9 bit UART mode. Then we initialize TIMER1 for MODE 2 i.e. 8 bit auto reload mode. Then put the retimer value according to the required Baudrate & then start TIMER 1.

SENDING & RECEIVING DATA

Once the serial port has been properly initialized as explained above (you can directly  use the above program), the serial port is ready to send & receive data.

For sending data all you have to do is to put the byte that you want to send in the SBUF SFR. i.e.

MOV SBUF,#(byte you want to send)

suppose i want to send 'A' the

MOV SBUF,#'A'

& the controller will will begin transmitting the character serially. After transmitting the byte the microcontroller lets us know by setting the TI bit in SCON. When TI bit is set we come to know that the controller has finished transmitting the byte & we can then send the next byte.

Here is a simple subroutine 'send' which will send the data in the Accumalator & then waits till the byte has been transmitted & then clears the Transmit flag.

• send:
• MOV SBUF,A
• wait:
• JNB TI,wait
• CLR TI
• ret

Let us write a simple program which will send data serially to PC

• ORG 0000h
• call baudrate                  //Initialize the com port
• mov a,#'D'
• call send
• mov a,#'N'
• call send
• mov a,#'A'
• call send
• stop:
• ajmp stop

The above program sends the string 'DNA' serially to PC. Using HYPERTERMINAL we can see what data has been transmitted  by the microcontroller.

Reading data from the serial port is equally easy. First we need to check if the RI flag in SCON is set or not. If it's set then it means that a byte has been received serially & the read that byte from the SBUF SFR.

• wait:
• JNB RI,wait               //wait till byte received
• CLR RI
• MOV A,SBUF             //Get the received byte in the Accumulator

Thats it thats all you got to do for receiving a byte.Now let us write a program where the controller sends data to PC only when a byte is received from the PC

• ORG 0000h
• call baudrate                  //Initialize the com port
• loop:
• JNB RI,loop
• CLR RI
• mov a,#'D'
• call send
• mov a,#'N'
• call send
• mov a,#'A'
• call send
• ajmp loop

The above program waits till a byte is received serially (dosent care which byte) & then sends 'DNA' to the PC.

-Amol Shah

Users' Comments (0)

Add your comment