This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Keil 8051 interrupt ISR

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?

  • "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.

  • Error prone or not - nested interrupts are quite common and can be very valuable for some hard-to-service hardware.

    It shouldn't be ignored just because it can fail - an incompetent programmer can manage to blow up a single "hello world". The problem isn't if the tools supports failing constructs, but of the developer allows the code to fail.

    If I decided to limit myself to totally "safe" development tools, I may have to switch to Logo. But I fear that my productivity would take a hit.

    A different - and somewhat (!) inflamed - thread discusses black or white or shades in between. This is yet another example of nuances. If I don't need nested interrupts, I avoid them. But I don't forbid myself from using them if I feel that they represent a real advantage.

    The question here is if the OP is in a situation where nested interrupts represent a real advantage, or if the wish for nested interrupts is based on a misconception that may bite even harder after a change to nested interrupts. Too quickly grabbing a heavier tool tends to result in far more dangerous accidents.

  • 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.

    Erik

  • 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.

    Erik

  • A different - and somewhat (!) inflamed - thread discusses black or white or shades in between. This is yet another example of nuances. If I don't need nested interrupts, I avoid them. But I don't forbid myself from using them if I feel that they represent a real advantage.
    nothing wrong with bested interrupts (I use them), but why all that hoolabaloo about doing it without using the intended tool: IP

    Erik

  • "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.

    Erik

  • 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).

  • 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?

  • The term "error prone" makes it sound so incredibly dangerous. It's not.
    it is for some

  • 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

  • "it is for some"

    As is walking across the road, but that doesn't mean people should never do it!

  • Thanks for your comments. The problem turned out to be something very simple. Solution:

    In Event B ISR, P_EPIRQ = 0x04; which clears the IRQ has to be done after EZUSB_IRQ_CLEAR(); which is the global IRQ. Otherwise unwanted nesting occures.

    The question that no one answered was whether the IRQs generated by C51 are nestable. From above, apparently they are not since nesting causes immediate failure.

  • OH BOY, let me try to blow some smoke out of your uppermost body part.

    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.

    since your scribbles (it would be an offence to call it code) only satisfy a) when b) is false it does not work.

    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?

    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

    That may be what you think you tried to say, but I suggest you go back and read the thread from the beginning, slowly.