A qustion about interrupt priorities' ....

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

Hello guys...

In AVR we can change the place of interrupt vectors,
is it possible -with this ability of place changing- to change the priorities of interrupts ????? :?: :?:

thanks in advance

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

Only in Xmega but not in traditional AVR8's - the interrupts are just processed in the "next flagged entry in vector table" order and you can't change that.

But this must be asked about once a week - there are TONS of prior threads and discussion about this that you search should find.

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

No. The interrupt vectors are fixed. The order determines the priorities, but you cannot change this.

Just write ISRs that are short and sweet, and all your IRQs will get serviced plenty fast enough.

Do you have a special problem ?

David.

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

thanks ..

My problem is with my friend , he uses PIC and I use AVR ,
and at this moment I lost 50 pounds for him because he won , and PIC can change the priorities of interrupts ... :cry: :cry:

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

which PIC ?

As far as I can remember, the 16Fxxx and 18Fxxx parts have a single vector. You just choose which order to service them.

I am sure that the bigger parts may be more sophisticated. So if I was you I would do some reading before you pay your friend.

David.

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

you'r right , they go to the place 0004 .

as he spoke - but I didn't understand it well - he uses a register to read the flags register , and within the ISR he can stop the current ISR (put the address of instruction in the stack) and serve another ISR depending on the state of his register , and this is not possible in AVR because there is no interruption for interrupt (no nested interrupts), and he spoke about 14 levels of stack in the PIC uc , which means that he can do recursion for 14 calls , is that possible in AVR , or how much the depth of the stack in AVR , and is it related to SRAM size ... ?????

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

You can do the same with an AVR, just do not run your interrupt servicing in your actual ISR. I know this sounds confusing, but its fairly simple. Here is some pseudo-code:

Dim Int0_Flag As Bit
Dim Int1_Flag As Bit

Config Int0 = Rising
Config Int1 = Low Level
On Int0 Isr_Int0
On Int1 Isr_Int1
Enable Int0
Enable Int1

Enable Interrupts

    Do
        If Int1_Flag = 1 Then
            DoSomethingFirst
            Reset Int1_Flag
            Enable Int1
        End If
        If Int0_Flag = 1 Then
            DoSomethingSecond
            Reset Int0_Flag
            Enable Int0
        End If
    Loop

End

Isr_Int0:
    Disable Int0
    Set Int0_Flag
    Return

Isr_Int1:
    Disable Int1
    Set Int1_Flag
    Return

So here the actual interrupt is serviced, disabled, a flag set, but the actual ISR executes in the main loop, in the order you decide. So for example here Int0 has higher physical priority, but Int1 gets serviced first if both interrupts are triggered upon entering mainloop.

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

ia17348 wrote:
My problem is...
The underlying problem is that you wagered a significant amount about a subject without adequate knowledge about that subject.

Last Edited: Fri. Jul 4, 2008 - 04:29 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Just claim your 50 pounds. You can buy me a beer one day.

By the sound of it, your friend is using a 16Fxxx part.
The fact that he is choosing his priority in software is considerably slower than vectoring to the correct ISR in the first place.

If his IRQs appear in the wrong order, his toy stack is destroyed. The AVR can use all its SRAM as stack.

Edit.
to Kevin: Nesting IRQs in software is not the same as altering IRQ priority. I would not bet 50 pounds either, without being sure of the answer.

David.

Last Edited: Fri. Jul 4, 2008 - 04:30 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

ia17348 wrote:
...this is not possible in AVR because there is no interruption for interrupt (no nested interrupts), and he spoke about 14 levels of stack in the PIC uc , which means that he can do recursion for 14 calls , is that possible in AVR , or how much the depth of the stack in AVR , and is it related to SRAM size ... ?????
Nested interrupts are possible with AVRs. The 14 calls of the PIC referred to a specialized area of RAM in some limited-capability PICs which allows the depth of 14 function calls. Yes, on AVR's the call-return stack is stored in general SRAM. You can divide your available SRAM by the number of bytes stored on the stack in a CALL function to see your maximum CALL depth possible (without overflowing the stack).

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

Besides, losing 50 pounds isn't that bad, it would be actually pretty good for me... ;)

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

you deserve a box of beer ...

but till now , is it possible to do nested interrupts ...
if i use that pseudo code , i think it will work ,
but it is not a nesting mode , it's just serving another interrupts without nesting , in other words it's a trick , but no nesting ....
another thing , I remember something in at89c2051 , there was a limited size for the ISR of each interrupt , and the solution was using a /jump/ to another palce , is there the same limitation in AVR so we should change the place of interrupt vector ..???

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

Quote:

but it is not a nesting mode , it's just serving another interrupts without nesting , in other words it's a trick , but no nesting ....

OK, I'll bite: What is the difference?

I suppose you could say that if only a higher priority can interrupt a lower priority that is true nesting?

Now, danni and others like their interrupt priorities as in x51. I've never seen the need to do an SEI within an ISR in many dozens of production AVR apps. Perhaps that is because I know about the situation for the outset and design accordingly.

anyway, if you have your heart set on it, get yourself set up to use an Xmega and you can make your interrupt scheme as complicated as you care to untangle.

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

Also see 'angelu's recent post at the end of this recent thread about this identical subject:

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

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

I really would not bother. Write your ISR carefully, and you will not need to interrupt it.

I presume that you have a real case, and this is not just an academic exercise.

The standard procedure is to re-enable IRQs at the beginning of a low priority ISR. An important IRQ occurs, is serviced and you go back to complete your low priority ISR. You risk a stockpile of half-completed ISRs with their working registers all on the stack.

Most ISRs can complete inside about 5us. You will waste more time with your software nesting.

There is generally a neater solution using the AVR timer/counter hardware that avoids the very frequent IRQs.

Those processors that have a reserved space for the ISR: good idea. it makes you less likely to bloat your ISR with the consequent extra JMP.

David.

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

Quote:
OK, I'll bite: What is the difference?

OK,Lee , the problem of priorities solved , but kmr said :

Quote:
Nested interrupts are possible with AVRs

....

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

for clawson , sorry for making a repeated discussion , but there were no time to search because all that discussion happened in a minute ,and I wanted to defence about AVR against PICs....

as for my question

Quote:
another thing , I remember something in at89c2051 , there was a limited size for the ISR of each interrupt , and the solution was using a /jump/ to another palce , is there the same limitation in AVR so we should change the place of interrupt vector ..???

you mean that's right???

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

You could answer all these questions yourself by just reading the data sheet.

AVR -> vector table that must contain a JMP to ISR
mcs51 -> sparse vector table that contains simple ISR or a JMP to further code.

As for your question. Why do you not read the replies that all said the table is fixed.

David.

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

Quote:
Nested interrupts are possible with AVRs

And he was correct just as much as your friend is correct that nested interrupts are possible on PIC.

Regards,
Steve A.

The Board helps those that help themselves.

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

Koshchi wrote:
Quote:
Nested interrupts are possible with AVRs

And he was correct just as much as your friend is correct that nested interrupts are possible on PIC.
I'd go further as say AVR's are "more nest-able" than PICs since an important concern with nested interrupts is blowing the stack and the stack is potentially much larger on AVRs than the category of PICs which have a 14 call deep, fixed stack size.

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

What if, within an ISR, you trigger an external interrupt via software (setting pin INT0 as output and writing a 1 or 0 to trigger the interrupt)?

Will the external interrupt be handled within the original interrupt?

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

Quote:
Will the external interrupt be handled within the original interrupt?

Not usually because ISRs generally run in the I=0 state. All that may happen is that the IF bit gets set for that interrupt so that when the RETI sets I=1 it'll then vector to the INT0 handler.

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

Right, forgot about that interrupts are disabled within the interrupt handler, but in assembler you need to do that manually, so is it technically possible?

Not that I’m tiring to do so, just as general info.

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

UNiXWHoRe:

Quote:

Enable Interrupts

Do
If Int1_Flag = 1 Then
DoSomethingFirst
Reset Int1_Flag
Enable Int1
End If
If Int0_Flag = 1 Then
DoSomethingSecond
Reset Int0_Flag
Enable Int0
End If
Loop

In this case, the cpu spend time checking the flags status.
A complex program, have many loops, where the program flow can work for a while, and then move to another loop for a time, so, you need to check these flags in many locations, not only one.
Another problem is, the ISR is serviced after a delay, and this delay is not the same each time.

I still claim, my example few weeks ago, is fast and have no risk.

David: as long as you save the registers that you will use inside an certain ISR and call back, there is no problem.

In AVR, the priorities are fixed, you can not change. Using nested interrupts, you override the current level of interrupts with another one. In this new level, the priorities are the same.
If you want to change more 'priorities' you need to implement more levels of nested interrupts.

I asked somoe time ago, if somebody know the compilers offer nested interrupts, but so far, no respoonse. It seems I should open a thread regarding this.

Gelu

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

Oh I agree this is not the fastest way to get it done, but if you are wondering about interrupt priority most likely you have lots of them, and little non-interrupt-based processing. One could take this one step further and use a timer to service the interrupts in a predictable, prioritized, and timely fashion, à la RTOS.

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

Quote:
I asked somoe time ago, if somebody know the compilers offer nested interrupts, but so far, no respoonse. It seems I should open a thread regarding this.

I would hope that this never happens.

You can always implement your own nesting. And of course look after any consequences yourself.

Both C and ASM provide you with sufficient rope.

Only girls' languages try to protect you.

David.

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

Quote:

Now, danni and others like their interrupt priorities as in x51. I've never seen the need to do an SEI within an ISR in many dozens of production AVR apps. Perhaps that is because I know about the situation for the outset and design accordingly.

I apreciate your loiality for AVR as it is, but do you think, the big uC makers who implement nested interrupts in their uC do not know how to design accordingly ?

Gelu.

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

But do you think: Maybe the AVR designers thought it would make for a simpler and less expensive design of the chip to not have them?

But do you think: Maybe the AVR designers were not experineced enough to implement them?

But do you think: Maybe the AVR designers theorized that with a fast CPU running at a modest clock rate and very modest amounts of SRAM fro stacks and context switching, that it just wasn't necessary because the necessary ISR nesting houskeeping takes more time than the typical ISR?

Again, I've never even come close to wishing I had nested ISRs, or one interrupting another. My apps run at modest clock rates, typically the smaller Megas, and not unusual to have 4 or more interrupt sources enabled.

I'm sure that you could construct an app where changing priorities or having nesting would be the "best" way. One I've heard of essentially structures the program to run in ISR nearly always; the lowest priority ISR "task" is essentially the main loop, and eveything else interrupts that.

Get yourself the Xmega and weave interrupt complexity to your heart's content. And more SRAM and clock speed to play with, at a lower price.

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

Or go with an ARM, they have offered nested and prioritized interrupts for years now...

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

Quote:
Right, forgot about that interrupts are disabled within the interrupt handler, but in assembler you need to do that manually
The hardware disables the global interrupt bit whenever an interrupt occurs. No code required for any language.

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

Quote:

But do you think: Maybe the AVR designers thought it would make for a simpler and less expensive design of the chip to not have them?

Yes, they thought it make sens to not have hardware multiplication on small chips.
This not means, if would have been implemented, the people would have not used. Or do you wana say, 'anyway, there is no need to have hardware multiplication since you can do it by software' ?

Same with RJMP vs JMP.

Quote:

But do you think: Maybe the AVR designers were not experineced enough to implement them?

No, they know for sure how to do this.
Also, they wanted to implement ADDI but there is no room. They know this missed instruction can be easy replaced by SUBI. I am sure they know, the lack of nested interrupts can be replaced by software arangements.

It is a matter to understand what we have and what we need. If we don't have, this not means, we do not need.

As a superfreak as you are, you should promote the AVR to the maximum performance that it can give.

Quote:

Or go with an ARM, they have offered nested and prioritized interrupts for years now...

No, as long as AVR offer me nested interrupts, I stay with it.

Gelu.

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

Quote:

As a superfreak as you are, you should promote the AVR to the maximum performance that it can give.

Hmmm--if indeed my thoughts had any weight, I'd promote the AVR not have any rarely-used features. As I see no utility for the feature at all in true MICROcontroller work, adding it does not make it "better" or "best" but rather loads it with baggage and fluff.

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

I agree Lee, Atmel definitely holds the record for absolute multitude of pin function multiplexing per pins in my book... This sometimes make it difficult to choose the right chip for the job, as not only must you choose the chip for the features you need, but you also need to make sure those features you need are all accessible at the same time for the package you use... Now Atmel could easily have made a product with the same functions and features in different packages whilst at the same time maximizing the pinning efficiency.. For example a Tiny861 in QFN package that actually USES the 12 extra pins of the package instead of making them NC.

Sorry for the rant. Hehe...

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

Quote:
I apreciate your loiality for AVR as it is, but do you think, the big uC makers who implement nested interrupts in their uC do not know how to design accordingly ?

Quote:
As a superfreak as you are, you should promote the AVR to the maximum performance that it can give.

I might misunderstand what you are saying, but if those are arguments for having prioritized interrupts then they could just as well be used to argue for:
- Hardware integer division (that would be much more useful for me than prioritized interrupts).
- Von Neumann architecture.
- "Predictive/parallel pipelining" (in lack of the correct term, but would make eg 3-cycle instructions 2-cycle or even 1-cycle?)
- Virtual memory.
- ATA interface.
...

As I perceive it, the Atmel folks selected carefully what to incorporate and what to leave out based on what they thought/knew the market wanted, what they could get onto a chip within certain limits (size, production technology, development time, current consumption... all eventually influencing the unit cost for the device), what would fit a lucrative niche in the market etc etc.

Just as they had a technical argument for not incorporating ADDI, I am sure they had a good set of reasons not to implement prioritized interrupts. In fact I suspect that those where: It will put a complexity burden on the AVR core that is not warranted given the applications that they anticipated the AVRs to run, and for such applications there are techniques for dealing with interrupt servicing priorities in the firmware (as has been described by others here).

If you want a supercomputer, buy a Cray :wink:(or whatever is fashionable in that sector nowadays).

Quote:

Atmel could easily have made a product with the same functions and features in different packages whilst at the same time maximizing the pinning efficiency.. For example [...]

IRC, there actualy are some AVR models that have more usable pins in some SMD packages that in the DIL package (more A/D channels?)

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

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

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

fleemy wrote:
What if, within an ISR, you trigger an external interrupt via software (setting pin INT0 as output and writing a 1 or 0 to trigger the interrupt)?

Will the external interrupt be handled within the original interrupt?

I've experimented with that before. After receiving a whole message through the TWI ISR I toggled the INTO pin to jump to the INT0 ISR and parse the message. If you re-enable interrupts it will jump immediately otherwise the current ISR finishes first.

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

The venerable HC11 had fixed interrupt priorities! That seemed to do well in the market. I've not looked at the latest offerings from Freescale to see if the HC12 etc have this same 'limitation'.

The last time I had to do 'tricks' as Angelu describes was with a HC11 design. It was pushing the hardware and I was counting cycles to make sure things worked and I had to enforce a re-ordered priority on the timer interrupts. Basically as Angelu describes:

Hi priority isr
{
if(low_priority_int_flag)
{
do_low_priority_isr();
}
}

Personally, I have no issue with the AVR interrupt structure. I rarely used interrupt priorities on 8051 which I used extensively before changing to AVR in '99. Every architecture has it's good and not so good points ( except the PIC12/14/16/18 which is simply clunky -rather than redesign it, they just pimped up an architecture that was acceptable when it was designed, not 20 years later) and these days if you're doing something that needs a specific feature set - choose a micro that does it for you and failing that, use a fpga. I've had too much experience over the years shoehorning code into a small micros, pulling tricks, counting cycles and having it bite you time and time again. Maybe I'm just getting old and lazy! Some think it's fun - I had little choice when I did it as there was little alternative - if you only had 128bytes of ram and 4k eprom that was the design constraint - no "there's a larger pin-compatible part avail if we need to expand" situation like we have today.

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

I understood Angelu's technique to actully be:

low_priority_isr(){
 disable IE bits of all other low priority ints
 SEI
 do this low priority handler
 CLI
 re-enable al the other IE's
}

The high priority int MAY occur during the handling of this low priority ISR with no danger of any other interrupt occuring between the SEI and the CLI - but the high priority ISR code doesn't necessarily execute (only if its source "fires")

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

clawson wrote:
I understood Angelu's technique to actully be:

low_priority_isr(){
 disable IE bits of all other low priority ints
 SEI
 do this low priority handler
 CLI
 re-enable al the other IE's
}

The high priority int MAY occur during the handling of this low priority ISR with no danger of any other interrupt occuring between the SEI and the CLI - but the high priority ISR code doesn't necessarily execute (only if its source "fires")


...and meanwhile, I'd be in and out of the low-priority handler and have no stack effects and I might well have >>better<< system throughput because I don't have the waste of the housekeeping inside the ISR(s). Unless the housekeeping is extensive there could be a windup situation if the same handler fires again.

I just have not had any situation where I wished that I could prioritize interrupts, whether preemptive or not.

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 Lee, if your ISR is halfway through sending the Encyclopaedia Brittanica through the uart at 300 baud, you could well appreciate a priority structure.

There is no law that says you must service an ISR swiftly.

I am sure there may be an occasion when you cannot service swiftly even if you want to. Someone may come up with a real example of an AVR application that needs the priority.

David.

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

Quote:
There is no law that says you must service an ISR swiftly.

Well there kind of ARE on AVRs for the very reason that there are no priorities so the "easy solution" is to keep the ISRs lean and mean and the likelihood of a high priority int being missed (or seriously delayed) is reduced if all ISRs try to act swiftly.

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

Not according to some of the examples that get posted.

Use of wait loops and printf() spring to mind.

David.

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

You mean the examples posted by the "unenlightened"?

But, anyway, printf() and so on may well be fine in an app like:

int main(void) {
 setup_1second_timer();
 sei();
 while(1);
}

ISR(timer) {
 sprintf(buffer, "%02d:%02d:%02d@, h, m, s);
 LCD_output(buffer);
}

(the key things being that one ISR() finishes executing in the time before the next occurs and it's not blocking the service of any fast response sources)

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

Yes Clawson, your 'C' version of the technique is correct.

I think there is a consens along this thread, AVR do not have hardware nested interrupt priorities implemented.
I think there is a consens this can be done by software.

Two questions remain however:

- there is a realy need for nested interrupts?

- if yes, implement them via software in AVR or migrate to another uC ?

My opinion is, everyone have to give himself the answer, because it depend of many factors.

Gelu.

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

Quote:

But Lee, if your ISR is halfway through sending the Encyclopaedia Brittanica through the uart at 300 baud, you could well appreciate a priority structure.

You can use TxD buffer empty interrupt to take the next byte from ram and to load the tx buffer. Will take around one microsecond, and then for another around 33ms you can do what you want.

Gelu.

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

david.prentice wrote:
But Lee, if your ISR is halfway through sending the Encyclopaedia Brittanica through the uart at 300 baud, you could well appreciate a priority structure.

But it's not going to sit in the ISR for the entire transmission. You're only ever going to pop into it long enough to load up the next byte(s) to send.

david.prentice wrote:
There is no law that says you must service an ISR swiftly.

Of course there is no law, but if you want your application to remain responsive, it is just something that you have to do.

david.prentice wrote:
I am sure there may be an occasion when you cannot service swiftly even if you want to. Someone may come up with a real example of an AVR application that needs the priority.

Certainly there are applications for longer running ISR's. But in the world of AVR's I'd say those apps are few and far between.

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:
Certainly there are applications for longer running ISR's. But in the world of AVR's I'd say those apps are few and far between.

I would agree with that.

David.