Electro Tech is an online community (with over 170,000 members) who enjoy talking about and building electronic circuits, projects and gadgets. To participate you need to register. Registration is free. Click here to register now.
Welcome to our site! Electro Tech is an online community (with over 170,000 members) who enjoy talking about and building electronic circuits, projects and gadgets. To participate you need to register. Registration is free. Click here to register now.
For a start try telling us what device you're referring to?.
However, it just means that an interrupt can be called while it's already executing an interrupt - this type of thing though can be fraught with danger!
Reentrant code is typically not used on PICs, it is generally incompatible with the Overlay memory allocation commonly used.
Basically say you have a task which uses a variable. For some reason you think you have a need for the task to call itself- like the task adds a+b and you think it'll be nifty if you have a carry for the adder task to call itself, but this time with the carry digits as arguments to add. Maybe that'll result in a carry too and thus that instance may have to call itself again.
Well that's often unnecessarily stressful on the calling stack. We only have so much space for return addresses. But what about that variable we used? Do we want the second instance to use the same memory location for its variable? If not we have to give up fixed memory locations for these variables (part of Overlay) and have some sort of memory stack to dynamically allocate memory for these variables.
The C compilers just won't let you do this reentrant stuff. The problems are significant and people almost never need it.
The core will not jump to the ISR while it's executing the ISR. It's already doing it. The user could make code in the ISR that called the ISR but it would be complete nonsense. Thus reentrancy is a non-issue.
On PIC parts with prioritized interrupts, it's possible for an interrupt of one type to interrupt a running ISR for another type. This is NOT reentrancy, just nesting.
Reentrant code is typically not used on PICs, it is generally incompatible with the Overlay memory allocation commonly used.
Basically say you have a task which uses a variable. For some reason you think you have a need for the task to call itself- like the task adds a+b and you think it'll be nifty if you have a carry for the adder task to call itself, but this time with the carry digits as arguments to add. Maybe that'll result in a carry too and thus that instance may have to call itself again.
Well that's often unnecessarily stressful on the calling stack. We only have so much space for return addresses. But what about that variable we used? Do we want the second instance to use the same memory location for its variable? If not we have to give up fixed memory locations for these variables (part of Overlay) and have some sort of memory stack to dynamically allocate memory for these variables.
The C compilers just won't let you do this reentrant stuff. The problems are significant and people almost never need it.
The core will not jump to the ISR while it's executing the ISR. It's already doing it. The user could make code in the ISR that called the ISR but it would be complete nonsense. Thus reentrancy is a non-issue.
I think there is an issue - it's not the ISR calling itself, it's the ISR and the mainline code both calling the same routine ...
Suppose the mainline code is executing a subroutine which uses some working registers. If an interrupt happens and the ISR calls the same subroutine, then the working registers will be re-used by the ISR's call of the subroutine and will have been corrupted when the interrupted mainline code is resumed unless the ISR has taken care to preserve the working registers.
High-level languages on "big" machines usually(?) achieve re-entrancy by ensuring that working registers are allocated on the stack so that there will be no conflict between use of the same subroutine in mainline and interrupt threads.
Oznog said:
On PIC parts with prioritized interrupts, it's possible for an interrupt of one type to interrupt a running ISR for another type. This is NOT reentrancy, just nesting.
There's scope for the same problem here, if two ISRs call the same subroutine that uses working registers in a way that has not been carefully designed.
This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
By continuing to use this site, you are consenting to our use of cookies.
