Errors in the ATMEGA324P Datasheet?

Log in or register to post comments
Go To Last Post
17 posts / 0 new
Author
Message
ZAPrime
ZAPrime's picture
Level: Wannabe
Joined: Fri. Apr 30, 2010
Posts: 60 View posts
Location: 6000 feet above sea level
#1
Posted by ZAPrime: Thu. Jun 30, 2011 - 08:49 PM
  • 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?

Tags:

AVR Microcontrollers, megaAVR and tinyAVR
Top
dksmall
dksmall's picture
Level: Raving Lunatic
Joined: Mon. Apr 16, 2001
Posts: 3684 View posts
Location: Phoenix, Arizona
Posted by dksmall: Thu. Jun 30, 2011 - 08:55 PM
  • 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".

Top
ZAPrime
ZAPrime's picture
Level: Wannabe
Joined: Fri. Apr 30, 2010
Posts: 60 View posts
Location: 6000 feet above sea level
Posted by ZAPrime: Thu. Jun 30, 2011 - 08:59 PM
  • 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.

Top
dksmall
dksmall's picture
Level: Raving Lunatic
Joined: Mon. Apr 16, 2001
Posts: 3684 View posts
Location: Phoenix, Arizona
Posted by dksmall: Thu. Jun 30, 2011 - 09:08 PM
  • 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.

Top
ZAPrime
ZAPrime's picture
Level: Wannabe
Joined: Fri. Apr 30, 2010
Posts: 60 View posts
Location: 6000 feet above sea level
Posted by ZAPrime: Thu. Jun 30, 2011 - 09:45 PM
  • 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.

Top
kscharf
kscharf's picture
Level: Posting Freak
Joined: Wed. Aug 4, 2004
Posts: 1839 View posts
Location: Davie, FL
Posted by kscharf: Thu. Jun 30, 2011 - 10:04 PM
  • 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).

Top
Brutte
Brutte's picture
Level: Raving Lunatic
Joined: Thu. Oct 5, 2006
Posts: 3229 View posts
Location: Poland
Posted by Brutte: Thu. Jun 30, 2011 - 10:25 PM
  • 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!

Top
Gold Markclawson
clawson's picture
Level: Moderator
Joined: Mon. Jul 18, 2005
Posts: 104792 View posts
Location: (using avr-gcc in) Finchingfield, Essex, England
Posted by clawson: Fri. Jul 1, 2011 - 07:52 AM
  • 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).

Top
ZAPrime
ZAPrime's picture
Level: Wannabe
Joined: Fri. Apr 30, 2010
Posts: 60 View posts
Location: 6000 feet above sea level
Posted by ZAPrime: Thu. Jul 21, 2011 - 08:37 PM
  • 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...

Top
larryvc
larryvc's picture
Level: Raving Lunatic
Joined: Thu. Dec 6, 2007
Posts: 4229 View posts
Location: Redmond, WA, USA
Posted by larryvc: Thu. Jul 21, 2011 - 08:52 PM
  • 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

Top
Bronze Marktheusch
theusch's picture
Level: 10k+ Postman
Joined: Mon. Feb 19, 2001
Posts: 40543 View posts
Location: Wisconsin USA
Posted by theusch: Thu. Jul 21, 2011 - 08:56 PM
  • 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.

Top
ZAPrime
ZAPrime's picture
Level: Wannabe
Joined: Fri. Apr 30, 2010
Posts: 60 View posts
Location: 6000 feet above sea level
Posted by ZAPrime: Fri. Jul 22, 2011 - 08:56 AM
  • 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.

Top
Bronze Marktheusch
theusch's picture
Level: 10k+ Postman
Joined: Mon. Feb 19, 2001
Posts: 40543 View posts
Location: Wisconsin USA
Posted by theusch: Fri. Jul 22, 2011 - 01:45 PM
  • 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.

Top
Gold Markclawson
clawson's picture
Level: Moderator
Joined: Mon. Jul 18, 2005
Posts: 104792 View posts
Location: (using avr-gcc in) Finchingfield, Essex, England
Posted by clawson: Fri. Jul 22, 2011 - 01:53 PM
  • 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.

Top
Bronze Marktheusch
theusch's picture
Level: 10k+ Postman
Joined: Mon. Feb 19, 2001
Posts: 40543 View posts
Location: Wisconsin USA
Posted by theusch: Fri. Jul 22, 2011 - 02:17 PM
  • 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.

Top
ZAPrime
ZAPrime's picture
Level: Wannabe
Joined: Fri. Apr 30, 2010
Posts: 60 View posts
Location: 6000 feet above sea level
Posted by ZAPrime: Sat. Jul 23, 2011 - 12:22 PM
  • 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
Top
ZAPrime
ZAPrime's picture
Level: Wannabe
Joined: Fri. Apr 30, 2010
Posts: 60 View posts
Location: 6000 feet above sea level
Posted by ZAPrime: Sat. Jul 23, 2011 - 12:47 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:

Top