Bad terminology in datasheet?

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

I think Atmel uses some misleading terminology in their datasheets. At least in the ones I have for the Atmegaxx9 chips. I don't mean to be nit picking here. I think the use of misleading terminology makes it much more difficult to understand. I could be wrong in thinking the terminology is bad. If so, please correct me. If not, I would like to suggest to Atmel that they fix it.

In trying to understand the USART baud rate generator, I keep stumbling over something Atmel calls fosc.
They define it twice.

On page 172 it is defined this way:
fosc ◦ ◦ ◦ ◦ ◦ ◦ ◦ ◦ XTAL pin frequency (System Clock)

And on page 173 it is defined this way:
fosc ◦ ◦ ◦ ◦ ◦ ◦ ◦ ◦System Oscillator clock frequency.

It is used to calculate the UBRR value this way:
UBRR = fosc/(16 * baud) -1

I suppose it's nice that fosc is defined twice. I think it would be better if it was defined the same way both times. And it would be totally awesome if it was defined correctly. :)

The problem is that fosc is not an oscillator frequency and has nothing to do with XTAL. Unless I'm mistaken, it is the System Clock frequency. In my case this is the rc oscillator frequency divided by the clock prescale. And the only XTAL I have is a watch crystal and has nothing to do with the USART. I need to use the rc oscillator frequency divided by the clock prescale in the formula where fosc appears.

I think it would be much better if Atmel replaced fosc with something like fsysclk and defined it this way:
fsysclk ◦ ◦ ◦ ◦ ◦ ◦ ◦ ◦System clock frequency.

Or do you think that would be way too simple? :)

Attachment(s): 

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

I guess if I were being pedantic, changing all of the definitions of fosc to fsysclk would make sense, however I see no distinction between a system "clock" and a system "oscillator". This is a digital system, after all, and I hardly expect the system "oscillator" to be anything other than a square wave, which would supply... a clock!

I did not have problems with this idea when I started with the AVR series.

On the other hand, I do not expect Atmel to change all of the current PDF'ed datasheets for this reason. I guess it's not a bad idea for future datasheets.

That's my opinion and I'm sticking to it... unless someone else has a better idea. :wink:

Stu

Engineering seems to boil down to: Cheap. Fast. Good. Choose two. Sometimes choose only one.

Newbie? Be sure to read the thread Newbie? Start here!

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

stu_san wrote:
I see no distinction between a system "clock" and a system "oscillator".
Stu

But my oscillator is apt to be running at 8 MHz. My System Clock is likely to be running at 2 MHz and might change while the AVR is running. Surely there is a difference.

On the Butterfly on my desk I have an oscillator running at 32768 hertz and another one running at 7.3628 MHz. Neither applies here. What is needed is the System Clock which is apt to be running at 1.8432 MHz, but could change at any moment.

So can I assume that when you and Atmel, and maybe the rest of the world, see fosc you immediately think, System Clock? And seeing it defined with the word XTAL doesn't cause doubts?

Hmmm, maybe I should get my head examined, or could it be the rest of the world that needs medical attention? :)

Maybe we could meet half way. How about changing fosc to fbanana. It would still be uninformative but at least it wouldn't mislead anyone to think it was referring to an oscillator.

To put it another way, to calculate the UBRR value I need to know the rc oscillator frequency and the clock prescale value. So in the formula in the data sheet, where fosc appears I have to mentally replace that with the rc oscillator frequency divided by the clock prescale. Unfortunately that's a bit confusing to my weak mind.

Last Edited: Wed. Jan 30, 2008 - 06:20 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The first definition is not correct. The XTAL pin frequency is not the same as the system clock. The system clock is the base frequency (whatever the source may be) divided by the system pre-scaler.

Regards,
Steve A.

The Board helps those that help themselves.

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

There ARE some AVRs that require internal clock scaling, especially to use the internal RC oscillator at very low supply voltages. Also, you might use that clock scaler to reduce power consumption.

While the '329 probably is not one of those, it IS important to keep the definitions consistent across the product line. As a result, there should be an important distinction between Fosc and Fsys.

My tuppence -

Jim Wagner

 

Until Black Lives Matter, we do not have "All Lives Matter"!

 

 

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

I think the confusion stems form the old days, before the AVR had dividers on the system clock. So at that time fosc and fsysclk were the same. And in very early days, there was no internal oscillator, so the frequency would be the frequency on the XTAL1 pin.

The 7.3728MHz actually applies, because the 1.8432MHz clock is derived from it by dividing it down by 4. The 32768Hz xtal has no relevance, as it's attached to the asynchronous timer, and I don't think would ever be confused as being related to the USART. (I don't think they use fosc there either)

I agree that the documentation should be updated to reflect the current state of things. It should actually be changed to fclkI/O to remain consistent with the clock description pages of the datasheet.

In either case, you can replace fosc with fsysclk (or more appropriately fclkI/O), which is the post-divider frequency. If you change the divider value, you will need to update UBRR as well.

This is more clear if you read the "system clock and clock options" section of the datasheet.

[edit]
seems this thread got pretty popular while I was replying ;)

Writing code is like having sex.... make one little mistake, and you're supporting it for life.

Last Edited: Wed. Jan 30, 2008 - 06:52 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Koshchi wrote:
The first definition is not correct. The XTAL pin frequency is not the same as the system clock. The system clock is the base frequency (whatever the source may be) divided by the system pre-scaler.

I ain't so happy with the second definition either. Like what the hell is the "System Oscillator clock frequency"?

I do have an oscillator that drives the system clock, that would be the rc oscillator, but that's simply confusing the issue..

The simple and best definition of fosc is like I said earlier. System clock frequency. Expunge the freakin' oscillator stuff!

And this whole confusion comes from the fact that they have a misleading symbol. What's wanted is fsysclk and what we get is fosc.

When I write software I'm a big believer is choosing the right name for the various data objects. I think it helps the readability of the code enormously. So if you think that fosc is correct, I don't wanna read your code. :)

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

Glitch, I think you are right on the button.

Legacy terminology for non-legacy hardware. Well that's understandable.

The same thing happens to my software. Over time it gets re-organized to make it more powerful, or simpler, or both. Occasionally I sit back, look at my code, and rename things. Sometimes that can make code I have a hard time understanding, a lot simpler to understand.

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

We have seen a lot of cut-and-past errors in the datasheets. It's quite obvious that when a new device is created, they grab the datasheet from a similar device (or parts form several similar devices) and paste it together to generate the new datasheet. This is both good and bad. On the good side, it keeps definitions consistent across the datasheets. On the bad side, we see the same errors propagate from one datasheet to the next.

Unfortunately fixing it in one, does not automatically fix it in all the others. This is one place where I think Atmel needs to do some work and task an engineer to review, and correct all the current datasheets to bring them up to date, and fix any found errors/inconsistencies.

Writing code is like having sex.... make one little mistake, and you're supporting it for life.

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

Quote:
This is one place where I think Atmel needs to do some work and task an engineer to review, and correct all the current datasheets to bring them up to date, and fix any found errors/inconsistencies.

I'm gonna dig out my typerwriter and do it!! (yeah-I wish someone would)

Hoyt

When in the dark remember-the future looks brighter than ever.   I look forward to being able to predict the future!

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

So I think I will send an e-mail to atmel unless you guys think it's a bad idea.

I see this same fosc in the datasheets for the mega644 and mega1281.

Steve

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

Steve,

When you email avr@atmel.com you might also point them towards:

https://www.avrfreaks.net/index.p...

in case there's any of the other oustanding errors that haven't already been captured.

(oh and they might want to check all the IN's and OUT's in example code as a lot of the newer devices have registers that are no longer in range of these yet the (cut/paste) code still has them)

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

Yes, e-mailing the errors to ATMEL is a good thing.

However, do not expect an instant or even response with every data sheet. Some data sheets get corrected and some never do. This March 10th will the 3 year anniversary of a data sheet example program bug that still has not been corrected in all the data sheets :shock:. I can't believe 3 years, but its almost here.

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

*sigh* Well, my nose has been well and truly shoved into "it". I promise, Papa, I will never do it again. :wink:

I now understand the problem you were having, Steve. Atmel does so many things right that it seems only proper that they should get this right, too. I am, perhaps, a little heartened that Atmel should mess up with datasheets (or, more properly, documentation). After all, engineers hate to do documentation, so Atmel must be an engineering-centered company. Yeah, weak inference I know. :?

That's not an excuse, just an observation. I hope Atmel changes for the better w.r.t. datasheets.

Stu

Engineering seems to boil down to: Cheap. Fast. Good. Choose two. Sometimes choose only one.

Newbie? Be sure to read the thread Newbie? Start here!

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

perhaps we need to create 'wikisheets' ;)

Writing code is like having sex.... make one little mistake, and you're supporting it for life.

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

[OT] Re: "wikisheets"

I love that term, "wiki". You could have a wiki about wikis, called "wikiwiki" And if that took off, the administration wiki for "wikiwiki" would be "wikiwikiwiki" Fozzy Bear would be the admin, of course! :lol:

[/OT]

Stu (wakka wakka wakka!)

Engineering seems to boil down to: Cheap. Fast. Good. Choose two. Sometimes choose only one.

Newbie? Be sure to read the thread Newbie? Start here!

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

There's already a lot of sheet in most wikis :)

I'm a picture guy myself. How about graphic novels for datasheets?

Attachment(s): 

Chuck Baird

"I wish I were dumber so I could be more certain about my opinions. It looks fun." -- Scott Adams

http://www.cbaird.org

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

graphics certainly go a long way. My idea wasn't to change the datasheets, only to maintain a live set of them, and correct any inconsistencies or errors.

BTW, nice graphic, the next step would be to break sysclk to clkI/O, clkCPU etc, as per the breakdown in the datasheet clock section. This becomes important when you start talking about the various sleep modes.

Writing code is like having sex.... make one little mistake, and you're supporting it for life.