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?
2- Interrupt B occures and is serviced (in the middle of ISR A execution. This seems to be a problem, no ISR should interrupt another ISR, are you doing something such as enabling interrupts or something inside an ISR? Why do you need to interrupt your interrupt? What are you doing inside the interrupt that you would even desire to interrupt it?
Stephen
This seems to be a problem, no ISR should interrupt another ISR why not? the sole purpose of the IP register is exactly to make that possible.
are you doing something such as enabling interrupts or something inside an ISR none of that would make another interrupt interrupt the ISR, only IP can do that.
Erik
are you doing something such as enabling interrupts or something inside an ISR
none of that would make another interrupt interrupt the ISR, only IP can do that.
You're wrong.
Short and concise enough?
none of that would make another interrupt interrupt the ISR, only IP can do that. You're wrong. pray explain how you can make an interrupt interrupt an interrupt w/o involving IP
for reference:
here are the links to "the bible" Chapter 1 - 80C51 Family Architecture: www.nxp.com/.../80C51_FAM_ARCH_1.pdf
Chapter 2 - 80C51 Family Programmer’s Guide and Instruction Set: www.nxp.com/.../80C51_FAM_PROG_GUIDE_1.pdf
Chapter 3 - 80C51 Family Hardware Description: www.nxp.com/.../80C51_FAM_HARDWARE_1.pdf
Here's the question:
Here's Erik's response:
none of that would make another interrupt interrupt the ISR
Here's some code that shows the response is wrong:
void SomeIsr(void) interrupt 0 { //Code that doesn't involve IP //No interrupts of higher priority enabled ES=1; //Some more code not involving IP //interrupted by a serial interrupt ES=0; }
what is happening here? will you guys STOP confusing everybody here and argument using damn SOLID facts onces and for all?!!?!?! I don't know who to believe anymore!
1) if an ISR is running, no interrupt of the same priority will happen. 2) the only way to malke an interupt interrupt an interrupt is by giving it a higher priority 3) evidently the Cypress chips have some other mechanism, so the above may not apply to then 4) in the sample the smoked sardine gives above, the serial interrupt will never be serviced precluding a totally screed up design that disables it in an ISR (the enable has no effect) and then enabling it asynchronously in the main
2) the only way to malke an interupt interrupt an interrupt is by giving it a higher priority
Should read:
2) the only way to make an interrupt interrupt an interrupt is by giving it a higher priority or by manually manipulating the priority logic
The original 8051 only has two hardware interrupt priority levels. 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.
Multi-level priorities can be achieved by (carefully) crafting the ISR; basically using code like,
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"
"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.
in the sample the smoked sardine gives above, the serial interrupt will never be serviced
You're still wrong.
Try re-reading the question and your answer to it. Then consider what code might be elsewhere in the program - you are already very close with your 2) above.
precluding a totally screed up design
Is that Greek, by any chance?
that disables it in an ISR (the enable has no effect) and then enabling it asynchronously in the main
No, the code I posted does not require any interrupt to be enabled anywhere else other than interrupt 0 during initialisation.
Your original response was wrong and may have mislead the OP. Accept it.
No, the code I posted does not require any interrupt to be enabled anywhere else other than interrupt 0 during initialisation you exit the "some" ISR with the serial int disabled, when is it going to be 'caught'.
that is a real problem, however, it is besides the point, the original issue was to have an interrupt interrupt an interrupt without using the IP.
you exit the "some" ISR with the serial int disabled, when is it going to be 'caught'.
There is no requirement to 'catch' serial interrupts when they are disabled.
Chapter 2 - 80C51 Family Programmer’s Guide and Instruction Set: www.nxp.com/.../80C51_FAM_PROG_GUIDE_1.pdf
Observe, in particular, the behaviour of TI and RI.
that is a real problem
No, it isn't.
however, it is besides the point
Absolutely. It's one of your smokescreen attempts.
the original issue was to have an interrupt interrupt an interrupt without using the IP.
The original issue was to have an interrupt interrupt an ISR by simply enabling it in the ISR. I posted an ISR that does that; contrary to your assertion that 'only IP can do that', no manipulation of IP inside the ISR is required. It is surely obvious that the interrupt must be of a higher priority?
OH BOY, let me try to blow some smoke out of your uppermost body part.
based on your statements of no IP involvement: Observe, in particular, the behaviour of TI and RI.
In the interrupt sense, the bahavoiour of RI AND TI is totally irrelevant unless all the following conditiona are met. a) the UART interrupt is enabled b) no ISR of same or higher priority is running
since your scribbles (it would be an offence to call it code) only satisfy a) when b) is false it does not work.
It is surely obvious that the interrupt must be of a higher priority? based on the above: which, confound it, is what I have stated from the very beginning of this thread
Er, what?
based on your statements of no IP involvement:
No IP involvement in the ISR, yes. I've been trying to explain to you why your original assertion that IP would have to be modified in the ISR rather than simply enabling an interrupt was incorrect.
In the interrupt sense, the bahavoiour of RI AND TI is totally irrelevant unless all the following conditiona are met.
In the non-interrupt sense the behaviour of RI and TI is totally relevant. You stated that the program 'would not work' if the interrupt were only enabled inside the other ISR, I'm just trying to point you towards the documentation that will show you how.
There you go again. Given that the snippet I posted was two lines of code in one function you're assuming rather a lot, don't you think? Can you try to guess how one might code outwith the posted ISR to handle the situation?
That may be what you think you tried to say, but I suggest you go back and read the thread from the beginning, slowly.
View all questions in Keil forum