Datasheet nonsense?

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

In all the datasheets I've looked at there is a nonsensical sentence added to an already tricky paragraph. It concerns the ADC interrupt pending flag. That would be ADIF in the ADCSRA register.

Here is the end of the paragraph:
Alternatively, ADIF is cleared by writing a logical one to the flag. Beware that if doing a Read-Modify-Write on ADCSRA, a pending interrupt can be disabled. This also applies if the SBI and CBI instructions are used.

The last sentence makes no sense to me. I think the SBI and CBI instructions can't be used on the ADCSRA register because it is at 0x7A. And even if they could be used, if SBI and CBI work the way I assume they do, they could be used to modify other bits in the ADCSRA register without inadvertantly clearing ADIF.

If anyone else agrees with me, I will send an e-mail to Atmel.

If you are interested, here is the entire paragraph:
• Bit 4 – ADIF: ADC Interrupt Flag
This bit is set when an ADC conversion completes and the Data Registers are updated. The ADC Conversion Complete Interrupt is executed if the ADIE bit and the I-bit in SREG are set.
ADIF is cleared by hardware when executing the corresponding interrupt handling vector. Alternatively, ADIF is cleared by writing a logical one to the flag. Beware that if doing a Read-Modify-Write on ADCSRA, a pending interrupt can be disabled. This also applies if the SBI and CBI instructions are used.

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

ADCSRA may well be in low address space on some/many models. You will probably find the same or similar notation on many of the ...IF bits. If the datasheet of a recent model, there is a buried disclaimer that "the code examples in the datasheet don't work"; it may also cover this situation.

As an experienced AVR user, I can shine by these things without problem. If I were just applying the family, like if I was to do an AT90SAM7 or even an Xmega design, I'd be tearing my hair out if the datasheet fragments did not work.

The notation/warning about clearing a pending interupt and RMW behaviour are needed >.somewhere<<.

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

Surely this just means that whenever you are writing to ADCSRA, it is wise to re-start an ADC conversion.

Similar situations occur with modifying any other system.

You would generally instigate an ADC under program control or as a regular procedure. I have covered the first in my first sentence. The second occasion just means that you might miss one conversion in a regular sequence. Unlikely to be fatal.

David.

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

Quote:

The second occasion just means that you might miss one conversion in a regular sequence. Unlikely to be fatal.

Au contraire--if you start the next conversion in the ISR of the previous one.

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

But you have knowingly written the ADCRSA, so would re-start another A/D conversion.

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

theusch wrote:
ADCSRA may well be in low address space on some/many models.
Lee

But the datasheets I am using like the atmega644 and atmega329 have the register at 0x7A, so the reference to CBI and SBI are just confusion.

Steve

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

theusch wrote:

As an experienced AVR user, I can shine by these things without problem.
Lee

Then maybe the datasheet should have another disclaimer. "This datasheet is intended for experienced AVR users that aren't troubled by nonsense. For the rest of you, get lost." :)

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

Something like that. Right.

I do tend to agree that a datasheet pass at at least the sample codes would be worthwhile.

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

Steve,

Could I suggest a solution:

Write an ADC ISR that lights an LED and starts a new A/D.

In your foreground code, start off the very first A/D.
Then regularly write to ADCSRA and turn off the LED. Keep a count of your writes.

In due course of time the ADC IRQs will cease and your LED will never shine. The data sheet hints that the ADIF is cleared, but does not say that it is always cleared. This test should show up the truth of the statement, and possibly the statistical likelihood of it happening.

David.

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

theusch wrote:

The notation/warning about clearing a pending interupt and RMW behaviour are needed >.somewhere<<.

Lee

Of course, and it is needed right there. If you read my first post you would see my problem was the last sentence:
This also applies if the SBI and CBI instructions are used.

I have assumed the CBI and SBI do not do a read-modify-write. Maybe my assumption is wrong. The description of these instructions doesn't mention it. At least not in the document I have. (doc0856.pdf 8-bit AVR instruction set)

If they do a read-modify-write, then it would seem doc0856.pdf needs fixing.

In any case, it seems to me the last sentence of the paragraph contributes nothing but confusion if the register in question doesn't allow CBI and SBI.

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

David, I appreciate your reply.

I probably didn't make myself clear. I have no problem with the paragraph except the last sentence about CBI and SBI.

Otherwise the sentence makes sense to me. The interrupt pending bit (ADIF) seems to behave like all the other interrupt pending bits. It's cleared two ways. It's cleared if the interrupt is actually taken (ISR runs), and it will be cleared if a one bit is written to it's position in the register. I don't have a problem with that.

The read-modify-write warning is also needed. Neophytes don't realize they are clearing this bit inadvertantly by flipping other bits in the register.

For example,
ADCSRA |= x;
will clear the ADIF bit regardless of the value of x.

ADCSRA &= x;
will also clear the pending flag unless x doesn't contain the ADIF bit.

The way I "or in" or "and off" bits is by using a temporary memory location. Before the contents of the temporary location is written back to the register, I "and off" the ADIF bit.

My problem was only with the last sentence about CLI and SBI.

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

Quote:
I have assumed the CBI and SBI do not do a read-modify-write.

Is it as plain as you would like it? In the instruction set document? Perhaps not. But let's look at a selection of quotes from the datasheet searching for "read-modify-write". A similar selection should be gathered with a "SBI" search.

Quote:

I/O-Ports
Introduction
All AVR ports have true Read-Modify-Write functionality when used as general digital I/O ports. This means that the direction of one port pin can be changed without unintentionally changing the direction of any other pin with the SBI and CBI instructions.
...
Do not use Read-Modify-Write instructions (SBI and CBI) to set or clear the MPCMn bit.
The MPCMn bit shares the same I/O location as the TXCn Flag and this might accidentally be cleared when using SBI or CBI instructions.
...
Due to this behavior of the receive buffer, do not use Read-Modify-Write instructions (SBI and CBI) on this location.
...
Beware that if doing a Read-Modify-Write on ADCSRA, a pending interrupt can be disabled. This also applies if the SBI and CBI instructions are used.

However, to get really confused check out this hit on SBI:
Quote:
Some of the Status Flags are cleared by writing a logical one to them. Note that, unlike most other AVRs, the CBI and SBI instructions will only operate on the specified bit, and can therefore be used on registers containing such Status Flags.

Now you tell me what "most other AVRs" do. ;)

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:
Au contraire--if you start the next conversion in the ISR of the previous one.

But in that case the interrupt flag is cleared automatically as soon as the ISR is called, so there is no chance for you to clear it accidentally.

Quote:
I have assumed the CBI and SBI do not do a read-modify-write. Maybe my assumption is wrong.

Yes, this assumption is wrong. In fact, these may be the only instructions that are read-modify-write. It is mentioned more than once in most datasheets. I agree that the instruction set summary should mention this.

Regards,
Steve A.

The Board helps those that help themselves.

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

Quote:

Quote:
Au contraire--if you start the next conversion in the ISR of the previous one.

But in that case the interrupt flag is cleared automatically as soon as the ISR is called, so there is no chance for you to clear it accidentally.


Ok, ok--you guys are right in that in my apps I'm typically (when interrupt-driven and continuous conversions) only going to touch ADCSRA at init and in the ISR. But we did have a problem app with heavy noise--one of the symptoms when finally tracked down was that the ADC ISR never fired (apparently one of the noise symptoms knocked the ADc for a loop or cleared ADIF or some other anomaly) and the result was that the "continuous" conversions stopped and the app continued using stale data from the last completed reads. That was the case I was thinking of.

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

Koshchi wrote:
Quote:
I have assumed the CBI and SBI do not do a read-modify-write. Maybe my assumption is wrong.

Yes, this assumption is wrong.

I appreciate this info. I had assumed that was precisely why these instructions existed.

I do think the instruction set document needs changing.

From what you say, the SBI works like ORI except the ORI operand is a register.

The ORI instruction description shows this:
Rd <- Rd v K

But the SBI shows this:
I/O(A,b) <- 1

Where A is the i/o register address and b is the bit number.

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

steve17 wrote:
theusch wrote:

As an experienced AVR user, I can shine by these things without problem.
Lee

Then maybe the datasheet should have another disclaimer. "This datasheet is intended for experienced AVR users that aren't troubled by nonsense. For the rest of you, get lost." :)


Oh. Joy. :roll: We tell every newbie that even sniffs at this site to "Read The F**&^$! Datasheet" and you're going to put something in there to scare the poor idiots off?

Oh well. S**** 'em if they can't take a joke! :D

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

theusch wrote:
Some of the Status Flags are cleared by writing a logical one to them. Note that, unlike most other AVRs, the CBI and SBI instructions will only operate on the specified bit, and can therefore be used on registers containing such Status Flags.

Now you tell me what "most other AVRs" do. ;)

Lee


No Lee, you are the experienced AVR user that the datasheet was written for. You tell me. :)

I see the quote you gave appears in the datasheet for the mega644 and the mega329, among others.

The same datasheets also contain this:
3. Some of the status flags are cleared by writing a logical one to them. Note that the CBI and SBI instructions will operate on all bits in the I/O register, writing a one back into any flag read as set, thus clearing the flag.

I surrender. Life was a lot simpler when I was programming an HC11. :) By the way, that microcontroller does have instructions that will set or clear a single bit without affecting any other bits. I assumed SBI and CBI were the AVR equivalents.

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

Quote:

No Lee, you are the experienced AVR user that the datasheet was written for. You tell me.

See above: "As an experienced AVR user, I can shine by these things without problem. " :lol:

Quote:

We tell every newbie that even sniffs at this site to "Read The F**&^$! Datasheet" and you're going to put something in there to scare the poor idiots off?

That is quite a dilemma, isn't it? When something new is added to a family (hmmm--maybe enhanced power-saving features in Mega88 family versus Mega8) then those sections always seem to be pretty good and all the info is there. Most of the "problems" arise with the cut-and-paste from the base datasheet it is derived from, and we find references to SBI where it does not apply; the disclaimers on the code fragments for unreachable registers, and the like. [It would almost seem as though it would be easier to fix up the code fragments than to find all the places to apply the disclaimer.]

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

steve17 wrote:
I surrender. Life was a lot simpler when I was programming an HC11. :) By the way, that microcontroller does have instructions that will set or clear a single bit without affecting any other bits. I assumed SBI and CBI were the AVR equivalents.

SBI and CBI are the AVR equivalents.

However, my guess is that the actual implementation of SBI and CBI may have changed over the years.

In many of the older AVR units, I guess that the SBI and CBI instructions were implemented at a low level as three distinct operations spread over 2 uninterruptible clock cycles:

1) Read the whole content of the I/O register via the full 8-bit data bus, into a temporary buffer.
2) Set or clear a single bit.
3) Write the whole result back out into the target register via the 8-bit data bus.

I guess this might be considered dangerous because of the possibility of some logical glitches:

1) Start decoding an SBI or CBI instruction.
2) An interrupt flag is set; since we're already in the instruction decode stage of the pipeline, it's too late to jump to an interrupt right now.
3) The instruction decode is complete, and the register is read, including the newly set interrupt flag.
4) The result is written back - since there's a '1' in the interrupt flag bit being written out, the interrupt flag is cleared.
5) Because the interrupt flag is cleared at the next instruction fetch stage of the pipeline, the interrupt will never have been triggered.

In some of the newer AVR implementations, it seems that the SBI and CBI op-codes have been modified so that they bypass operating on the full 8-bit data bus, and really do only affect a single bit within their target register.

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

If you would like to get the datasheets changed so they are clarified, please send an email to avr AT atmel DOT com, explaining the problem.

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

Hi all

I have the same problem with the register UCSRnA.
I want to clear the bit MPCMn in assembler.
My code :

lds	r16,   UCSR0A	
cbr	r16,   MPCM0	
sts	UCSR0A,r16

Can I do that ?

Thank you

Last Edited: Mon. Oct 20, 2008 - 01:50 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

According to my copy of the opcodes manual:

Quote:
Performs the logical AND between the contents of register Rd and the complement of the constant mask k

I'd therefore suggest you'd get more mileage out of:

cbr r16, (1<<MPCM0)

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

Thank you Clawson

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

Quote:
you'd get more mileage out of:

Code:
cbr r16, (1<<MPCM0)

...and even MORE Kms if you use a macro :-)

	CLRB	UCSR0A,MPCM0,macro_reg	;Clear Wake on address bit
.
.
.
	SETB	UCSR0A,MPCM0,macro_reg	;Set Wake on address bit

see AVR001 for macros.

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

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

loricaire:

Consider the flag bits that exist in UCSR0A. You have TXC0, UDER0, and RXC0.

The RXC0 flag is never directly affected by writing anything to it; it can only be cleared by emptying the USART's receiver FIFO or shutting off the USART's receiver entirely. So even if you do accidentally write a 1 to that bit, it will never have any side-effects.

The UDRE0 flag is also never directly affected by writing anything to it; it can only be cleared by filling up the USART's transmitter FIFO or by shutting off the USART's transmitter entirely. So even if you do accidentally write a 1 to that bit, it will never have any side-effects.

The TXC0 flag is a different story - there do exist possible situations in which that bit might have been set prior to performing the Read portion of the Read-Modify-Write operation you describe. In those situations, following the completion of the operation, the TXC0 flag will have been cleared.

You would need to take account of this in your software. Exactly what provisions (if any) might be required really depend on the ways in which you make use of the USART in your software.

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

Quote:

UDRE0 ... or by shutting off the USART's transmitter entirely.

Is it? It has a value of 1 after reset. Not that it is of much (or any?) use if the transmitter isn't enabled.

This just came up in a current Xmega thread. The datasheet wording is similar for both the Xmega and mega88.

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

Thank you John.
I taked the AVR001.zip. Now I use the macro.

Thank you lfmorrison for explained me the problem of a read-modify-write.