AT91SAM: nested interrupts

Is there a option / possibility to work with nested interrupts (a work around)?

I'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.

It basically consists of re-enabling interrupts at a particular point of the ISR.

Hence, looking at the interrupt controller chapter of the chips documentation might be a good start.

or is it possible to avoid nested interrupts....?

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

any ideas?

or is it possible to avoid nested interrupts....?

Possibly, if you keep the ISRs short enough that their execution time is within the acceptable latency for the other ISRs.

Are you using the processors DMA facilities to avoid having to move around received and transmitted data by hand?

Using an interrupt for incoming usart pkts, using polling method vor incoming ethernet pkts - will work;

You said that the ethernet packets needs to be processed quickly. I doubt that this will be the case if you're polling for these packets and don't want to spend most of the CPU time doing the polling.

Are you using the processors DMA facilities to avoid having to move around received and transmitted data by hand?

I'm using the dma for receiving the ethernet pkts.

You said that the ethernet packets needs to be processed quickly.
That's true. It makes no such big difference in my case to use polling or interrupt method.

int main(void)
{
  //....

  while(1)
  {

   /* using the ethernet interrupt */
   if(EthPkt > 0)
      Emac_RxPkt();

   if(Usart0Pkt > 0)
      Usart0_RxPkt();

   if(Usart1Pkt > 0)
      Usart1_RxPkt();

   /* if there's an user input (touch, tft, encoder) */
   if(Gui_UserInput)
      Gui_Update();
  }
}

The function Gui_Update() is the function which takes a long time (to produce all the stuff). Therefore if there's another interrupt (ethernet pkt received -> and the variable EthPkt increases -> it is also only possible to get this new pkt after finishing the Gui_Update() function.
That's the problem at the moment.

That's the problem at the moment.

So why do you need to nest 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.

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't have the 20us time constraint, nesting wouldn't be necessary.

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) -> nested interrupts...

The pkts at the usart will arrive all 40us. In the worst case (both usart connections): 20us.

Without using the timer interrupt, all ISRs are fast enough to achieve these timings. But the GUI_Update function won't..., if this function is running, the processor will miss (has not enough time to process these pkts) two or three ethernet pkts...