so when you use a "Call" , to call a function or something like that , the address is maintained in the "Stack" and then it's called back . where is the address stored ? after the interrupt is called ? "Reti" will take you right back to it , but where is it stored ? . because i wan't to store that address in memory and at the end of the interrupt return to an other point in the program .
+when working with code , after you call a Sub-program or a function , the Return address is stored in the stack , now what if i use the stack within the Sub-routine ? what happens
In both cases (call and interrupt) the address is stored on the stack; the operation is referred to 'push onto the stack'. The stack is just part of the RAM memory; in the IDE it's the part that is called 'dynamic memory".
A RET or RETI simply moves the address back (pop from stack) into the program counter so the program continues where it was.
In case you don't know: the stack is last-in first-out and literally like a stack of plates. You keep on placing the one on top of the other. You can only take them of from the top.
amine2:
because i wan't to store that address in memory and at the end of the interrupt return to an other point in the program.
Of all to really bad ideas I've seen proposed here, that is probably the worst ever....
There is NO valid reason to do that, and doing that will be fraught with peril. If you don't even understand how the stack works, there is approximately zero chance you would ever get that to work, and if you somehow did, it would be very fragile and create all kinds of impossible to debug problems. Whatever it is you're really trying to accomplish, there are several right ways to do it, and many, many wrong ways. What you are asking for is probably the most wrong of all the wrong ways.
because i wan't to store that address in memory and at the end of the interrupt return to an other point in the program .
So, you are home cooking dinner. The phone rings. You answer the phone, tell the telemarketer to f**k off, and then return to watching TV. Makes (no) sense to me.
PaulS:
So, you are home cooking dinner. The phone rings. You answer the phone, tell the telemarketer to f**k off, and then return to watching TV. Makes (no) sense to me.
+100
But going back to the kitchen, turning the cooker off and then watching TV would make some sense (that is, if watching TV ever made sense )
PaulS:
So, you are home cooking dinner. The phone rings. You answer the phone, tell the telemarketer to f**k off, and then return to watching TV. Makes (no) sense to me.
The most common place you see this done is in hardware trap handlers. Some processors will interrupt when you divide by zero, access an invalid address, etc. In that interrupt the best thing to do is walk the stack to get the address where the interrupt occurred, make that info known in some way (write to comm interface, store in nvm, etc), and then return to someplace else in the code that would reset your application.
Another place you see it, as mentioned by someone else above, is in preemptive real-time operating systems. The RTOS needs some way to stop any task in the middle and start a different one if it's higher priority. A common way to do that is to have a periodic interrupt where the RTOS can record where it interrupted the currently executing task, and replace the return address if another task is now the higher priority.
From the posters initial question it sounds like they might be getting into code that is higher than their current level, but isn't the Arduino all about learning new things?
BigBobby:
The most common place you see this done is in hardware trap handlers. Some processors will interrupt when you divide by zero, access an invalid address, etc. In that interrupt the best thing to do is walk the stack to get the address where the interrupt occurred, make that info known in some way (write to comm interface, store in nvm, etc), and then return to someplace else in the code that would reset your application.
Another place you see it, as mentioned by someone else above, is in preemptive real-time operating systems. The RTOS needs some way to stop any task in the middle and start a different one if it's higher priority. A common way to do that is to have a periodic interrupt where the RTOS can record where it interrupted the currently executing task, and replace the return address if another task is now the higher priority.
From the posters initial question it sounds like they might be getting into code that is higher than their current level, but isn't the Arduino all about learning new things?
There is a whole WORLD of difference between properly, safely, and robustly handling task-switching in a multi-threading/multi-tasking environment, and simply re-directing the program counter in the middle of an interrupt handler. What the OP is suggesting is pretty much guaranteed to lead to nothing but failure, and is almost certainly the worst possible approach to solving whatever problem he is trying to solve. How, exactly, would the OPs interrupt handler have the slightest idea WHAT code was running when the interrupt occurred, and what was on the stack frame at that point in time, or what the register states were? In a typical task switcher, that information is either known, or is not needed, but here it would be absolutely essential, yet also, fundamentally un-knowable.
RayLivingston:
How, exactly, would the OPs interrupt handler have the slightest idea WHAT code was running when the interrupt occurred, and what was on the stack frame at that point in time, or what the register states were? In a typical task switcher, that information is either known, or is not needed, but here it would be absolutely essential, yet also, fundamentally un-knowable.
He knows for certain which code was running when the interrupt occurred because that information is located on the stack. The OP says he wants to store the interrupted address in memory so he's planning to use that information, although he doesn't say how, before returning to his other function.
If he is planning to return to the interrupted address someone should probably tell him that he needs the rest of the context off of the stack too, but this is all definitely possible.
BigBobby:
He knows for certain which code was running when the interrupt occurred because that information is located on the stack. The OP says he wants to store the interrupted address in memory so he's planning to use that information, although he doesn't say how, before returning to his other function.
I think it is a fair bet that if he has to ask here how to get the address he does not know how to do this stuff and it will just crash.
If you know how to do it then please feel free to write the tutorial for the OP. And then answer all his questions when he gets into trouble.
AWOL:
As long as the original address is remembered, it's just the start of a simple OS
I did this once, back in 80-something. Wrote some C running on an MS-DOS box that implemented a simple multitasking kernel. I just had it bounce some bricks around the screen - it would go for several seconds before crashing!
OP: to accomplish this you need to write a bit of assembler. Allocate space for stack for each thread, and then have your interrupt routine change the stack address and execute a RETI. The interrupt routine needs to track the stack frames it is using. They have to be initialised in such a way that when the client function returns, it returns to a function whose job it is to let the interrupt routine know that the thread is dead (by setting some variuables) and then force another interrupt rather than returning.
It's do-able. But it will make your code very difficult to debug and may do strange things when your timer interrupt occurs while you are doing things in a library or with hardware. The usual "doing several things at once" pattern is way easier than writing threadsafe code.
