<?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>AT91SAM: nested interrupts</title><link>https://community.arm.com/developer/tools-software/tools/f/keil-forum/24907/at91sam-nested-interrupts</link><description> 
Hi all, 

 
in my project, I&amp;#39;ve three main processes (ethernet stack, gui-tft
and usart interface). The gui routine (for the whole user interface
including touch, tft, encoder) takes its time, therefore the ethernet
stack part uses an interrupt (execution</description><dc:language>en-US</dc:language><generator>Telligent Community 10</generator><item><title>RE: AT91SAM: nested interrupts</title><link>https://community.arm.com/thread/130565?ContentTypeID=1</link><pubDate>Fri, 20 Nov 2009 01:37:53 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:c9ed5729-3a14-46cb-aac8-2246e8562492</guid><dc:creator>Hannes Lange</dc:creator><description>&lt;p&gt;&lt;p&gt;
Because, the Gui_Update() function takes too long... therefore I
tried to use an timer interrupt for processing the incoming ethnernet
pkts (to process one pkt takes longer than two or more interrupts
events (usart) -&amp;gt; nested interrupts...&lt;/p&gt;

&lt;p&gt;
The pkts at the usart will arrive all 40us. In the worst case
(both usart connections): 20us.&lt;/p&gt;

&lt;p&gt;
Without using the timer interrupt, all ISRs are fast enough to
achieve these timings. But the GUI_Update function won&amp;#39;t..., if this
function is running, the processor will miss (has not enough time to
process these pkts) two or three ethernet pkts...&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: AT91SAM: nested interrupts</title><link>https://community.arm.com/thread/125878?ContentTypeID=1</link><pubDate>Fri, 20 Nov 2009 01:29:23 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:3a57527b-842c-4195-b58e-21ec1a4b8d2c</guid><dc:creator>Christoph Franck</dc:creator><description>&lt;p&gt;&lt;p&gt;
&lt;i&gt;That&amp;#39;s the problem at the moment.&lt;/i&gt;&lt;/p&gt;

&lt;p&gt;
So why do you need to &lt;b&gt;nest&lt;/b&gt; interrupts? If the UART ISR
finishes quickly enough for the ethernet packets to be processed by
the ethernet ISR, nesting is not necessary at all! Just process the
interrupts normally, i.e. the ISRs for interrupts that arrive while
another ISR is running run after the current ISR finishes.&lt;/p&gt;

&lt;p&gt;
I have an application where I need to nest interrupts. The
required response time for the UART is in the order of 20
microseconds, which could not be achieved if I let my other ISRs run
to completion. Hence the UART ISR is allowed to interrupt another ISR
that is currently running. If I didn&amp;#39;t have the 20us time constraint,
nesting wouldn&amp;#39;t be necessary.&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: AT91SAM: nested interrupts</title><link>https://community.arm.com/thread/115414?ContentTypeID=1</link><pubDate>Fri, 20 Nov 2009 01:16:01 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:ec3146cb-086c-4660-9d85-ab2323daa51a</guid><dc:creator>Hannes Lange</dc:creator><description>&lt;p&gt;&lt;p&gt;
&lt;i&gt;Are you using the processors DMA facilities to avoid having to
move around received and transmitted data by hand?&lt;/i&gt;&lt;/p&gt;

&lt;p&gt;
I&amp;#39;m using the dma for receiving the ethernet pkts.&lt;/p&gt;

&lt;p&gt;
&lt;i&gt;You said that the ethernet packets needs to be processed
quickly.&lt;/i&gt;&lt;br /&gt;
That&amp;#39;s true. It makes no such big difference in my case to use
polling or interrupt method.&lt;/p&gt;

&lt;pre&gt;
int main(void)
{
  //....

  while(1)
  {

   /* using the ethernet interrupt */
   if(EthPkt &amp;gt; 0)
      Emac_RxPkt();

   if(Usart0Pkt &amp;gt; 0)
      Usart0_RxPkt();

   if(Usart1Pkt &amp;gt; 0)
      Usart1_RxPkt();

   /* if there&amp;#39;s an user input (touch, tft, encoder) */
   if(Gui_UserInput)
      Gui_Update();
  }
}
&lt;/pre&gt;

&lt;p&gt;
The function Gui_Update() is the function which takes a long time
(to produce all the stuff). Therefore if there&amp;#39;s another interrupt
(ethernet pkt received -&amp;gt; and the variable EthPkt increases -&amp;gt;
it is also only possible to get this new pkt after finishing the
Gui_Update() function.&lt;br /&gt;
That&amp;#39;s the problem at the moment.&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: AT91SAM: nested interrupts</title><link>https://community.arm.com/thread/103626?ContentTypeID=1</link><pubDate>Fri, 20 Nov 2009 00:58:22 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:3510c720-b58c-49f7-a0c4-bc73a0a6ff2a</guid><dc:creator>Christoph Franck</dc:creator><description>&lt;p&gt;&lt;p&gt;
&lt;i&gt;or is it possible to avoid nested interrupts....?&lt;/i&gt;&lt;/p&gt;

&lt;p&gt;
Possibly, if you keep the ISRs short enough that their execution
time is within the acceptable latency for the other ISRs.&lt;/p&gt;

&lt;p&gt;
Are you using the processors DMA facilities to avoid having to
move around received and transmitted data by hand?&lt;/p&gt;

&lt;p&gt;
&lt;i&gt;Using an interrupt for incoming usart pkts, using polling
method vor incoming ethernet pkts - will work;&lt;/i&gt;&lt;/p&gt;

&lt;p&gt;
You said that the ethernet packets needs to be processed quickly.
I doubt that this will be the case if you&amp;#39;re polling for these
packets and don&amp;#39;t want to spend most of the CPU time doing the
polling.&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: AT91SAM: nested interrupts</title><link>https://community.arm.com/thread/77934?ContentTypeID=1</link><pubDate>Fri, 20 Nov 2009 00:41:02 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:d2305b04-cf14-46ab-b1f7-51a80f98077a</guid><dc:creator>Hannes Lange</dc:creator><description>&lt;p&gt;&lt;p&gt;
or is it possible to avoid nested interrupts....?&lt;/p&gt;

&lt;p&gt;
Using an interrupt for incoming usart pkts, using polling method
vor incoming ethernet pkts - will work; but the update function of
the graphical user interface takes too long (during this time, the
processor is not able to get all ethernet pkts in time...&lt;/p&gt;

&lt;p&gt;
any ideas?&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: AT91SAM: nested interrupts</title><link>https://community.arm.com/thread/57285?ContentTypeID=1</link><pubDate>Thu, 19 Nov 2009 06:17:49 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:2c7cb57b-019d-4505-9b3b-8d3ea21f80e2</guid><dc:creator>Christoph Franck</dc:creator><description>&lt;p&gt;&lt;p&gt;
&lt;i&gt;Is there a option / possibility to work with nested interrupts
(a work around)?&lt;/i&gt;&lt;/p&gt;

&lt;p&gt;
I&amp;#39;m not familiar with that particular part, but Atmel does
describe the process required to use nested interrupt in the
datasheets of the parts that I am familiar with.&lt;/p&gt;

&lt;p&gt;
It basically consists of re-enabling interrupts at a particular
point of the ISR.&lt;/p&gt;

&lt;p&gt;
Hence, looking at the interrupt controller chapter of the chips
documentation might be a good start.&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item></channel></rss>