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?
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.
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
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
Erik
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.