Can External Interrupt Program be too long to be able to work properly?

Question

I have a question to ask regarding about external interrupt program. If i'm using INT1(External Interrupt 1 set to Falling Edge) of DS89C450 and my program of the external interrupt is very long, will it function properly? or will there be any problem with it? I'm using Keil embedded C.

Answer 1

Another way to do this without an RTOS is to use event flags and state machines. Your program can be diagrammed into discrete states that transition when a particular event is called. For example, in this diagram I found using google:

A button click is an event; something that can be triggered from your INT1 interrupt for example. You would then put the following loop in the foreground:

#define STATE_POWER_OFF   1
#define STATE_POWER_ON    2

#define EVENT_BUTTON_CLICK  0x01

volatile unsigned char bEventFlags = 0;
unsigned char bState = STATE_POWER_OFF;

unsigned char getEventFlags( void ) ;

int main(void)
{
    for(;;)
    {
        unsigned char flags = getEventflags() ;

        if (flags != 0)
        { 
           switch (bState)
           {
                case STATE_POWER_OFF:
                    if (flags & EVENT_BUTTON_CLICK)
                    {
                        // Do something
                        bState = STATE_POWER_ON;
                    }
                    break;

                case STATE_POWER_ON:
                    if (flags & EVENT_BUTTON_CLICK)
                    {
                        // Do something
                        bState = STATE_POWER_OFF;
                    }
                    break;
            }
        }
    }
}

unsigned char getEventFlags( void )
{
    unsigned char flags = 0 ;

    // Get copy of flags in critical section and clear down
    _disable_interrupts() ;
    flags = bEventFlags ;
    bEventFlags = 0 ;
    _enable_interrupts ;

    return flags ;
}

And your ISR would then be very short:

void INT1_ISR(void)
{
    bEventFlags |= EVENT_BUTTON_CLICK;
}

Answer 2

In the sense that the interrupt handler will run to completion regardless, no it cannot be "too long". However while an interrupt is being processed, depending on the interrupt architecture, either nothing else will run, or only higher-priority interrupts will run. The consequence of this is that you may miss your real-time deadlines.

You may even miss subsequent interrupts from the interrupt source being handled. On some architectures if the interrupt is not disabled during handling, that could cause re-entrancy, which may cause a problem if the handler is not re-entrant or there is insufficient stack.

So the answer to the question of will it work will depend entirely on your application, what real-time deadlines it has and what other interrupt sources may occur. The answer to whether such an interrupt handler is good design is certainly no. Even if it works now, it will not be generally useful in other applications and may break under maintenance.

A better solution would be to deploy a simple RTOS scheduler kernel on the part, and have the interrupt handler signal a task at an appropriate priority level. The MCS-51 architecture can efficiently implement a scheduler due to its 8 duplicate register banks - for up-to eight tasks, a context switch can be very fast.