This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

How to receive character to P89V51RD using serial communication?

Hi everyone,
In my code receive session is not working.. what changes should i made to receive a character from my keyboard?

// Program to test serial communication of controller with PC using hyper terminal
#include<reg51.h>

void ini()     // Initialize Timer 1 for serial communication
{
TMOD=0x20;  //Timer1, mode 2, baud rate 9600 bps
TH1=0XFD;
SCON=0x50;
TR1=1;
}

void recieve()  //Function to receive serial data
{
unsigned char value;
while(RI==0);
value=SBUF;
P1=value;
RI=0;
}

void transmit()  // Funtion to transmit serial data
{
P2=P1-32;
SBUF=P2;
while(TI==0);
TI=0;
SBUF=P1;
while(TI==0);
TI=0;
}

void main()
{
while(1)
{
  ini();
  recieve();
  transmit();
}
}


Thank in advance

Parents
  • 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.

Reply
  • 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.

Children
  • 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