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
Using the T flag (set/clt) and brts/brtc, but thats only one. :cry:
ISR: brts target_0
.
.
.
etc.
Is there a technique for altering interrupt vectors
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.
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.
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.
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)
The events are sequential, and most be dealt with by sequential (and different) actions.
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?
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.
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.
