I'm having problems with 8051 based ISRs. The problem occures when:
1- Interrupt A is being serviced. 2- Interrupt B occures and is serviced (in the middle of ISR A execution. 3- Sometimes ISR A fails to complete.
I'm using the C ISRs used in C51 without any register set defined ("using xx"). My understanding is that the ISRs should get entered and serviced mutually exclusive from one another without corrupting one another's stack. Is this not the case?
Multi-level priorities can be achieved by (carefully) crafting the ISR; basically using code like,
LCALL IsrRelease ;Release interrupt from priority logic ... Do other things with interrupt released RET IsrRelease: RETI
I have a vague recollection of seeing something like this in the Bible.
Anyway, it works - And works well. What you show is 'possible', however it is error prone. Just visualize what happens if the interrupt for which you call "IsrRelease" happens again before the RET is reached? "that will never happen" is not a valid system design parameter.
I have no recollection,vague or not of "seeing something like this in the Bible"
Erik
"What you show is 'possible', however it is error prone."
It's more that possible! I actually use it!
Sure, you must be careful with the design, but any competent 8051 programmer should be able to cope with such a requirement.
"that will never happen" is not a valid system design parameter.
I simply do not agree with that! You must program the controller via the code to ensure it will not happen. It is not impossible to write code that can protect against such things; so long as the coder has sufficient understanding.
Details of it can be found in the Bible document 80C51_FAM_ARCH_1.pdf on page 15 under the title "Simulating a Third Priority Level in Software". With understanding of this, it is possible to simulate fourth, fifth, sixth priorities if so required.
I suggest you re-visit the Bible and learn.
I simply do not agree with that! You must program the controller via the code to ensure it will not happen. Pray tell how to code to ensure so that e.g. a switch connected to EI0 does not get closed again within, say, 17ms ?
Details of it can be found in the Bible document 80C51_FAM_ARCH_1.pdf on page 15 under the title "Simulating a Third Priority Level in Software" oh, yes, now I recall, never having used it the memory faded.
"Pray tell how to code to ensure so that e.g. a switch connected to EI0 does not get closed again within, say, 17ms ?"
You've got to realise - It is not being said (or even suggested) that nested interrupts are obligatory.
You're example is just not the type of situation where they would be necessary; therefore it is not an issue.
If you cannot think of a reason to use them, or think that they have an advantage, or feel incapable of writing safe code that would benefit from their use then the answer is simple ... You should not consider risking it.
However ... Don't mark a mechanism as floored simply because you cannot do it.
you say: "(carefully) crafting" [I would drop the paranthesis] I say "error prone"
same thing just from different directions
There is, another trick that is valuable (and I have used) in some cases: I use T0 as the example of the interrupt you just happen not to use, any unused interrupt will do. Set all interrupts except T0 to high priority, take what overloads the interrupt out and put it in the T0 ISR. In the now no more overloading ISR set TF0.
The term "error prone" makes it sound so incredibly dangerous. It's not. It just requires a little careful consideration. Just like most (non-trivial) programming tasks.
With regards to your trick ... Yes, I agree it is another useful technique. I have done the very same thing on a number of occasions (on a number of different CPU cores).
The term "error prone" makes it sound so incredibly dangerous. It's not. it is for some
"it is for some"
As is walking across the road, but that doesn't mean people should never do it!