How to receive character to P89V51RD using serial communication?

You have to study uart methods.
This is the a simple one using polling.

/* ********************************************************** */
/*                                                            */
/*               Echo Back: test for uart @ 9600              */
/*               Polled uart implementation                   */
/*                                                            */
/* ********************************************************** */
//
// Needs proper connection of RXpin and TXpin between PC D9M and connector of embedded device.
// If PC as DTE(D9M) and embedded as DCE(D9F) then 2 - 2, 3 - 3, 5 - 5 (straight cable).
// If PC as DTE(D9M) and embedded as DTE(D9M) then 2 - 3, 3 - 2, 5 - 5 (cross over cable).
// A chip as MAX232A(or like) must be used for proper signaling on RS232 line.
// Terminal on PC like Hyperterminal must be configured for 9600, 8bit, no parity, no handshake.
// At 9600 bps it is needed about 1ms to send(or receive) a byte through uart.
//
// Uses a standard 8051 header file.
// P89V51RD2 has more options than 8051, so the proper header must be used to exploit those features.
//

#include <reg51.h>

void uart_init();                 // Initializes UART peripheral
char uart_getc();                 // Polled method to Receive a byte(8bit)
void uart_putc (char c);          // Polled method to Transmit a byte(8bit)
void uart_puts(char *s);          // Typical puts for uart Transmit a null-terminated-string

void uart_init()                  // Initializes UART peripheral
{
  TMOD = 0x20;                    // Timer1, mode 2
  TH1  = 0xFD;                    // 9600 bps 11059200 Clock, core(12cycle), uart(SMOD=0)
  TL1  = 0xFD;                    // First byte timing
  SCON = 0x52;                    // 0x52 : 0101 0010  Receive Enable, TI as 1 (set as ready)
  TR1  = 1;
}

char uart_getc()                  // Polled method to Receive a byte(8bit)
{
  while (RI == 0)                 // Wait until a byte has been received
     ;                            //
  RI = 0;                         // Acknowledge RI
  return SBUF;                    //
}

void uart_putc (char c)           // Polled method to Transmit a byte(8bit)
{
  while (TI == 0)                 // TI as 0 indicates TX busy,
    ;                             //    if busy then wait for TX completion of the previous byte
  SBUF = c;                       // Does not wait for TX of current byte to complete,
                                  //    so gives time to caller for other actions
}

void uart_puts(char *s)           // Typical puts for uart Transmit a string-null-terminated
{
  while (*s)                      // Check for null byte termination
    uart_putc(*s++);              //    and send each byte using uart
}

void main ()
{
   char c;

   uart_init();                   // Init UART to desired settings
   uart_puts("Hello, echoback testing serial communication\n\r");

   while (1) {                   // This loop echoes back whatever is typed on PC Keyboard
     c = uart_getc();            //    get next byte from PC
     uart_putc(c);               //    and send it back as echo
   }

}

void uart_puts(char *s)

is inherently dangerous - "s" does not have to be null terminated! Better to deliver the buffer length/maximum buffer length as well.

puts() isn't really a big problem - somewhere in memory there is likely to be a zero.
puts() isn't much different from printf() - also assuming that the string is zero-terminated.
Just as strlen() and a huge number of other functions.

gets() on the other hand is lethal unless it is one of the non-standard implementations that takes a buffer size.

Isn't that effectively saying that all of the standard 'C' string functions are "inherently dangerous"...?!

I meant that this usage _could_ yield undesired results - not more.

I should have chosen my words more carefully!

Isn't that effectively saying that all of the standard 'C' string functions are "inherently dangerous"...?!
well, replacing say 100 - I did not count - strcpy in a project with strncpy made 3 functions dysfunctional i.e. a buffer overflow was there with strcpy.

Erik

Sorry for late reply since I went to native for past few days.. In above mentioned program Transmit session is working but I could not able to retrieve the receive section.

Note that your processor do not contain any huge magical buffer so the above code will not loopback your message. Or do you expect that your transmitted, long, string will have all characters hanging somewhere in the cable until you switch to start receiving data?

Writing a full string before starting to receive do work if you communicate with a PC. But it do not work with a loopback cable. If the chip have FIFO for transmit and receive, then you can get away with shorter messages since the transmit call will end before all data have gone out on the cable (some of it is still in the transmit FIFO) - and the receive FIFO will be able to pick up some of the already transmitted characters before you start to receive.

Without FIFO, you must pick up received characters at the same speed that they arrive to the serial port, or you will get a data overrrun. This is a reason why there are lots of sample code available for creating an interrupt-driven solution where transmit and receive are interacting with ring buffers. So puts() will end up putting data in the outgoing ring-buffer. And as the characters are sent out on the cable, they will be received and placed in the incomming ring buffer, waiting for your code to start consuming received data.

interruptifobia seems, in 99% of the cases, to be the reason to use polled.

I can't remember when I last (if ever) used polled.

Using interrupts is not rocket science, and using poll, which may work very well in simple apps will, as your code grows, someday, show uip as one of these "unexplainable once in a day hiccups".

Erik

Sorry friend, I am having the programmer board, in that a PIC controller is used to transmit the HEX file to board so that PIC controller calls the RI of 8051. Now my problem solved by using 8051 controller separately..
Thanks for Helping.