hello forum. i want to use, both external interupts on arduino Uno.
the problem is ,that both interupts, will happen with high frequency, so there is a chanche, that one interupt(INT1) ,will be received, while the program executes the interupt function of INTO....
i have read that when atmega is on ISR function, it blocks all incoming interupts....
is there any way to disable this, so that when an interupts happens, it could interupt the ISR as well??
No. The AVR does not have priority interrupts. While you're in the ISR of some interrupt, the other interrupts have to wait. Keep the code in your ISR short and this should not be a great limitation.
well, since one interupt will happen with high frequency (every 0.4ms ) and the other every 2-3 ms, i am more worried, of the just happening in the "exact " same time, than happening when the program is inside ISR.... 
There is a list of interrupt pirorities in the processors data sheet. But any interrupt will not be missed it will be seen when the other ISR finishes. However if you enable the interrupts in an ISR then that interrupt routine will be interrupted.
What do you mean by :
But any interrupt will not be missed it will be seen when the other ISR finishes
if INT1 happens when you are in ISR0, then ISR1 will happen as soon as ISR0 finishes??? is that by default???
(also, i am ok with interupting the ISR,but how do i enable it? )
is that by default?
Yes, it will probably execute a single instruction then service the second interrupt.
interupting the ISR,but how do i enable it?
sei();
And stand back as your program will quite likely fail or become unstable unless you have really nailed all the interrupt sources down and know what you are doing, (or turn off other interrupts like the timer and serial). Nested interrupts are not for the faint hearted.
Rob
settra:
well, since one interupt will happen with high frequency (every 0.4ms ) and the other every 2-3 ms, i am more worried, of the just happening in the "exact " same time, than happening when the program is inside ISR....
That's not high frequency!!
If your interrupt routines finish in a few us as they should, no bad issues
will happen - the millis interrupt is already happening every 1.024ms.
I have a system with one interrupt running at 16kHz and some other interrupts
as well and it all just works - but I keep the ISRs as short as possible (using
direct port manipulation for example).
As long as none of your interrupt handlers take so long to run that you get multiple interrupts from the other source, it will simply work. The only consequence of having interrupts occur while another interrupt is being handled is that the buffered interrupts are handled fractionally later than when they occurred. Good practice is to keep interrupt handlers short and simple and if you follow that then at those low frequencies you won't have any problem.
sei();
And stand back as your program will quite likely fail or become unstable unless you have really nailed all the interrupt sources down and know what you are doing, (or turn off other interrupts like the timer and serial). Nested interrupts are not for the faint hearted.
well then, i suppose, ther is no need for sei() , since INT0 will be handled after ISR1 is done !!
i suppose that is also the reason that the program fails , if you use buttons as interupt, cause of their debouncing??
(too many interupts happen before the first is done, and it cant handle them all? )
i suppose that is also the reason that the program fails ,
What program is this then? Have you posted it? Maybe if you did we could see why it fails.
and it cant handle them all?
That will only be the case if the ISR takes longer to do than the interval between successive interrupts triggering the same pin.
if you use buttons as interupt, cause of their debouncing
Any bounce should be way longer than an ISR.
oh yes. i meant any generic program which has an Serial.print() on the ISR, will fail cause of button debouncing...
settra:
oh yes. i meant any generic program which has an Serial.print() on the ISR, will fail cause of button debouncing...
No.
Any program with Serial.print inside an ISR will fail full stop. This is because the Serial.print statement uses interrupts and will not return until the interrupt has been triggered which it can't do if it is called inside an ISR because the interrupts are disabled.
oh okey 
but anyway. the result is, that, if INT1 happens while you are in ISR0, then ISR1 will happen as soon as ISR0 is done.
thanks allot for the help