UART receive problem

Go To Last Post
9 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hello,

I have a UART receive problem. When I sent char , I saw true value(echo example). But I send some char QUICKLY , echo is wrong . As below.

 

/*********************

send: 8888888888888888

echo(receive): 88ÎÎÎ8ÎÎå8

 

If I send slowly some char, It was success.

send: 8888888888

echo(receive):8888888888

*********************/

 

/***************

//interrupt code

ISR(USART0_RX_vect){
    data[data_cnt++] = UDR0;
    uart0.receiveHandle(data); 
}

***************/

 

I used UART peripheral (it is not softSerial).

What do you think about this?

This topic has a solution.

Serkan.

Last Edited: Fri. Feb 8, 2019 - 12:41 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

How is your AVR clocked?
You’re the millionth and one person who has uart problems. Number 1 culprit is clocking. You wouldn’t happen to be using the internal oscillator would you?

Note - your code doesn’t check for array bounds.

This reply has been marked as the solution. 
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hello,

I figure out my fault. Its reason is stop bit count problem. I used 2 stop bit and receive side is 1 stop bit. And when it was quick, occured problem.

Also thanks for your reply Kartman.

Serkan.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I think you mean the other way around. The transmitter using 2 stop bits is not a problem, but if the receiver is set for 2 stop bits and the transmitter one, then i can see how the problem ocurred.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I mean transmit side = 1 stop bit , receive bit = 2 stop bit calculate. another thinking is thinking reverse. Because this is echo example.

Serkan.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Still doesn't make sense since the receiver ignores the

setting of USBS for number of stop bits:

 

USART Stop Bits Setting

 

--Mike

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

avr-mike wrote:
Still doesn't make sense since the receiver ignores the setting of USBS for number of stop bits:
Do we know the receiver is an AVR?

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"Wisdom is always wont to arrive late, and to be a little approximate on first possession."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Regardless, the symptoms are classic stop bit error, with loss of character sync caused by receiver expecting 2 and only getting 1!

 

Jim

 

Click Link: Get Free Stock: Retire early! PM for strategy

share.robinhood.com/jamesc3274

 

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

ki0bk wrote:
Regardless, the symptoms are classic stop bit error, with loss of character sync caused by receiver expecting 2 and only getting 1!
Not necessarily.  Even if both TX/RX stop bits agree, if baud rate error is near limit, single characters can make it through fine, but repeated characters with no additional idle time can result in incorrect start-bit detection.

 

We need more information.

 

OP:  What is doing the sending?  What is doing the receiving?  Do you have an oscilloscope?  Set your transmitter for 8N1, then send an endless series of 'U' characters.  You should see a square wave with a frequency exactly 1/2 the baud rate.  What do you see?

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"Wisdom is always wont to arrive late, and to be a little approximate on first possession."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

Last Edited: Fri. Feb 8, 2019 - 05:19 PM