<?xml version="1.0" encoding="UTF-8" ?>
<?xml-stylesheet type="text/xsl" href="https://community.arm.com/utility/feedstylesheets/rss.xsl" media="screen"?><rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:slash="http://purl.org/rss/1.0/modules/slash/" xmlns:wfw="http://wellformedweb.org/CommentAPI/"><channel><title>Keil 8051 interrupt ISR</title><link>https://community.arm.com/developer/tools-software/tools/f/keil-forum/37924/keil-8051-interrupt-isr</link><description> 
I&amp;#39;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&amp;#39;m using the C ISRs used</description><dc:language>en-US</dc:language><generator>Telligent Community 10</generator><item><title>RE: Keil 8051 interrupt ISR</title><link>https://community.arm.com/thread/144429?ContentTypeID=1</link><pubDate>Thu, 21 Aug 2008 14:44:32 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:fdf09365-4197-4ec6-979d-dbe5e619d3d5</guid><dc:creator>scrungy doolittle</dc:creator><description>&lt;p&gt;&lt;p&gt;
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.&lt;br /&gt;
It works because the RETI clears the interrupt disable bit in the
hardware and there is no other way to clear it.&lt;/p&gt;

&lt;p&gt;
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.&lt;/p&gt;

&lt;p&gt;
We used that trick on a very early, OTP 20 pin 8051 when I was
working for Eagle Signal Controls in Austin.&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Keil 8051 interrupt ISR</title><link>https://community.arm.com/thread/144430?ContentTypeID=1</link><pubDate>Mon, 14 Jul 2008 09:51:59 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:879abf0b-c552-4a26-8f04-0d39e1104373</guid><dc:creator>Neil Kurzmam</dc:creator><description>&lt;p&gt;&lt;p&gt;
This is not a general 8052 question. This is an add-on that is
specific to your Chip. The general 8052 rules do not fully apply.&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Keil 8051 interrupt ISR</title><link>https://community.arm.com/thread/151977?ContentTypeID=1</link><pubDate>Mon, 14 Jul 2008 05:40:57 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:7e714e8a-289e-440c-abe2-2762d17d984b</guid><dc:creator>Jack Sprat</dc:creator><description>&lt;p&gt;&lt;p&gt;
&lt;i&gt;OH BOY, let me try to blow some smoke out of your uppermost
body part.&lt;/i&gt;&lt;/p&gt;

&lt;p&gt;
Er, what?&lt;/p&gt;

&lt;p&gt;
&lt;i&gt;based on your statements of no IP involvement:&lt;/i&gt;&lt;/p&gt;

&lt;p&gt;
No IP involvement in the ISR, yes. I&amp;#39;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.&lt;/p&gt;

&lt;p&gt;
&lt;i&gt;In the interrupt sense, the bahavoiour of RI AND TI is totally
irrelevant unless all the following conditiona are met.&lt;/i&gt;&lt;/p&gt;

&lt;p&gt;
In the non-interrupt sense the behaviour of RI and TI is totally
relevant. You stated that the program &amp;#39;would not work&amp;#39; if the
interrupt were only enabled inside the other ISR, I&amp;#39;m just trying to
point you towards the documentation that will show you how.&lt;/p&gt;

&lt;p&gt;
&lt;i&gt;since your scribbles (it would be an offence to call it code)
only satisfy a) when b) is false it does not work.&lt;/i&gt;&lt;/p&gt;

&lt;p&gt;
There you go again. Given that the snippet I posted was two lines
of code in one function you&amp;#39;re assuming rather a lot, don&amp;#39;t you
think? Can you try to guess how one might code outwith the posted ISR
to handle the situation?&lt;/p&gt;

&lt;p&gt;
&lt;i&gt;It is surely obvious that the interrupt must be of a higher
priority?&lt;br /&gt;
based on the above: which, confound it, is what I have stated from
the very beginning of this thread&lt;/i&gt;&lt;/p&gt;

&lt;p&gt;
That may be what you think you tried to say, but I suggest you go
back and read the thread from the beginning, slowly.&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Keil 8051 interrupt ISR</title><link>https://community.arm.com/thread/142052?ContentTypeID=1</link><pubDate>Fri, 11 Jul 2008 20:32:31 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:90d2aad3-4e0e-4985-900c-6ff77b36e86e</guid><dc:creator>HRX Raad</dc:creator><description>&lt;p&gt;&lt;p&gt;
Thanks for your comments. The problem turned out to be something
very simple. Solution:&lt;/p&gt;

&lt;p&gt;
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.&lt;/p&gt;

&lt;p&gt;
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.&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Keil 8051 interrupt ISR</title><link>https://community.arm.com/thread/154580?ContentTypeID=1</link><pubDate>Fri, 11 Jul 2008 06:27:03 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:b72b9032-1916-45a1-b591-8e5768aff24b</guid><dc:creator>andy malund</dc:creator><description>&lt;p&gt;&lt;p&gt;
&lt;i&gt;&amp;quot;it is for some&amp;quot;&lt;/i&gt;&lt;/p&gt;

&lt;p&gt;
As is walking across the road, but that doesn&amp;#39;t mean people should
never do it!&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Keil 8051 interrupt ISR</title><link>https://community.arm.com/thread/151244?ContentTypeID=1</link><pubDate>Fri, 11 Jul 2008 06:14:27 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:8dd21aed-674d-4e08-9d5d-831f80018a52</guid><dc:creator>erik  malund</dc:creator><description>&lt;p&gt;&lt;p&gt;
OH BOY, let me try to blow some smoke out of your uppermost body
part.&lt;/p&gt;

&lt;p&gt;
&lt;b&gt;based on&lt;/b&gt; your statements of no IP involvement:&lt;br /&gt;
&lt;i&gt;Observe, in particular, the behaviour of TI and RI.&lt;/i&gt;&lt;/p&gt;

&lt;p&gt;
In the interrupt sense, the bahavoiour of RI AND TI is &lt;b&gt;totally
irrelevant&lt;/b&gt; unless all the following conditiona are met.&lt;br /&gt;
a) the UART interrupt is enabled&lt;br /&gt;
b) no ISR of same or higher priority is running&lt;/p&gt;

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

&lt;p&gt;
&lt;i&gt;It is surely obvious that the interrupt must be of a higher
priority?&lt;/i&gt;&lt;br /&gt;
&lt;b&gt;based on&lt;/b&gt; the above: which, confound it, is what I have stated
from the very beginning of this thread&lt;/p&gt;

&lt;p&gt;
Erik&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Keil 8051 interrupt ISR</title><link>https://community.arm.com/thread/154062?ContentTypeID=1</link><pubDate>Fri, 11 Jul 2008 06:05:17 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:855cca1e-792d-417f-84db-5343b08b9157</guid><dc:creator>erik  malund</dc:creator><description>&lt;p&gt;&lt;p&gt;
&lt;i&gt;The term &amp;quot;error prone&amp;quot; makes it sound so incredibly dangerous.
It&amp;#39;s not.&lt;/i&gt;&lt;br /&gt;
it is for some&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Keil 8051 interrupt ISR</title><link>https://community.arm.com/thread/150692?ContentTypeID=1</link><pubDate>Fri, 11 Jul 2008 05:15:01 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:cdd7613f-a04d-4184-a1d9-9ed25434e1f9</guid><dc:creator>Jack Sprat</dc:creator><description>&lt;p&gt;&lt;p&gt;
&lt;i&gt;you exit the &amp;quot;some&amp;quot; ISR with the serial int disabled, when is
it going to be &amp;#39;caught&amp;#39;.&lt;/i&gt;&lt;/p&gt;

&lt;p&gt;
There is no requirement to &amp;#39;catch&amp;#39; serial interrupts when they are
disabled.&lt;/p&gt;

&lt;p&gt;
here are the links to &amp;quot;the bible&amp;quot;&lt;br /&gt;
Chapter 1 - 80C51 Family Architecture:&lt;br /&gt;
&lt;a href="http://www.nxp.com/acrobat_download/various/80C51_FAM_ARCH_1.pdf"&gt;www.nxp.com/.../80C51_FAM_ARCH_1.pdf&lt;/a&gt;&lt;/p&gt;

&lt;p&gt;
Chapter 2 - 80C51 Family
Programmer&amp;Atilde;&amp;cent;&amp;acirc;&amp;sbquo;&amp;not;&amp;acirc;&amp;bdquo;&amp;cent;s
Guide and Instruction Set:&lt;br /&gt;

&lt;a href="http://www.nxp.com/acrobat_download/various/80C51_FAM_PROG_GUIDE_1.pdf"&gt;www.nxp.com/.../80C51_FAM_PROG_GUIDE_1.pdf&lt;/a&gt;&lt;/p&gt;

&lt;p&gt;
Chapter 3 - 80C51 Family Hardware Description:&lt;br /&gt;

&lt;a href="http://www.nxp.com/acrobat_download/various/80C51_FAM_HARDWARE_1.pdf"&gt;www.nxp.com/.../80C51_FAM_HARDWARE_1.pdf&lt;/a&gt;&lt;/p&gt;

&lt;p&gt;
Observe, in particular, the behaviour of TI and RI.&lt;/p&gt;

&lt;p&gt;
&lt;i&gt;that is a real problem&lt;/i&gt;&lt;/p&gt;

&lt;p&gt;
No, it isn&amp;#39;t.&lt;/p&gt;

&lt;p&gt;
&lt;i&gt;however, it is besides the point&lt;/i&gt;&lt;/p&gt;

&lt;p&gt;
Absolutely. It&amp;#39;s one of your smokescreen attempts.&lt;/p&gt;

&lt;p&gt;
&lt;i&gt;the original issue was to have an interrupt interrupt an
interrupt without using the IP.&lt;/i&gt;&lt;/p&gt;

&lt;p&gt;
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 &amp;#39;only IP can do that&amp;#39;, no
manipulation of IP inside the ISR is required. It is surely obvious
that the interrupt must be of a higher priority?&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Keil 8051 interrupt ISR</title><link>https://community.arm.com/thread/153434?ContentTypeID=1</link><pubDate>Thu, 10 Jul 2008 23:25:54 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:13f951c3-95df-4d2d-8ece-4ac5d0561559</guid><dc:creator>andy malund</dc:creator><description>&lt;p&gt;&lt;p&gt;
The term &amp;quot;error prone&amp;quot; makes it sound so incredibly dangerous.
It&amp;#39;s not. It just requires a little careful consideration. Just like
most (non-trivial) programming tasks.&lt;/p&gt;

&lt;p&gt;
With regards to your &lt;i&gt;trick&lt;/i&gt; ... Yes, I agree it is another
useful &lt;i&gt;technique&lt;/i&gt;. I have done the very same thing on a number
of occasions (on a number of different CPU cores).&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Keil 8051 interrupt ISR</title><link>https://community.arm.com/thread/152752?ContentTypeID=1</link><pubDate>Thu, 10 Jul 2008 13:27:21 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:aca43832-aa8a-436a-b41c-62bd75fd29f8</guid><dc:creator>erik  malund</dc:creator><description>&lt;p&gt;&lt;p&gt;
you say: &amp;quot;(carefully) crafting&amp;quot; [I would drop the paranthesis]&lt;br /&gt;
I say &amp;quot;error prone&amp;quot;&lt;/p&gt;

&lt;p&gt;
same thing just from different directions&lt;/p&gt;

&lt;p&gt;
There is, another trick that is valuable (and I have used) in some
cases:&lt;br /&gt;
I use T0 as the example of the interrupt you just happen not to use,
any unused interrupt will do.&lt;br /&gt;
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.&lt;/p&gt;

&lt;p&gt;
Erik&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Keil 8051 interrupt ISR</title><link>https://community.arm.com/thread/151981?ContentTypeID=1</link><pubDate>Thu, 10 Jul 2008 12:59:21 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:23b6b3cf-9b0f-48a2-ac08-60f28e8a862a</guid><dc:creator>andy malund</dc:creator><description>&lt;p&gt;&lt;p&gt;
&lt;i&gt;&amp;quot;Pray tell how to code to ensure so that e.g. a switch
connected to EI0 does not get closed again within, say, 17ms
?&amp;quot;&lt;/i&gt;&lt;/p&gt;

&lt;p&gt;
You&amp;#39;ve &lt;b&gt;got&lt;/b&gt; to realise - It is not being said (or even
suggested) that nested interrupts are obligatory.&lt;/p&gt;

&lt;p&gt;
You&amp;#39;re example is just not the type of situation where they would
be necessary; therefore it is not an issue.&lt;/p&gt;

&lt;p&gt;
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.&lt;/p&gt;

&lt;p&gt;
However ... Don&amp;#39;t mark a mechanism as floored simply because
&lt;b&gt;you&lt;/b&gt; cannot do it.&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Keil 8051 interrupt ISR</title><link>https://community.arm.com/thread/152748?ContentTypeID=1</link><pubDate>Thu, 10 Jul 2008 10:16:40 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:83915863-03c5-4551-9d10-116b72da7f4c</guid><dc:creator>erik  malund</dc:creator><description>&lt;p&gt;&lt;p&gt;
&lt;i&gt;A different - and somewhat (!) inflamed - thread discusses
black or white or shades in between. This is yet another example of
nuances. If I don&amp;#39;t need nested interrupts, I avoid them. But I don&amp;#39;t
forbid myself from using them if I feel that they represent a real
advantage.&lt;/i&gt;&lt;br /&gt;
nothing wrong with bested interrupts (I use them), but why all that
hoolabaloo about doing it without using the intended tool:
&lt;b&gt;IP&lt;/b&gt;&lt;/p&gt;

&lt;p&gt;
Erik&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Keil 8051 interrupt ISR</title><link>https://community.arm.com/thread/150311?ContentTypeID=1</link><pubDate>Thu, 10 Jul 2008 10:13:02 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:e0eeeca5-e877-48fc-9ec6-830f4fa84a0c</guid><dc:creator>erik  malund</dc:creator><description>&lt;p&gt;&lt;p&gt;
&lt;i&gt;No, the code I posted does not require any interrupt to be
enabled anywhere else other than interrupt 0 during
initialisation&lt;/i&gt;&lt;br /&gt;
you exit the &amp;quot;some&amp;quot; ISR with the serial int disabled, when is it
going to be &amp;#39;caught&amp;#39;.&lt;/p&gt;

&lt;p&gt;
that is a real problem, however, it is besides the point, the
original issue was to have an interrupt interrupt an interrupt
&lt;b&gt;without using the IP&lt;/b&gt;.&lt;/p&gt;

&lt;p&gt;
Erik&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Keil 8051 interrupt ISR</title><link>https://community.arm.com/thread/151240?ContentTypeID=1</link><pubDate>Thu, 10 Jul 2008 10:08:58 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:6ddec3fd-87bc-4309-8386-7d939a7b917a</guid><dc:creator>erik  malund</dc:creator><description>&lt;p&gt;&lt;p&gt;
&lt;i&gt;I simply do not agree with that! You must program the
controller via the code to ensure it will not happen.&lt;/i&gt;&lt;br /&gt;
Pray tell how to &lt;b&gt;code to ensure&lt;/b&gt; so that e.g. a switch
connected to EI0 does not get closed again within, say, 17ms ?&lt;/p&gt;

&lt;p&gt;
&lt;i&gt;Details of it can be found in the Bible document
80C51_FAM_ARCH_1.pdf on page 15 under the title &amp;quot;Simulating a Third
Priority Level in Software&amp;quot;&lt;/i&gt;&lt;br /&gt;
oh, yes, now I recall, never having used it the memory faded.&lt;/p&gt;

&lt;p&gt;
Erik&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Keil 8051 interrupt ISR</title><link>https://community.arm.com/thread/151973?ContentTypeID=1</link><pubDate>Thu, 10 Jul 2008 09:56:37 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:ac3f7dd6-f126-4755-8363-fa79a06240e2</guid><dc:creator>ImPer Westermark</dc:creator><description>&lt;p&gt;&lt;p&gt;
Error prone or not - nested interrupts are quite common and can be
very valuable for some hard-to-service hardware.&lt;/p&gt;

&lt;p&gt;
It shouldn&amp;#39;t be ignored just because it can fail - an incompetent
programmer can manage to blow up a single &amp;quot;hello world&amp;quot;. The problem
isn&amp;#39;t if the tools supports failing constructs, but of the developer
allows the code to fail.&lt;/p&gt;

&lt;p&gt;
If I decided to limit myself to totally &amp;quot;safe&amp;quot; development tools,
I may have to switch to Logo. But I fear that my productivity would
take a hit.&lt;/p&gt;

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

&lt;p&gt;
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.&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Keil 8051 interrupt ISR</title><link>https://community.arm.com/thread/149883?ContentTypeID=1</link><pubDate>Thu, 10 Jul 2008 09:21:53 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:e7b2f180-58f1-4b8a-afe4-af5836ffecaa</guid><dc:creator>Jack Sprat</dc:creator><description>&lt;p&gt;&lt;p&gt;
&lt;i&gt;in the sample the smoked sardine gives above, the serial
interrupt will never be serviced&lt;/i&gt;&lt;/p&gt;

&lt;p&gt;
You&amp;#39;re still wrong.&lt;/p&gt;

&lt;p&gt;
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.&lt;/p&gt;

&lt;p&gt;
&lt;i&gt;precluding a totally screed up design&lt;/i&gt;&lt;/p&gt;

&lt;p&gt;
Is that Greek, by any chance?&lt;/p&gt;

&lt;p&gt;
&lt;i&gt;that disables it in an ISR (the enable has no effect) and then
enabling it asynchronously in the main&lt;/i&gt;&lt;/p&gt;

&lt;p&gt;
No, the code I posted does not require any interrupt to be enabled
anywhere else other than interrupt 0 during initialisation.&lt;/p&gt;

&lt;p&gt;
Your original response was wrong and may have mislead the OP.
Accept it.&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Keil 8051 interrupt ISR</title><link>https://community.arm.com/thread/146226?ContentTypeID=1</link><pubDate>Thu, 10 Jul 2008 08:18:47 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:ec9b7299-4746-4281-b89c-a037408eba10</guid><dc:creator>andy malund</dc:creator><description>&lt;p&gt;&lt;p&gt;
&lt;i&gt;&amp;quot;What you show is &amp;#39;possible&amp;#39;, however it is error
prone.&amp;quot;&lt;/i&gt;&lt;/p&gt;

&lt;p&gt;
It&amp;#39;s more that possible! I actually use it!&lt;/p&gt;

&lt;p&gt;
Sure, you must be careful with the design, but any
&lt;b&gt;competent&lt;/b&gt; 8051 programmer should be able to cope with such a
requirement.&lt;/p&gt;

&lt;p&gt;
&lt;i&gt;&amp;quot;that will never happen&amp;quot; is not a valid system design
parameter.&lt;/i&gt;&lt;/p&gt;

&lt;p&gt;
I simply do not agree with that! You must program the controller
&lt;b&gt;via the code&lt;/b&gt; to ensure it &lt;b&gt;will not&lt;/b&gt; happen. It is not
impossible to write code that can protect against such things; so
long as the coder has sufficient understanding.&lt;/p&gt;

&lt;p&gt;
Details of it &lt;b&gt;can&lt;/b&gt; be found in the Bible document
80C51_FAM_ARCH_1.pdf on page 15 under the title &amp;quot;Simulating a Third
Priority Level in Software&amp;quot;. With understanding of this, it is
possible to simulate fourth, fifth, sixth priorities if so
required.&lt;/p&gt;

&lt;p&gt;
I suggest you re-visit the Bible and learn.&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Keil 8051 interrupt ISR</title><link>https://community.arm.com/thread/144428?ContentTypeID=1</link><pubDate>Thu, 10 Jul 2008 07:55:54 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:e697a284-4d5c-4d35-8f8a-86ee437aed16</guid><dc:creator>erik  malund</dc:creator><description>&lt;p&gt;&lt;p&gt;
&lt;i&gt;Multi-level priorities can be achieved by (carefully) crafting
the ISR; basically using code like,&lt;/i&gt;&lt;/p&gt;

&lt;pre&gt;
&lt;i&gt;    LCALL    IsrRelease ;Release interrupt from priority logic
    ... Do other things with interrupt released

    RET

IsrRelease:

    RETI&lt;/i&gt;
&lt;/pre&gt;

&lt;p&gt;
&lt;i&gt;I have a vague recollection of seeing something like this in
the Bible.&lt;/i&gt;&lt;/p&gt;

&lt;p&gt;
&lt;i&gt;Anyway, it works - And works well.&lt;/i&gt;&lt;br /&gt;
What you show is &amp;#39;possible&amp;#39;, however it is error prone. Just
visualize what happens if the interrupt for which you call
&amp;quot;IsrRelease&amp;quot; happens again before the RET is reached? &amp;quot;that will
never happen&amp;quot; is not a valid system design parameter.&lt;/p&gt;

&lt;p&gt;
I have no recollection,vague or not of &amp;quot;seeing something like this
in the Bible&amp;quot;&lt;/p&gt;

&lt;p&gt;
Erik&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Keil 8051 interrupt ISR</title><link>https://community.arm.com/thread/142050?ContentTypeID=1</link><pubDate>Thu, 10 Jul 2008 07:02:32 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:29261cf6-2d37-4fee-bdb1-fa31eeef26e8</guid><dc:creator>andy malund</dc:creator><description>&lt;p&gt;&lt;p&gt;
&lt;i&gt;2) the only way to malke an interupt interrupt an interrupt is
by giving it a higher priority&lt;/i&gt;&lt;/p&gt;

&lt;p&gt;
Should read:&lt;/p&gt;

&lt;p&gt;
&lt;i&gt;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&lt;/i&gt;&lt;/p&gt;

&lt;p&gt;
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,&lt;/p&gt;

&lt;pre&gt;
    LCALL    IsrRelease ;Release interrupt from priority logic
    ... Do other things with interrupt released

    RET

IsrRelease:

    RETI
&lt;/pre&gt;

&lt;p&gt;
I have a vague recollection of seeing something like this in the
Bible.&lt;/p&gt;

&lt;p&gt;
Anyway, it works - And works well.&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Keil 8051 interrupt ISR</title><link>https://community.arm.com/thread/138835?ContentTypeID=1</link><pubDate>Thu, 10 Jul 2008 06:47:22 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:1360220b-40c3-4226-8f25-89c2a40a9f6a</guid><dc:creator>erik  malund</dc:creator><description>&lt;p&gt;&lt;p&gt;
1) if an ISR is running, no interrupt of the same priority will
happen.&lt;br /&gt;
2) the only way to malke an interupt interrupt an interrupt is by
giving it a higher priority&lt;br /&gt;
3) evidently the Cypress chips have some other mechanism, so the
above may not apply to then&lt;br /&gt;
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&lt;/p&gt;

&lt;p&gt;
Erik&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Keil 8051 interrupt ISR</title><link>https://community.arm.com/thread/135450?ContentTypeID=1</link><pubDate>Thu, 10 Jul 2008 06:08:19 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:676db8d3-5bd2-4aea-829d-7c9d26198c39</guid><dc:creator>Catcus Blip</dc:creator><description>&lt;p&gt;&lt;p&gt;
what is happening here? will you guys STOP confusing everybody
here and argument using damn SOLID facts onces and for all?!!?!?! I
don&amp;#39;t know who to believe anymore!&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Keil 8051 interrupt ISR</title><link>https://community.arm.com/thread/124799?ContentTypeID=1</link><pubDate>Thu, 10 Jul 2008 05:38:34 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:9b1facbb-bf25-4022-b891-d54939eed74d</guid><dc:creator>Jack Sprat</dc:creator><description>&lt;p&gt;&lt;p&gt;
Here&amp;#39;s the question:&lt;/p&gt;

&lt;p&gt;
&lt;i&gt;are you doing something such as enabling interrupts or
something inside an ISR&lt;/i&gt;&lt;/p&gt;

&lt;p&gt;
Here&amp;#39;s Erik&amp;#39;s response:&lt;/p&gt;

&lt;p&gt;
&lt;i&gt;none of that would make another interrupt interrupt the
ISR&lt;/i&gt;&lt;/p&gt;

&lt;p&gt;
Here&amp;#39;s some code that shows the response is wrong:&lt;/p&gt;

&lt;pre&gt;
void SomeIsr(void) interrupt 0
{
   //Code that doesn&amp;#39;t involve IP
   //No interrupts of higher priority enabled

   ES=1;

   //Some more code not involving IP
   //interrupted by a serial interrupt

   ES=0;
}
&lt;/pre&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Keil 8051 interrupt ISR</title><link>https://community.arm.com/thread/147421?ContentTypeID=1</link><pubDate>Wed, 09 Jul 2008 12:01:36 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:bb90e59c-66a2-4273-aa9e-ab7542dbdbe2</guid><dc:creator>Neil Kurzmam</dc:creator><description>&lt;p&gt;&lt;p&gt;
I looked at one of the EZ-USB chips. You have several options, you
code snippet tells very little. Priority applies. Plus there is a
second USB Interrupt priority there is a note about the proper order
to clear the flags. USB is not on interrupt 0. There are 2 USB
interrupts with several events.&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Keil 8051 interrupt ISR</title><link>https://community.arm.com/thread/146223?ContentTypeID=1</link><pubDate>Wed, 09 Jul 2008 09:16:58 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:b189f275-1020-430b-9ee9-be6fc4e28b20</guid><dc:creator>Neil Kurzmam</dc:creator><description>&lt;p&gt;&lt;p&gt;
EZUSB is not a number, unless they only have one chip in the
family. I will look. Event B and A is that how they are referred to
in the data sheet? You are giving very little to work with. Only
people who have worked on that specific chip can help. I am not
convinced you hypothesis is correct.&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Keil 8051 interrupt ISR</title><link>https://community.arm.com/thread/146219?ContentTypeID=1</link><pubDate>Wed, 09 Jul 2008 05:48:52 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:1c168afc-4ced-4b30-af0a-a24169cfba66</guid><dc:creator>erik  malund</dc:creator><description>&lt;p&gt;&lt;p&gt;
&lt;i&gt;The chip is EZUSB from Cypress semiconductor. The 8051 in there
has some enhancements with a external vectored interrupt
controller.&lt;/i&gt;&lt;br /&gt;
If that had been included in the first post, maybe 2/3 of the effort
many has made to help you would not have been wasted.&lt;/p&gt;

&lt;p&gt;
Erik&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item></channel></rss>