Keil 8051 interrupt ISR

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

Erik

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

Erik

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,

    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.

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.

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

"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!

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.

Funny you should mention that trick. I wrote that one up for EDN magazine as a design idea back in about 89 time frame or so. It indeed works.
It works because the RETI clears the interrupt disable bit in the hardware and there is no other way to clear it.

The only difference between a RET and a RETI is that one clears the interrupt flag, so you call an RETI and the call puts the value on the stack and the reti returns just like any other return, but also clears the interrupt disable bit.

We used that trick on a very early, OTP 20 pin 8051 when I was working for Eagle Signal Controls in Austin.