silly interupt flag question

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

I'm doing a bunch of things with several IRQ's (turning them on/off, changing edge modes, etc)...but I've encountered some real craziness.

 

Part of what I am doing is, before setting irq parameters (such as timer overflow value), is to always write "1" to the irq flag bit, to 100% ensure that irq is not pending (ie: clear any pending of that irq), to ensure irq eventually fires as desired.

However, now with all the madness, I'm wondering when the flag IS zero, does writing a one actually SET the irq? The manual only states writing a one clears it (which is what I'm going by)...maybe I'm actually causing my irqs to fire, when I'm just trying to be safe. 

 

For clarity, such as

 

ldi temp , (0<<INTF1)|(1<<INTF0) ;ensure any IRQ glitches cleared on IRQ0
out EIFR, temp 

 

so before writing a one to clear a pending, does the bit need checked, or can it simply be written to one?  If this is not an issue, I will look at other (many) possibilities.

 

Normally I wouldn't do this clearing at all, but with so many things happening, thought it would be a benefit

This topic has a solution.

When in the dark remember-the future looks brighter than ever.

Last Edited: Wed. Nov 8, 2017 - 07:46 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Which AVR model are you talking about?

 

Jim

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

Writing to the flags won’t set them. Only the interrupt source can set the flag.

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

Writing to the flags won’t set them. Only the interrupt source can set the flag.

Your words match my original premise, so my setting of the bits is probably fine. I need to bark up another tree, but was somewhat hopeful I had found the issue! 

 

 

Which AVR model are you talking about?

mega328 

When in the dark remember-the future looks brighter than ever.

Last Edited: Tue. Nov 7, 2017 - 11:46 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

What craziness?  Show the code which elicits this craziness.

"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."

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

"Fast.  Cheap.  Good.  Pick two."

"Read a lot.  Write a lot."

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

 

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

From my understanding writing a '1' to an interrupt flag clears the flag.  The other way an interrupt flag is cleared is by the hardware when it executes the ISR that corresponds to the flag.

 

From the Mega328 datasheet Timer0 section RED is how the flag is SET, YELLOW highlighter on how to clear the flag:

 

Jim

If you want a career with a known path - become an undertaker. Dead people don't sue! - Kartman

Please Read: Code-of-Conduct

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB user

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

Hi JGM,

 

Yes no question about clearing the flag, it is very explicit.  What they fail to mention or clearly call out (and I started to dwell upon), was if the flag is NOT set in the first place, does writing a one SET it?  I don't see this circumstance mentioned anywhere. ...seems logical, that could be the case (therefore acting like a flip flop ..write 1 to set, write one to reset)....but apparently  ONLY the irq condition can set it (at least that is thee going theory).

 

 

I was thinking my constant "clearing" of the flag (whether already set or not), might have actually been causing lots of false irq's to occur.

 

When in the dark remember-the future looks brighter than ever.

Last Edited: Wed. Nov 8, 2017 - 12:55 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

avrcandies wrote:
What they fail to mention or clearly call out (and I started to dwell upon), was if the flag is NOT set in the first place, does writing a one SET it?

It certainly does explicitly say what sets it AND what clears the flag.  The yellow highlight in my post tells how it's cleared, and the red outline says how it is set.

 

Now, what you could do is write a simple program for say the timer, and run it in the simulator and see what happens.

 

JIm

If you want a career with a known path - become an undertaker. Dead people don't sue! - Kartman

Please Read: Code-of-Conduct

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB user

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

I wrote:

What craziness?  Show the code which elicits this craziness.

"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."

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

"Fast.  Cheap.  Good.  Pick two."

"Read a lot.  Write a lot."

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

 

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

 

It certainly does explicitly say what sets it

I generally agree, though they should specifically cover the mentioned condition

They specifically say: Alternatively the flag is CLEARED by writing a one to the bit ....(I take verb cleared as meaning it went from 1 to 0)

 

....This would certainly make a lot of sense perhaps:

An irq condition occurring sets the corresponding flag bit

Alternatively if the flag bit is zero & you write a one, it becomes one   ...they fail to mention what happens in this condition.

Alternatively if the flag bit is one  & you write a one, it becomes zero

 

What they should say is: Regardless of its state, the flag bit becomes zero when a one is written to it.

 

 

When in the dark remember-the future looks brighter than ever.

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

avrcandies wrote:
They specifically say: Alternatively the flag is CLEARED by writing a one to the bit ....(I take verb cleared as meaning it went from 1 to 0)

 

Exactly.

 

avrcandies wrote:
Alternatively if the flag bit is zero & you write a one, it becomes one ...they fail to mention what happens in this condition.

They have TOLD you....the flag is cleared when you write a one to it.  Incidentally I wrote that program I suggested and ran it in the Simulator.  If the Flag is a zero, and you write a one to it NOTHING happens.

 

avrcandies wrote:
What they should say is: Regardless of its state, the flag bit becomes zero when a one is written to it.

OK, OK, OK...I'll mention it at the Moderators Convention in the spring.  Happy now?

 

If I write a "1" to this thread will it be cleared? winkcheeky

 

Jim

If you want a career with a known path - become an undertaker. Dead people don't sue! - Kartman

Please Read: Code-of-Conduct

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB user

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

.I'll mention it at the Moderators Convention in the spring.

Is it in the usual place in Hawaii this year? I havnen't got my ticket yet.

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

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

I thought you were headed to Bali this year!?

David (aka frog_jr)

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

avrcandies wrote:
I don't see this circumstance mentioned anywhere. ...seems logical, that could be the case (therefore acting like a flip flop ..write 1 to set, write one to reset)

I think you are stretching things.  Surely, if assigning one to the unset bit then set the bit, there w0ould be a note about that somewhere.

 

I think it is logical that if you try the assignment of a 1 to an unset interrupt flag bit that the effect will be a hard between Vcc and Gnd, with attendant overheating and possible fire.

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

js wrote:

.I'll mention it at the Moderators Convention in the spring.

Is it in the usual place in Hawaii this year? I havnen't got my ticket yet.

 

Just so long as it's not the same place it was last year....  My ticket has not arrived yet either, and I also hope it's not for the same airline either.

 

JIm

If you want a career with a known path - become an undertaker. Dead people don't sue! - Kartman

Please Read: Code-of-Conduct

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB user

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

I thought you were headed to Bali this year!?

No thanks, too many crazy people there. Anyway I have the Hawaiian shirt ironed now.

 

 

 

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

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

 

 

vrcandies wrote:

They specifically say: Alternatively the flag is CLEARED by writing a one to the bit ....(I take verb cleared as meaning it went from 1 to 0)

Exactly.

avrcandies wrote:

Alternatively if the flag bit is zero & you write a one, it becomes one ...they fail to mention what happens in this condition

They have TOLD you....the flag is cleared when you write a one to it. 

 

Think this through...

Well, if the verb clearing a bit means going from one to zero, then saying writing a one clears the flag , means when a one is written when the flag is one, it will become zero

However, that does NOT necessarily preclude the case of when a one is written when the flag is zero, it will become one. So it is NOT being TOLD or addressed.

 

A completely independent statement is made about some event setting the flag to one, but it is not stated therein that this is the only way it is can be Set to one.  So their description seems to have a hole .  However, I concur with our normal interpretation & try not to think about this situation. 

 

 

  

 

When in the dark remember-the future looks brighter than ever.

Last Edited: Wed. Nov 8, 2017 - 02:56 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Surely, if assigning one to the unset bit then set the bit, there w0ould be a note about that somewhere

maybe or maybe not...I would think in the realm of logic that writing a one to something would (surely) & very commonly produce a one/set condition, unless told otherwise.  And there is nothing directly in the datasheet to refute it.

 

Playing devils advocate, why would I expect to need a note saying that setting a one results in a one?  I'd certainly like a note when it does not do that.

 

I'm informing Atmel that I found a hole in their description & won't tell them what it is unless I get a complete set of their latest databooks. smiley

 

When in the dark remember-the future looks brighter than ever.

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

Think this through...

Well, if the verb clearing a bit means going from one to zero

Clearing a bit means >>making<< it zero, not necessarily >>changing<< it to zero.

 

Seems you're jigging madly on the head of a pin.  The problem is surely in your code, not in a semantic re-interpretation of the datasheet.

"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."

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

"Fast.  Cheap.  Good.  Pick two."

"Read a lot.  Write a lot."

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

 

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

avrcandies wrote:
Think this through... Well, if the verb clearing a bit means going from one to zero, then saying writing a one clears the flag , means when a one is written when the flag is one, it will become zero. However, that does NOT necessarily preclude the case of when a one is written when the flag is zero, it will become one. So it is NOT being TOLD or addressed.

 

I have a better idea.....STOP thinking about it.  I even tried a small program that writes a one to the flag when it's a zero, and it stayed zero. 

 

avrcandies wrote:
A completely independent statement is made about some event setting the flag to one, but it is not stated therein that this is the only way it is can be Set to one. So their description seems to have a hole . However, I concur with our normal interpretation & try not to think about this situation.

 

Good Grief.....

 

avrcandies wrote:
I'm informing Atmel that I found a hole in their description & won't tell them what it is unless I get a complete set of their latest databooks. smiley

You will be waiting a VERY long time as Databooks went bye bye a long time ago.

 

Jim.

If you want a career with a known path - become an undertaker. Dead people don't sue! - Kartman

Please Read: Code-of-Conduct

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB user

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

 I even tried a small program that writes a one to the flag when it's a zero, and it stayed zero. 

Thanks Jim, that's what I always assumed to be true, (until I started playing the what-if I've been wrong all these years game).

 

 

When in the dark remember-the future looks brighter than ever.

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

Does this mean this thread has a solution to your question, the post with the solution can be tagged as such, and we can move on to other more pressing items?  Like Johns Shirt....cheeky

 

JIm

If you want a career with a known path - become an undertaker. Dead people don't sue! - Kartman

Please Read: Code-of-Conduct

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB user

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

Yes please mark it, as from here on out, I can't let my progress be interrupted angel

When in the dark remember-the future looks brighter than ever.

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

YOu have to mark the post with the solution  None of us can.

 

Jim

If you want a career with a known path - become an undertaker. Dead people don't sue! - Kartman

Please Read: Code-of-Conduct

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB user

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

I'm pretty sure that in the hardware world, you get to say you've cleared a bit, whether or not it was set to start with.

Consider your various flipflops and latches with "clear" input...

FlipFlop with clear and preset

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

Horse dead. Cease beating. ;-)

"He used to carry his guitar in a gunny sack, or sit beneath the tree by the railroad track. Oh the engineers would see him sitting in the shade, Strumming with the rhythm that the drivers made. People passing by, they would stop and say, "Oh, my, what that little country boy could play!" [Chuck Berry]

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

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

I generally agree with the hardware analogy.  Atmel's description left a smidge of ambiguity (If you have a register bit that can be set to one when desired (or automatically by an event), but cleared by writing another one, it would still fit their description.)

When you are grasping at possible straws, you go hmmm, is that the cause?   I finally found what the real issue was (related to the timer mode).

 

Time to close this one down!

 

When in the dark remember-the future looks brighter than ever.

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

avrcandies wrote:
I finally found what the real issue was (related to the timer mode).
Which someone here might have been able to help with if you had responded at the time to:

joeymorin wrote:

What craziness?  Show the code which elicits this craziness.

or the later:

joeymorin wrote:

I wrote:

What craziness?  Show the code which elicits this craziness.

Lots of threads here are about people "grasping at straws" - the classic being the inability to read UDR or UCSRC when a UART is not working. Because they can't see the 8N1 value in UCSRC they think that MUST BE why their UART connection is not working and then long threads focus on that particular red herring while the actual problem (as we all know: "it's the wrong clock") could have been solved if they had an open mind about what might be wrong (probably attempting 9600 on 1MHz!).

 

So, no, when something doesn't work and you come up with your first theory as to why it is then don't waste a lot of time trying to prove that it MUST be the reason, keep an open mind and consider other possibilities.

 

(and when someone asks to see the code or for an explanation of the problem it might be an idea to share those so others can take a look at EVERYTHING involved).