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
Start with the Hello World example that is included in the Keil installation...
void main (void) { init_SerialPort() ; while (1) { while (!TI); TI = 0; SBUF = 'A' ; } } void init_SerialPort() { SCON = 0x60 ; PCON |= 0x80 ; TMOD |= 0x20 ; TH1 = 0xF8 ; TL1 = 0xF8; TR1 = 1; TI = 1; }
hugs n kisses.
No user delay. The UART have specific means to tell when it's ready for more data. It's only when you know that the receiver is very, very slow (maybe having to spend time processing the received data but without buffer space to both keep old message and receive more) that you add own delays.
No delays are required if hardware flow control is enabled in conjunction with interrupt driven TX/polling of UART status register.
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.
And be sure to study the uVision Manual to understand what you're doing; in particular, http://www.keil.com/support/man/docs/uv4/uv4_examples.htm
So for some slow devices, extra transmission delays may be needed. But it is rather uncommon. NEVER have delays in receive
Erik
Delays on receive side would really be bad. That's a ten points out of ten recipe for producing failed communication.
If a receiver can't keep up with incomming data, and don't have any handshake support (hw handshake lines or XON/XON or similar) and the processor load just from the serial interrupts is almost killing, then the workaround is obviously to deactivate the serial port for a while. Maybe reactivate it again in 10 seconds, and see if the abuser is still there, trying to upload the illustrated edition of the Encyclopedia Galactica ;)
Dear all, Thanks for your replies. I found the problem and now it's working fine. Actually i forgot to configure the TR1 bit.
Thanks and Regards Radhakrishnan