Date: Mon, 18 May 1998 16:10:04 +0300 (IDT)
From: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
To: Joseph Kaplan <j DOT a DOT kaplan AT larc DOT nasa DOT gov>
cc: djgpp AT delorie DOT com
Subject: Re: hardware interrupts
In-Reply-To: <v03130300b185c83566a2@[128.155.2.168]>
Message-ID: <Pine.SUN.3.91.980518160231.18465B-100000@is>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Precedence: bulk


On Mon, 18 May 1998, Joseph Kaplan wrote:

> I have put a print statement in the interrupt handler to show this.

Regardles of whether this is or isn't the cause of your problem, using 
print statements in an interrupt handler is a VERY bad idea.  Most print 
functions call DOS, which is an absolute no-no in an interrupt handler.  
If you do, sooner or later your program will crash

If you must print something, use direct screen (aka conio) functions, and 
also avoid cprintf, which might call malloc.  The safest way is to create 
a string in a buffer and then call cputs to write it to VRAM.

> void CondorArinc429Impl::protectedInterruptHandler(...)
> {
>   cout << "Interrupt Handler" << endl;
>   determineReceiver();
>   outportb(interrupt_control_port,interrupt_acknowledge);
> }

I don't see here where do you send the EOI byte to the PIC, unless the 
last statement above does it.  If you don't send EOI, you won't get more 
than a single interrupt.

> >Second, the code and data of the handler need to be locked.
> >
> I didn't lock any of the code or the data because I am using
> CWSDPR0 as my memory manager.  I thought that was only
> necessary if you had a paging memory manager.

That is correct, you don't need to lock with CWSDPR0.