Errors in the ATMEGA324P Datasheet?

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

*sigh*

Copied straight from the 324P Datasheet

void USART_Init( unsigned int baud )
{
/* Set baud rate */
UBRRHn = (unsigned char)(baud>>8);
UBRRLn = (unsigned char)baud;
/* Enable receiver and transmitter */
UCSRnB = (1<<RXENn)|(1<<TXENn);
/* Set frame format: 8data, 2stop bit */
UCSRnC = (1<<USBSn)|(3<<UCSZn0);
}

n refers to the Usart port.

The registers UBRRHn and UBRRLn do not exist, This is confirmed by looking at the register summary on page 413.

They are UBRRnH and UBRRnL.

Who do I take this up with?

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

You should be using UBRR0H UBRR0L or UBRR1H UBRR1L. Are you?

To expand on this, if you are using USART0 then replace each "n" with "0". If you are using USART1 the use "1" for "n".

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

dksmall wrote:
You should be using UBRR0H UBRR0L or UBRR1H UBRR1L. Are you?

Yeah I know and I am - the n refers to which Usart - replace with 0 or 1.

The problem is the n is in the wrong place in the registers in the example code.

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

I see, didn't even noticed when I typed it in since I'm use to that order. Well you could try contacting Atmel, but updating an example in one datasheet probably isn't much of a priority to them, given the speed in whic they've fixed other errors over the years.

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

dksmall wrote:
I see, didn't even noticed when I typed it in since I'm use to that order. Well you could try contacting Atmel, but updating an example in one datasheet probably isn't much of a priority to them, given the speed in whic they've fixed other errors over the years.

:lol:

I'll be using it the correct order from now on too. It's just irritating for the beginner.

Thanks, will try that. Thought I might be able to do it through the forum.

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

It's just a stupid typo. I bet if you look carefully though ANY of their data sheets you'll find a few typos, miss-spellings, wrong grammar, etc. Norwegian probably translates into English better than Chinese or Japanese does however. You can get some good laughs reading a spec sheet translated from Chinese to English (by a Chinese translator).

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

Somebody with a little experience does not need that example at all, while the beginner gets frustrated, wasting time.
Long story, that is how Atmel's datasheets are written. Exclusively for people who already know everything about AVRs.

Koshchi, are you there?

No RSTDISBL, no fun!

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

The fault should be reported to avr @ atmel.com and added to the sticky thread at the top of this forum (though it's not the first occasion these UART numbers are wrong).

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

kscharf wrote:
It's just a stupid typo. I bet if you look carefully though ANY of their data sheets you'll find a few typos, miss-spellings, wrong grammar, etc. Norwegian probably translates into English better than Chinese or Japanese does however. You can get some good laughs reading a spec sheet translated from Chinese to English (by a Chinese translator).

The problem as Brutte pointed out is that as a beginner, its a huge frustration when your code won't work and you don't understand why. It's taken me 2 weeks to get my USART working because somebody couldn't be bothered to proofread.

And I don't by the translation excuse.

I don't have anyone I can ask at varsity as everyone else uses Microchip, which just makes the process more frustrating than ever.

And there is another error,

This code works,

void RS232_Init(void)
{

//PRR |= (1<<PRUSART0);
/* Set baud rate */
UBRR0L = (uint8_t) (F_CPU / (16UL * USART0_BAUD)) - 1;
UBRR0H = (uint8_t) ((F_CPU / (16UL * USART0_BAUD)) - 1) >>8;


/* Enable receiver and transmitter */
UCSR0B |= (1<<RXEN0)|(1<<TXEN0);
/* Set frame format: 8data, 2stop bit */
UCSR0C = (1<<USBS0)|(1<<UCSZ00)|(1<<UCSZ01)|(0<<UMSEL00)|(0<<UMSEL01);
}

This code doesn't


void USART_Init( unsigned int baud )
{
/* Set baud rate */
UBRRHn = (unsigned char)(baud>>8);
UBRRLn = (unsigned char)baud;
/* Enable receiver and transmitter */
UCSRnB = (1<<RXENn)|(1<<TXENn);
/* Set frame format: 8data, 2stop bit */
UCSRnC = (1<<USBSn)|(3<<UCSZn0);
}

Spot the difference:

That should be 2 instead of 3. Double check page 192.

(3<<UCSZn0) is for 9 bit transmission...

Clawson, I've added it to the list and linked back here...

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

ZAPrime, you are absolutely right about the poor documentation. Atmel should at least try what they write.

Could you PM me about wher 6000 feet above sea level is? I need a change of air.

"I may make you feel but I can't make you think" - Jethro Tull - Thick As A Brick

"void transmigratus(void) {transmigratus();} // recursio infinitus" - larryvc

"It's much more practical to rely on the processing powers of the real debugger, i.e. the one between the keyboard and chair." - JW wek3

"When you arise in the morning think of what a privilege it is to be alive: to breathe, to think, to enjoy, to love." -  Marcus Aurelius

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

Quote:

Spot the difference:

That should be 2 instead of 3. Double check page 192.

(3<<UCSZn0) is for 9 bit transmission...


I assume you are talking about
Quote:

/* Set frame format: 8data, 2stop bit */
UCSRnC = (1<<USBSn)|(3<<UCSZn0);

If so, (3 << UCSZn0) is (3 << 1) is 0x06 which is indeed 8-bit characters, since the UCSZn2 bit is not set in UCSRnB.

Quote:

(3<<UCSZn0) is for 9 bit transmission...

... -- NOT. See page 193. (Now, when you are quoting page numbers you had better be specific about which datasheet you are using. I'm referring to 8272A. And that is the '324A/'324PA datasheet. The latest P sheet I have 8011N has slightly different page numbers--but close.)

I can pedant with the best of them (even if it is not a verb).

Lee

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

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

8011O–AVR–07/10 is the datasheet I am using. So it is 192 :P

And sorry, you are right, I misinterpretted how it shifts the bits. But it remains, that does not work on my end.

I get frame error on my terminal program and that's all I get. As soon as I changed it, it started working according to specifications.

And yes, my terminal program was set correctly.

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

Quote:

And sorry, you are right, I misinterpretted how it shifts the bits.

OK, so the rant about the code fragment in the datasheet is n/a, even though it was added to the datasheet errors thread.

Quote:

It's taken me 2 weeks to get my USART working because somebody couldn't be bothered to proofread.

...is also n/a.

Now, let's examine:

Quote:
Spot the difference:

In one set of code, the UBRR values are calculated when the set of the register is done.

In the other set of code, a passed parameter called "baudrate" is used to set the UBRR registers.

Now, perhaps someone could not be bothered to proofread and the parameter to the routine really is >>not<< "baud rate"? (That appears to be the case and that was what put you onto the wrong track.)

Or maybe it is, and a value such as 9600 was passed to the routine. That baud rate value CANNOT be used directly to set UBRR registers.

Lee

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

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

Quote:

even though it was added to the datasheet errors thread.

ZAPrime,

I can delete that post if you can't.

Moderator.

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

Quote:

ZAPrime,

I can delete that post if you can't.

Moderator.


Yah know, Moderator, after doing the digging in my rebuttal I pretty much see the cause for Z's rant--it is the >>datasheet<< code fragment that implies that one would pass a baud rate to that routine and not a calculated UBRR value. So I share Z's pain. Not on the line that was first suspected, but nearby. ;)

Lee

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

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

clawson wrote:
Quote:

even though it was added to the datasheet errors thread.

ZAPrime,

I can delete that post if you can't.

Moderator.

Go for it

edit: Thanks!

Last Edited: Sat. Jul 23, 2011 - 03:30 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

theusch wrote:
Quote:

And sorry, you are right, I misinterpretted how it shifts the bits.

OK, so the rant about the code fragment in the datasheet is n/a, even though it was added to the datasheet errors thread.

Quote:

It's taken me 2 weeks to get my USART working because somebody couldn't be bothered to proofread.

...is also n/a.

Now, let's examine:

Quote:
Spot the difference:

In one set of code, the UBRR values are calculated when the set of the register is done.

In the other set of code, a passed parameter called "baudrate" is used to set the UBRR registers.

Now, perhaps someone could not be bothered to proofread and the parameter to the routine really is >>not<< "baud rate"? (That appears to be the case and that was what put you onto the wrong track.)

Or maybe it is, and a value such as 9600 was passed to the routine. That baud rate value CANNOT be used directly to set UBRR registers.

Lee

That query was addressed in a previous thread when I first started setting up the Usart. https://www.avrfreaks.net/index.p...

Ag, it doesn't matter. The point is, it now works and now I know how to do it in future :D

theusch wrote:
Quote:

ZAPrime,

I can delete that post if you can't.

Moderator.


Yah know, Moderator, after doing the digging in my rebuttal I pretty much see the cause for Z's rant--it is the >>datasheet<< code fragment that implies that one would pass a baud rate to that routine and not a calculated UBRR value. So I share Z's pain. Not on the line that was first suspected, but nearby. ;)

Lee

:lol: