Side effect of RETI?

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

I mean what could be the possible undesired/unexpected side effect of calling an interrupt service routine by RCALL?

 

Thank you.

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

???  I think you will need to explain in more detail what you are concerned about.

 

The AVR's interrupt mechanism is very "traditional" -- when the event occurs, the program counter is set to the instruction at the appropriate vector.  What happens after that is up to you.

 

Now the AVR instruction set designers gave us RETI to unwind the stack and set the I bit at the same time--as would be desired 99+% of the time.  (that eliminates a perhaps undsireable side effect ;) of the I bit being set and nested interrupts happening.

 

KerimF wrote:
I mean what could be the possible undesired/unexpected side effect of calling an interrupt service routine by RCALL?

'I' bit never being set, so you sleep with the fishes forever?

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 haven't a clue what the question is here! The title says "RETI", the post says "RCALL".

 

The way AVR interrupts work is this. For each event type there is a fixed address in the code space that is jumped to when that event occurs. The AVR pushes the current code location then jumps to that vector address. At that address you usually place an RJMP or JMP to a handler code. When it ends you can execute RET or RETI. It's usual to use the latter because on entry to the vector the AVR cleared the global interrupt flag and RETI is just like RET but it also re-enables the  global interrupt flag.

 

What "side effect" are you talking about? The effects are well documented - not something "hidden".

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

So in this situation, even if the I flag is not set, when RCALL addresses an ISR, the RETI of the ISR will set the I flag on exit always. This is what I referred to as a side effect ;)

 

I guess, you know that in a complex program, setting or clearing the I flag or any of the enable interrupt flags is made on the fly and depends on the phase the program is running.

 

Sorry for not being clear on my first post.

 

Kerim

 

Last Edited: Sun. Jun 26, 2016 - 04:23 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

KerimF wrote:
So in this situation, even if the I flag is not set, when RCALL addresses an ISR, the RETI of the ISR will set the I flag on exit always. This is what I referred to as a side effect ;)

Not exactly.  It is up to >>you<< what happens during interrupt handling.  >>You<< have chosen a toolchain to use.  Tell which toolchain and version.  Tell why the normal actions for that toolchain are objectionalble to you.

 

The "side effects" can well crop up whey you >>do not<< follow the usual sequence...

 

1)  I already mentioned that if you manually set the 'I' bit before your RET then you have opened yourself up to nested interrupts.

1a)If 'I' bit never gets set then you can no longer process interrupts.

 

2)  The mechanism you seem to be promoting, RCALLing the ISR from the vector table, will leave an extra return address on the stack -- certainly an undesireable "side effect".

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

Cliff, perhaps the OP wants to call the ISR from mainline code.  I guess that in a very isolated case that could make sense.  But please describe where this is critical, why in a complete app you can't just handle the I bit after the call, why in a complete app the ISR and the mainline cannot just call an "action routine", and/or why the small chunk of ISR code cannot be simply duplicated.

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

If that's really what he wants (I still don't follow what he's asking/concerned about) then surely you put the common code in a function foo()  then just call foo() from both within the ISR and direct from main()? Though the usual penalties are to be paid for doing so. 

 

You certainly can't easily "CALL" an ISR() directly otherwise. (well you can but it's a hassle). 

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

Please note, I write all my MCU firmware in assembly.

 

In my last application, I use Timer 2 (of ATmega8) with an extra counter, say TMR2H, with TCNT2. The main role of Timer 2, besides being a clock counter (in this case 16-bit), is to signal when a delay between two external events exceeds a pre-set maximum time (which is set differently for every phase of the process) and executes the appropriate instructions.

 

At a certain point, I may need executing a set of instructions in TMR2 routine. One of the ways is using RCALL to its entry address. (How to select the part in TMR2 to be executed is another subject). Now, I should remember that, in this case, after RCALL the I flag is 'always set' whether it is supposed being set or not. I don't think there is something else to be aware of... right?

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

KerimF wrote:
t a certain point, I may need executing a set of instructions in TMR2 routine.
clawson wrote:
If that's really what he wants (I still don't follow what he's asking/concerned about) then surely you put the common code in a function foo() then just call foo() from both within the ISR and direct from main()?

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

If the I flag is set when you call the ISR there is NO difference. (RETI is just SEI and RET in one instruction).

 

But make sure that you don't run into some reentrant problems, if the ISR fire the "normal" way.

 

I used to end my init code with RETI instead of RET so save a opcode :)

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

Sorry I don't see why not, why make a foo() when you have a perfect fine ISR routine?

 

That is the same if you want to disable ISR after a ISR, then just use a RET and not RETI.

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

The reason I asked this question is to ensure there is no difference between RET and RETI other than setting the I flag after RETI.

And this is exactly what you all kindly confirm it.

 

Thank you.

 

When something (idea, definition, characteristic or protocol for a few) looks rather clear and simple to me, I has always the impression that I 'may' have missed knowing it fully ;) practically speaking in the least.

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

Do permit me for asking, but your Location: says Aleppo-Syria.  

 

Hasn't that place been recently destroyed with thousands of people dead in the streets?

 

Or am I thinking about the other Aleppo-Syria?

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

Hi Simone,

It is the same city but fortunately just about half of it was destroyed (mainly the parts, as the old city, that were invaded and occupied by multi-national Islamist mercenaries).

It is a big industrial city; the industrial capital of Syria.

And if Al-Qaeda (presented to the world as moderate rebels by the International Society) will take over the entire city, all Syria will fall soon afterwards while millions of Christian Syrians (besides many others) will have to face the gates of Hell. But please don't worry... if you get what I mean. Thank you for your care.

Last Edited: Mon. Jun 27, 2016 - 01:11 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Simonetta wrote:
Do permit me for asking, but your Location: says Aleppo-Syria. Hasn't that place been recently destroyed with thousands of people dead in the streets? Or am I thinking about the other Aleppo-Syria?

KerimF wrote:
It is the same city but fortunately just about half of it was destroyed

Question asked and answered.

 

Keep to the topic of the thread.

 

Jim - Moderator

I would rather attempt something great and fail, than attempt nothing and succeed - Fortune Cookie

 

"The critical shortage here is not stuff, but time." - Johan Ekdahl

 

"Step N is required before you can do step N+1!" - ka7ehk

 

"If you want a career with a known path - become an undertaker. Dead people don't sue!" - Kartman

"Why is there a "Highway to Hell" and only a "Stairway to Heaven"? A prediction of the expected traffic load?"  - Lee "theusch"

 

Speak sweetly. It makes your words easier to digest when at a later date you have to eat them ;-)  - Source Unknown

Please Read: Code-of-Conduct

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB, RSLogix user

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

Of course I will, Jim.

 

Kerim - Your guest cheeky