• State Not Answered
  • Locked Locked
  • Replies 8 replies
  • Subscribers 22 subscribers
  • Views 1462 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

Problems with serial communication

Christian Konrad

I have implemented a new serial data transfer protocol in our 8051 system (80C552).

I tryed to write the received characters immediately back to the terminal with the following commands:

	ucrs232_buffer[ucrec_count] = S0BUF;
	S0BUF = ucrs232_buffer[ucrec_count];
This two command lines are performed in the ISR. I wrote 16 chars and got back 13 completly different ones.

If I send a message from the 80C51 to the terminal its correct! Also the command from the terminal is correct.

What can be the reason for this wrong reception?

Parents
  • 0

    Hi Christian,
    what is your SIO baud rate?
    There may be problem with SIO interrupt priority and corrupted terminal's STOP bits (especially for lower buad rates).

    1. Compare both SIO settings.
    2. Set serial interrupt to the highest priority as sole owner of the priority.
    3. Maybe can help insertion of "short" delay between your two S0BUF lines for example (up to 1/2 STOP bit time which depends on your serial ISR length till S0BUF "actions" - It is necessary to tune it)

    	ucrs232_buffer[ucrec_count] = S0BUF;
        /* delay here */
	S0BUF = ucrs232_buffer[ucrec_count];
    Vaclav

Reply
  • 0

    Hi Christian,
    what is your SIO baud rate?
    There may be problem with SIO interrupt priority and corrupted terminal's STOP bits (especially for lower buad rates).

    1. Compare both SIO settings.
    2. Set serial interrupt to the highest priority as sole owner of the priority.
    3. Maybe can help insertion of "short" delay between your two S0BUF lines for example (up to 1/2 STOP bit time which depends on your serial ISR length till S0BUF "actions" - It is necessary to tune it)

    	ucrs232_buffer[ucrec_count] = S0BUF;
        /* delay here */
	S0BUF = ucrs232_buffer[ucrec_count];
    Vaclav

Children
  • 0 in reply to Vaclav Korecek

    Hello Vaclav,

    thank you for your answer! The baud rate is 9600. My OSC=15MHz -->9765bps. This is not so good but it worked with the old protocol, and i did not any changes at the interface settings.

    I use the external interrupt which occurs with app. 915Hz. I set this to priority level 0 and the serial interrupt to priority level 1 --> No changes at all.

    if(RI)
{	
if (ucrec_count >= 128)
   ucrec_count=0;

//store data from S0BUF
ucrs232_buffer[ucrec_count] = S0BUF;
S0BUF = ucrs232_buffer[ucrec_count];

//if char equals <EOT>(0x04), set brs232_rec
if (ucrs232_buffer[ucrec_count]==0x04)
  brs232_rec =1;
ucrec_count++;
RI=0;			
}
return;
    Writing the chars back to S0BUF was just inserted for test. If I do not use this line, I get also a wrong message. In normal case I read the char which was transferd to my buffer and check if it is an <EOT> sign.

    Is it a problem that my receive buffer is in external memory?

  • 0 in reply to Christian Konrad

    "The baud rate is 9600. My OSC=15MHz -->9765bps. This is not so good but it worked with the old protocol"

    Just because something doesn't fail doesn't meant that it's actually working properly! ;-)

    That sounds a pretty large baudrate error!! :-0

    As recommended on the Keil baudrate calculator
    http://www.keil.com/c51/baudrate.asp
    "For the best results, you should choose baud rates that are accurate to +/-1% or better."

    I think you could just have been lucky that it ever worked!!

  • 0 in reply to Andrew Neil

    Thank you for your message and the baud rate generator. I tryed the baud rate 1200 with and error of +0,17% and I got the same result!
    Unfortunatly it was not the reason!

    Christian