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