The concept of serial communication is simple, in serial communication data is sent one bit at a time. Although this is slower than parallel communication, which allows the transmission of an entire byte at once, it is simpler and can be used over longer distances. 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:
|
||||||||||
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 baud rate. 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 won’t 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 baud rate is determined by the crystal frequency we will be using 11.0592 MHz crystal for calculation. You must be thinking why such an odd value, why 11.0592 MHz crystal & why not 12MHz crystal. The reason we use 11.0592 MHz crystal is it generates baud rate that is compatible with PC's baud rates i.e. it can generate exact baud rates of 300, 1200, 4800, 9600, 19200 bps whereas if we use other crystal values then those exact baud rate cannot be generated. This doesn’t mean that we cannot use other crystals for serial communication the error generated is very small & hence can be used if data to be send is not very large. In mode 1 the baud rate is determined by how frequently TIMER 1 overflows. Higher the overflow rates higher the baud rate. 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 freq./32)/Baud rate} if PCON.7=0 Which is the default condition on power ON or TH1=256-{(OSC freq./16)/Baud rate} if PCON.7=1 As you know 1 OSC Freq. i.e. 1 Machine Cycle = Crystal Frequency/12, so the above equations can also be written as: TH1=256-{(Crystal freq./384)/Baud rate} if PCON.7=0 OR TH1=256-{(Crystal freq./192)/Baud rate} if PCON.7=1 |
||||||||||
Below is a table for different PC compatible baud rates for 11.0592MHz crystal & PCON.7=0
|
||||||||||
|
||||||||||
|
||||||||||
BAUDRATE INITIALIZATION |
||||||||||
The above subroutine is for serial PORT initialization; firstly we initialize 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 retime value according to the required Baud rate & 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' then MOV SBUF, #'A' & the controller 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 Accumulator & then waits till the byte has been transmitted & then clears the Transmit flag.
|
||||||||||
|
||||||||||
Let us write a simple program which will send data serially to PC
|
||||||||||
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 is set then it means that a byte has been received serially & then read that byte from the SBUF SFR.
|
||||||||||
|
||||||||||
That’s 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 |
||||||||||
The above program waits till a byte is received serially (doesn’t care which byte) & then sends 'DNA' to the PC. |
.