ARM How to handle nested interrupts in LPC2300

Actualy i just giving an example.

but you indicated a real problem, then said that you tried the supplied macros to no avail. so what's up?
note that most problem can and should be solved without nested interrupts - which could introduce challenges that are not always evident (stack space violations for example).

Actualy i just giving an example.

but you indicated a real problem, then said that you tried the supplied macros to no avail. so what's up?
note that most problem can and should be solved without nested interrupts - which could introduce challenges that are not always evident (stack space violations for example).

Here is Ext0 ISR

void EXT0_ISR (void) __irq
{ EXTINT = 0x01;

IENABLE; TransmitChar0('E');

Timer1Delay(50); // delay for 50ms sec

TransmitChar0('I'); TransmitChar0('N'); TransmitChar0('T');

IDISABLE; VICVectAddr = 0;
}

And Timer0 is 10ms.
After putting IENABLE & IDISABLE.
processor stop working.

regards
SS T.

I think first u need to disable interrupts when
u enter ISR, and enable back when u getting out of
that... anyway also with the defination of your
IENABLE and IDISABLE macro make sure that u enable
and disable ONLY current interrupt and remaining interrupts are open.

I think first u need to disable interrupts when
u enter ISR

No. That is the default behavior.

Timer1Delay(50); // delay for 50ms sec

why are you doing this?

if you are transmitting your data using a serial port, why not use the processor's transmit interrupt capability...? or even better, set a hardware timer's overflow counter on such a value that it would generate an interrupt EXACTLY when you need to send data, rather than to wait in the ISR itself?

you need to:
* read the processor's manual
* deepen yourself in the consequences of decisions that you make when you write a program.

There are reasons when an interrupt may need ns or us delays just because the hardware have timing limitations and the delay is too short to allow the next step to be handled by a second interrupt.

But to have the processor deadlock for 50ms just to delay the transfer of a second character is not good at all. How much do your think your Windows machine would manage to do if all I/O were handled by interrupt service routines performing inter-character delays.

Always design your ISR to do a quick job and then directly leave. The only reason do to something else is if you for some reason can allow the ISR to permanently lock out the normal program - for example like a trap handler that reports a grave error and then stops the processor in an infinite loop, requiring you to connect with a debugger to check the stack trace.

Is is possible to interrupt to interrupt isr (timer0 interrupt to ISR of EINT0)?

SS T.
Pune India.