[En-Nut-Discussion] Interrupt disable time

Dave Smart SmartFamily at mchsi.com
Fri Dec 13 14:40:15 CET 2002


Hello,

I'm creating a device driver that needs to sample a couple of inputs
consistently within about 15 usec of assertion of the interrupt. My ISR
processing normally only requires about 3 to 4 uSec. I have my driver
working reasonably well, but there are a couple of issues I'm trying to
resolve.

First, between the hardware assertion and my ISR activation, I see a
consistent 13 uSec delay. I believe this is the preamble and setup for the
driver (the top piece of which is below and has some overhead).

Are there known optimizations to reduce this amount?


Second, and more importantly, is that occasionally (too frequently for my
system), the ISR appears to be blocked, probably by another interrupt, and
since I'm using Ethernet, I'm guessing that might be one of the culprits.

What is the maximum block time of known interrupts?
I see that interrupts must be explicitly re-enable interrupts to allow for
nested interrupts. Has anyone experimented with re-enabling interrupts
within the device drivers to allow for nested ISR's, and thereby supporting
faster response times for the more critical drivers?


Oh, my couple of issues turned into a 3rd question. Using the GNU compiler,
is there an option for the list file to contain mixed C and Assembly? This
would aid me in learning the AVR instruction set a little quicker.


thanks all,
Dave Smart


Code Snippet:

static void MyDevInterrupt(void *arg)
	{
	NUTDEVICE *dev = (NUTDEVICE *)arg;
	IFSTREAM *ifs = dev->dev_icb;
	KYBDDCB *dcb;
	static unsigned char data;

	DDRD |= 0x80;		// Debug output PD.4
	PORTD |= 0x80;	// Debug Set it high visible at 15 usec after h/w signal
	...			// Do stuff
	if (Conditions_are_right)
		NutEventPostAsync(&dcb->dcb_rx_rdy);
	...
	PORTD &= ~0x80;	// Debug Set it low seen about 4 usec after set high
	}			// ISR exit not visible







More information about the En-Nut-Discussion mailing list