Redirecting interrupts in ASM

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

Is there a technique for altering interrupt vectors that is faster than setting flags and testing them at the vector target? Assuming a flag register with one bit set elsewhere:

ISR: sbrc,flags,0
     rjmp target_0
     sbrc,flags,1
     rjmp target_1
      .
      .
      .
     etc.

Above seems rather slow.
Thanks in advance

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

Using the T flag (set/clt) and brts/brtc, but thats only one. :cry:

ISR: brts target_0 

      . 
      . 
      . 
     etc. 

RES

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

Quote:
Is there a technique for altering interrupt vectors
Interrupts priority is fixed in the AVRs if that's what you mean.

What exactly do you want to do? Usually you don't want to mess around to much within an ISR so what you want is the reverse, set or clear a flag in an ISR and let the main program do the analysis.

And by the way don't forget to save and restore the SREG within the ISR.

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

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

Priority is not the question..., it is a matter of different responses to a series of interrupts at the same pin.

My circumstance is that a series of interrupts (at a single pin) will occur, each requiring a different response. The events are sequential, and most be dealt with by sequential(and different) actions.

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

I don't really know of any processor (Atmel or not) that will let you do what you want.

Can you dedicate the Z register for the task? Then instead of a flag you could prime the register with the address of the required function and do an IJMP within the interrupt.

Again make sure that SREG is saved\restored and that you put a RETI at the end of the ISR.

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

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

Probably depends on how many 'targets' you need to jump to. If you don't have that many, there is probably not much speed to be gained. If you have a lot, you could probably store the address of the next 'target' in sram, and use an icall or ijmp. Something like-

ISR: 
save stuff here (Z,sreg,etc.)
lds r31,sram_address_high
lds r30,sram_address_low
icall
restore stuff
reti

target_x:
do stuff
ldi r30,high address of target_y
ldi r31,low address of target_y
sts sram_address_high,r31
sts sram-address_low,r30
ret

target_y:
do stuff
ldi r30,high address of target_Z
ldi r31,low address of target_Z
sts sram_address_high,r31
sts sram-address_low,r30
ret

target_z:

If you have a few 'targets', this probably doesn't make much sense, but if you have 100 'targets', then it starts to make sense. Or something.

(the above assembly may not be correct, so its just a general idea)

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

Quote:
The events are sequential, and most be dealt with by sequential (and different) actions.

If I understand this correctly, then you're pretty much doing it like you have to do it. If all actions have to be considered (that is, any number of them need to be performed on each interrupt), then it's a different problem than if only one of them will be performed.

However, your initial code showed jumps to the tasks, which implies that once you found the one you want to do, you ignore the rest.

So, which is it: one of many, or many of many, depending on the flags?

Chuck Baird

"I wish I were dumber so I could be more certain about my opinions. It looks fun." -- Scott Adams

http://www.cbaird.org

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

So this is like a state machine? So the current state determines what subroutine is called from the interrupt?
Or can there be multiple subroutines called from based on the flags?

If you have few different states and single subroutine, why not use a jump table? on the other hand, if you have 8 flags for 8 different subroutines that need to be called or not, then you must check the flags one at a time.

Basically, in C code equivalent worl, you could use a pointer to a function, and call the function via pointer in the interrupt. Then someone else must make sure the pointer points to the right function.

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

Thanks for all suggestions and thoughts..., what a bright bunch of guys! To answer Chuck, only a couple of tasks..., and Jepael, yes.., state machine-like.

At this juncture I've decided to set appropriate flags in the body of the prog, then test and jump *after* the ISR return. This works because it is *known* that the controller is in an idle state at interrupt time.

At any rate.., my question has been answered..., there seems not to be any un-obvious way of addressing (ha! a pun..) the question.

Thanks again to all.