AVR Series-0 SPI: Trouble clearing the interrupt flag

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

Hello,

 

according to the AVR Series-0 SPI documentation

 

 

the IF is cleared by hardware when executing the corresponding interrupt vector.

After much debugging I had to realize: Nothing is cleared! 

Second method "cleared by first reading the SPI.INTFLAGS..." works.

And then a third method works too (found in "Getting started with SPI"): Write 1 to this IF bit position.

 

Can anybody confirm this? SPI is configured in Master/Normal-Mode using ATMega4808.

Last Edited: Sun. Apr 21, 2019 - 12:26 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

On the newer mega and tiny series, you have to

clear interrupt flags yourself in interrupt routines.

Likely the passage you quoted was copy-pasted

and reflects the older AVR architecture.

 

--Mike

 

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

avr-mike wrote:
was copy-pasted

 

I often have that impression too.

Then some statements are wrong, other one are true,

some things are missing.

 

All mixed up, same as different methods to reset these flags in different interrupts.

 

"Cleared by hardware when executing the corresponding interrupt vector" -

this I found also at TXCIF USART Transmit Complete Interrupt Flag.

Maybe wrong too.

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

GermanFranz wrote:

All mixed up, same as different methods to reset these flags in different interrupts.

 

"Cleared by hardware when executing the corresponding interrupt vector" -

this I found also at TXCIF USART Transmit Complete Interrupt Flag.

Maybe wrong too.

 

I think this series doesn't have any automatic interrupt flag clearing at all. So, yeah, probably all the entries that say otherwise are wrong.

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

El Tangas wrote:
I think this series doesn't have any automatic interrupt flag clearing at all.

 

Why this was changed compared to the older AVRs ?

Needs more code now frown

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

GermanFranz wrote:

Why this was changed compared to the older AVRs ?

 

We can only speculate.  I would guess that

this was changed to provide more options

to you as a designer.  Since there is no way

to set an interrupt flag yourself, it's nice to

give you the option to leave it set if you

want.

 

--Mike

 

 

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

avr-mike wrote:
it's nice to give you the option to leave it set if you want

For what should that be useful?  A new interrupt will occur directly after the return from the current interrupt... frown

 

Last Edited: Sun. Apr 21, 2019 - 06:41 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

GermanFranz wrote:

For what should that be useful?

 

I don't know if it's useful.  There was a

recent discussion about the MULtiply

instructions copying the topmost bit of

the result to the Carry Flag, and whether

that was useful.  I don't know about that

one either, but it could possibly somehow

be more useful than not providing that

information.

 

Not suggesting that this is a good idea,

but if you needed your interrupt handler

to implement a state machine, you could

just keep the interrupt flag set until it

reached the final state.  As you noted, the

CPU would keep calling it over and over

(doing a single opcode from main() after

each iteration).  In the routine you would

do the work for the current state, advance

the state as needed, and the final state

would clear the flag.

 

--Mike

 

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

Yes, the number of possibilities has increased. I mean: especially the possibilities of errors.
This is generally the major drawback of the increased series-0/1 controller complexity.

Last Edited: Mon. Apr 22, 2019 - 10:14 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Opinion:

 

Microchip/AVR is caught in a bit of a bind, here, in addition to being seduced by the Arduino mind-set. Let me elaborate, a bit.

 

Bind, because of trying to fit AVRs into the Microchip product line. Microchip, of course, already had PICs. AVRs, for many applications represents a step up in power (what ever that is taken to mean). New AVRs have to fit somewhere in the company's product map. Clearly, they have chosen a sort of Super-8bit target. But, this choice comes at a cost, maybe several. At least one is that the complexity shifts these devices more into the "professional" market and out of the hobby market. As witnessed by the postings in this forum, even pros are having a hard time dealing with the whole complexity issue. We have had several long threads about port mapping and, now, several about interrupt flags. I have little doubt that there WILL be more.

 

Enter ASF & START. In these, we have a solution to this complexity. More software! Wizards and frameworks! After all, if it works for Arduino, it must be good, right? Never mind that layers of abstraction (can) cost memory. Is that why we have Mega4809? I would hope not - I want to use that "extra" memory for real program - a multitude of "drivers" for a variety of plug-in product interfaces. But, its easy to be seduced by al this new product development. Improved technology gives us less power per logic function. Moore's Law gives us more transistors per unit die area. So, lets cram in more goodies and let START give us the code to manage the configuration of all this good stuff.

 

Me, a Luddite? NO! But, I do argue that far too many changes are being made with far too little thought (and, apparently, far too few resources to implement the strategies they do have - witness the new "manuals"). Or, maybe it is just trying to do too much, too fast.

 

What ever is happening, potential users are bearing the brunt of the company's short-comings. Problem for me is: M4808/9 looks like the ideal device for my next generation product. Problem for me is: I doubt I have enough time to learn everything that would be needed to make it happen.

 

Jim

Jim Wagner Oregon Research Electronics, Consulting Div. Tangent, OR, USA http://www.orelectronics.net