• State Not Answered
  • Locked Locked
  • Replies 9 replies
  • Subscribers 22 subscribers
  • Views 3156 views
  • Users 0 members are here
Options
Related
How was your experience today?
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

RS232 communication in 8051

radhakrishnan murugesan

Dear all,
i am new to this domain. i am trying to send some data from 8051 microcontroller to the PC. i am using philips P89V51RD2 microcontroller and i am using Keil4.22 version tool to program. i read the 8051 tutorial and configured everyting related for this communication, but still i didn't get the result. Kindly give your guidance to proceed the work further..

The code is as follows,

void main (void)
{ init_SerialPort() ;

while (1) { T1 = 0 ; SBUF = 'A' ; UserDelay(200) ; }
}

void init_SerialPort()
{ SCON = 0x53 ; PCON = 0x80 ; TMOD = 0x2F ; TH1 = 0xFD ;
}

Thanks and Regards
Radhakrishnan M

Parents
  • 0 in reply to Tamiryan Michael

    Note that some listening devices don't have hardware-controlled hanshake support - and may be too slow to manually toggle handshake lines.

    And some sending devices don't have hardware-processed handshake support - and may be too slow to stop outgoing data when a pin toggles. Very much so if the UART is configured to use FIFO for the transmission, in which case the UART may already have multiple characters queued for transmission.

    So for some slow devices, extra delays may be needed. But it is rather uncommon. Most listeners that makes use of hardware handshake toggles the handshake state while still having room for a number of characters. Designing so that the receiver can survive a full FIFO burst from a transmitter (if the device can't handle full continuos transfers at max speed) reduces lots of end-customer problems, and keeps the support costs down. Note that some USB-connected UARTs can have very large FIFOs, to try to mask the latency in the USB interface.

Reply
  • 0 in reply to Tamiryan Michael

    Note that some listening devices don't have hardware-controlled hanshake support - and may be too slow to manually toggle handshake lines.

    And some sending devices don't have hardware-processed handshake support - and may be too slow to stop outgoing data when a pin toggles. Very much so if the UART is configured to use FIFO for the transmission, in which case the UART may already have multiple characters queued for transmission.

    So for some slow devices, extra delays may be needed. But it is rather uncommon. Most listeners that makes use of hardware handshake toggles the handshake state while still having room for a number of characters. Designing so that the receiver can survive a full FIFO burst from a transmitter (if the device can't handle full continuos transfers at max speed) reduces lots of end-customer problems, and keeps the support costs down. Note that some USB-connected UARTs can have very large FIFOs, to try to mask the latency in the USB interface.

Children