 |
 |
| View previous topic :: View next topic |
| Author |
Message |
newby
Joined: 26 Sep 2004
Posts: 32
|
| interrupts <=> function calls |
 Posted: Tue Dec 28, 2004 10:25 am |
 |
|
Hello everybody !
i found in the manual that interrupts (maybe) have to wait till a function, which is active at the time the interrupt occurs, has finished. It is also stated, that "functions" could also be multiplications and so on.
The reason for this behaviour is beacuse of stack overflow which could happen...
Does anybody know which functions (e.g. which "multiplications") blockades interrupts ? Is there a possibilty to turn that behaviour off (without doing the ISR completely on my one) ? |
|
 |
Ttelmah
Guest
|
|
| Posted: Tue Dec 28, 2004 10:59 am |
|
|
You have slightly misunderstood what is said.
Generally, an interrupt can interrupt almost any function, _except_ a few that specifically disable interrupts (some for controlling the program memory for example). However routines will be protected from being interrupted, if they are potentially re-entrant.
So (for instance), if you code:
| Code: |
float aval;
#int_timer2
void timer_int(void){
float val;
delay_ms(10);
val=sin(val);
aval=val;
}
|
and in 'main' (or any other non-interrupt routine), use either the delay_ms routine, or the 'sin' routine), then the interrupts will be disabled for the entire duration of each routine.
The 'key' is that the interrupt _must not_ be able to occur inside any routine that is called inside the interrupt. However 'simple' code like:
| Code: |
int aval;
#int_timer2
void timer_int(void){
aval=aval+1;
}
|
causes no problem, because addition is performed as a simple 'inline' function, rather than calling a subroutine.
Similarly, you can call any amount of arithmetic in the main code, without the interrupts being disabled, _provided_ you do not call the same routines at any point in the interrupt code.
This ties very closely with the general advice, to keep interrupt code as short and simple as possible, and avoid using delays inside these routines.
Best Wishes |
|
|
newby
Joined: 26 Sep 2004
Posts: 32
|
|
| Posted: Thu Dec 30, 2004 2:19 pm |
|
|
thank´s for your explanation !
But what if i use the #inline statement before the function definition - than the stack problem should be solved. The problem that variables could be overwritten would exist anyhow, but in my case i would not mind. |
|
|
Ttelmah
Guest
|
|
| Posted: Fri Dec 31, 2004 4:13 am |
|
|
| newby wrote: | thank´s for your explanation !
But what if i use the #inline statement before the function definition - than the stack problem should be solved. The problem that variables could be overwritten would exist anyhow, but in my case i would not mind. |
This would depend on what the function did. You can't change the typing of existing 'system' functions in this regard. As you have correctly realised, the local variables for the function would still force the protection to be enabled, if it is used in both locations.
An example of a route 'round', is given below. Here I needed to move a block of memory inside an interrupt routine, but also needed to move a block outside the routine. The solution, was to use the supplied 'memcpy' function in the main code, and then use my own version inside:
| Code: |
//Replacement for the memcpy routine, for use inside the interrupt
#inline
void mymemcpy(char *dest,char *source, int num)
{
#ASM
MOVFF dest,FSR0L
MOVFF &dest+1,FSR0H
MOVFF SOURCE,FSR1L
MOVFF &source+1,FSR1H
LOOP1:
MOVFF POSTINC1,POSTINC0
DECFSZ num
GOTO LOOP1
#ENDASM
}
|
This way the two routines are completely 'independant', and interrupts do not have to be disabled (the global handler saves the registers involved in such a movement). Since the variables are 'local' to the interrupt version only, there is no problem with these either.
The same sort of solution can be used for almost any case.
Best Wishes |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|
FAQ 
Search
Register
Profile 
Log in to check your private messages 
Log in
