Searching \ for 'PC (DOS) IRQ Clearing' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/index.htm?key=dos+irq+clearing
Search entire site for: 'PC (DOS) IRQ Clearing'.

Truncated match.
PICList Thread
'PC (DOS) IRQ Clearing'
1998\12\23@112515 by Andy Kunz

flavicon
face
I'm having a problem with clearing an IRQ I think in a DOS app.

Do you have any example code of how to handle when I get an IRQ > 7?

       if (CommPort[PORTNUM].IRQ >= 8)
               outp (0xA0, 0x20);
       outp (0x20, 0x20);

This seems to be working fine for interrupts < 8.  It's 8 and greater
that's killing my machine - locks it up BUT GOOD!

Thanks.

Andy
==================================================================
Andy Kunz - Statistical Research, Inc. - Westfield, New Jersey USA
==================================================================

1998\12\23@114258 by WF AUTOMACAO

flavicon
face
Andy Kunz wrote:
>
> I'm having a problem with clearing an IRQ I think in a DOS app.
>
> Do you have any example code of how to handle when I get an IRQ > 7?
>
>         if (CommPort[PORTNUM].IRQ >= 8)
>                 outp (0xA0, 0x20);
>         outp (0x20, 0x20);
>
> This seems to be working fine for interrupts < 8.  It's 8 and greater
> that's killing my machine - locks it up BUT GOOD!
>
> Thanks.
>
> Andy
> ==================================================================
> Andy Kunz - Statistical Research, Inc. - Westfield, New Jersey USA
> ==================================================================

What do intend to disable? on PC..

Miguel

1998\12\23@114504 by Peter L. Peres

picon face
On Wed, 23 Dec 1998, Andy Kunz wrote:

> I'm having a problem with clearing an IRQ I think in a DOS app.
>
> Do you have any example code of how to handle when I get an IRQ > 7?
>
>         if (CommPort[PORTNUM].IRQ >= 8)
>                 outp (0xA0, 0x20);
>         outp (0x20, 0x20);
>
> This seems to be working fine for interrupts < 8.  It's 8 and greater
> that's killing my machine - locks it up BUT GOOD!

If I remember well, you need to reset the 2nd (upper) controller too, and
before the 1st one if I'm not wrong.

I'll look it up in my books tonight.

hope this helps,

Peter

1998\12\23@124212 by Andy Kunz

flavicon
face
>What do intend to disable? on PC..

Not disable, acknowledge so that the device can generate another IRQ.  That
code was from within the ISR.

Andy


==================================================================
Andy Kunz - Statistical Research, Inc. - Westfield, New Jersey USA
==================================================================

1998\12\23@124216 by Andy Kunz

flavicon
face
Peter,

The first outp() is supposed to be doing that - that's what scares me!

Thanks.

Andy


At 06:42 PM 12/23/98 +0000, you wrote:
{Quote hidden}

==================================================================
Andy Kunz - Statistical Research, Inc. - Westfield, New Jersey USA
==================================================================

1998\12\23@163025 by steve

flavicon
face
> Do you have any example code of how to handle when I get an IRQ > 7?
>
>         if (CommPort[PORTNUM].IRQ >= 8)
>                 outp (0xA0, 0x20);
>         outp (0x20, 0x20);
>
> This seems to be working fine for interrupts < 8.  It's 8 and greater
> that's killing my machine - locks it up BUT GOOD!

I remember beating my head against the wall for this one.
>From rather vague memory, sending a 0x20 is a general
acknowledge/clear thing. If you using the second PIC (so it's not
OT) you need to explicitly change the appropriate bit.
I think the upshot of it was that if there was another INT pending,
the PIC would clear the highest priority and suddenly you loose the
timer tick or one of those other handy things.

Sorry for the vague answer but it should point you in the right
direction.

Steve.


======================================================
Steve Baldwin                Electronic Product Design
TLA Microsystems Ltd         Microcontroller Specialists
PO Box 15-680, New Lynn      http://www.tla.co.nz
Auckland, New Zealand        ph  +64 9 820-2221
email: spam_OUTstevebTakeThisOuTspamtla.co.nz      fax +64 9 820-1929
======================================================

1998\12\23@170726 by Clyde Smith-Stubbs

flavicon
face
Andy Kunz wrote:

> Do you have any example code of how to handle when I get an IRQ > 7?
>
>
> This seems to be working fine for interrupts < 8.  It's 8 and greater
> that's killing my machine - locks it up BUT GOOD!

Looking back at some code I wrote many years ago to handle interrupts on
a PC, I see that the order of writing the two interrupt controllers
is reversed compared to the above. I know it worked, so give it a go. E.g.

       outp (0x20, 0x20);
       if (CommPort[PORTNUM].IRQ >= 8)
               outp (0xA0, 0x20);

Merry Christmas to All!

--
Clyde Smith-Stubbs               |            HI-TECH Software
Email: .....clydeKILLspamspam@spam@htsoft.com          |          Phone            Fax
WWW:   http://www.htsoft.com/    | USA: (408) 490 2885  (408) 490 2885
PGP:   finger clydespamKILLspamhtsoft.com   | AUS: +61 7 3355 8333 +61 7 3355 8334
---------------------------------------------------------------------------
HI-TECH C: compiling the real world.

1998\12\23@172634 by paulb

flavicon
face
Hello Andy.

> I'm having a problem with clearing an IRQ I think in a DOS app.
> Do you have any example code of how to handle when I get an IRQ > 7?
>         if (CommPort[PORTNUM].IRQ >= 8)
>                 outp (0xA0, 0x20);
>         outp (0x20, 0x20);

 All *I* can say is; this is a thorny question that I've never dared to
address.  I shall be very interested in the answer!

 Are you writing this from scratch, or copying someone's template?
Just as an outside guess, have you tried *not* clearing the secondary
controller?  I have a *funny* notion the BIOS may do that for you.  Or
maybe the primary.
--
 Cheers,
       Paul B.

1998\12\23@173444 by paulb

flavicon
face
Clyde Smith-Stubbs wrote:

> I see that the order of writing the two interrupt controllers
> is reversed compared to the above. I know it worked, so give it a go. E.g.
>
>         outp (0x20, 0x20);
>         if (CommPort[PORTNUM].IRQ >= 8)
>                 outp (0xA0, 0x20);

 Curiously enough, I think that's actually the *same* thing Steve
Baldwin said, but just put slightly differently!
--
 Cheers,
       Paul B.

1998\12\23@193310 by steve

flavicon
face
> > I see that the order of writing the two interrupt controllers
> > is reversed compared to the above. I know it worked, so give it a go. E.g.
> >
> >         outp (0x20, 0x20);
> >         if (CommPort[PORTNUM].IRQ >= 8)
> >                 outp (0xA0, 0x20);
>
>   Curiously enough, I think that's actually the *same* thing Steve
> Baldwin said, but just put slightly differently!

No, it's a different solution but with a similar amount of technical
backup - ie. "This seemed to work"..."I vaguely recall"...etc. :-)

So now you've made me go and look up what I did and why.

   if (slaveController )
   {
       outportb( SEC_IRQ_CTLR, ( commIntNo & 0x07 ) | 0x60 );
       outportb( PRI_IRQ_CTLR, 0x62 );
   }
   else
     outportb( PRI_IRQ_CTLR, ( commIntNo & 0x07 ) | 0x60 );

Sending a 0x20 to the PIC is a non specific EOI and it tells it to
clear the INT at the level currently being serviced.  Sending a 0x6X
is a specific EOI and specifies exactly which INT to clear. The
reason was that this was an embedded (non-DOS) situation and there is
a possibility of someone playing with priorities.
If there are two equal priority interrupts then a non specific EOI
can cause the loss of the second one. In a DOS system they are all
prioritised so it's not really an issue and the 0x20 works fine.

Steve.

======================================================
Steve Baldwin                Electronic Product Design
TLA Microsystems Ltd         Microcontroller Specialists
PO Box 15-680, New Lynn      http://www.tla.co.nz
Auckland, New Zealand        ph  +64 9 820-2221
email: .....stevebKILLspamspam.....tla.co.nz      fax +64 9 820-1929
======================================================

1998\12\24@064943 by paulb

flavicon
face
Steve Baldwin wrote:

> No, it's a different solution but with a similar amount of technical
> backup - ie. "This seemed to work"..."I vaguely recall"...etc. :-)

 No, I suspect it«s likely to be a different solution with the same
effect.  The sending of a non-specific EOI to the secondary controller
may cause it to clear and then re-assert its output IRQ before the
primary is ready to see it (and this assuming the actual calling IRQ has
in fact been cleared).

 If however, the primary is cleared first, it is able to respond to the
second call from the secondary and the subsequent interrupt will be
honoured.
--
 Cheers,
       Paul B.

1998\12\24@120456 by Peter L. Peres

picon face
On Wed, 23 Dec 1998, Andy Kunz wrote:

> Peter,
>
> The first outp() is supposed to be doing that - that's what scares me!

I seem to remember that there was some sort of timing limitation between
the two clears on fast machines ? The IRQ signal propagates slower than
the instructions in older (?) machine's controllers.

Try to insert a delay of a few usec between the two clears.

Do you make sure that the physical IRQ source is turned off before this,
that the IRQ 'off' signal propagates to the controller, and that the
interrupt reaction is set on 'edge' in the BIOS, and that the IRQ is not
shared with anything ? Maybe there is a logic level compatibility problem
between your source and the PC ? (I am guessing here, e.g. LS TTL and
certain HC chips have strange incompatibilities afaik).

I haven't gotten around to open the books last night. Maybe tonight.

afaik a modern Pentium class machine responds fast enough to interrupts to
cause propagation time problems in a slow peripheral's IRQ control
circuits if no delays are used and the interrupt is set to level trigger.

Hope this helps,

Peter

1998\12\28@092104 by Dr. Imre Bartfai

flavicon
face
Hi,

On Wed, 23 Dec 1998, Andy Kunz wrote:

> I'm having a problem with clearing an IRQ I think in a DOS app.
>
> Do you have any example code of how to handle when I get an IRQ > 7?
>
>         if (CommPort[PORTNUM].IRQ >= 8)
>                 outp (0xA0, 0x20);
       else    // would be better here I guess
>         outp (0x20, 0x20);
/* another comment: I always prefer specific EOI command to non-specific
       ones... */

{Quote hidden}

1998\12\28@095608 by Andy Kunz

flavicon
face
WOW, what a collection of (sometimes contradictory) wisdom!

The interrupt source is a PIC which strobes the IRQ output line on the ISA
bus.  I don't have a pin to ack it, so I cheat.

The PC is a Pentium-class machine running 95.

I just need to be able to get out of the interrupt.  If I use my code, the
machine gets swamped on the first interrupt, everything slows down (mouse
movement, etc.) but keeps functioning.  If I try to kill the app, the
machine locks up tight as a drum - only the magic red button will help me!

I'll give it a try - I have all day today to make it work.

Thanks!

Andy

==================================================================
 Andy Kunz - Montana Design - http://www.users.fast.net/~montana
==================================================================

1998\12\28@103648 by Andy Kunz

flavicon
face
>So now you've made me go and look up what I did and why.
>
>    if (slaveController )
>    {
>        outportb( SEC_IRQ_CTLR, ( commIntNo & 0x07 ) | 0x60 );
>        outportb( PRI_IRQ_CTLR, 0x62 );
>    }
>    else
>      outportb( PRI_IRQ_CTLR, ( commIntNo & 0x07 ) | 0x60 );

That looks like a like more sense than what I had.  I'll give it a shot.

Thanks, Steve!

Andy

==================================================================
 Andy Kunz - Montana Design - http://www.users.fast.net/~montana
==================================================================

1998\12\28@103657 by Andy Kunz

flavicon
face
>  No, I suspect it«s likely to be a different solution with the same
>effect.  The sending of a non-specific EOI to the secondary controller
>may cause it to clear and then re-assert its output IRQ before the
>primary is ready to see it (and this assuming the actual calling IRQ has
>in fact been cleared).
>
>  If however, the primary is cleared first, it is able to respond to the
>second call from the secondary and the subsequent interrupt will be
>honoured.

This makes sense, too.

So, to finalize things, when I get it working (drop-dead day is Tuesday)
I'll post the solution here.

Thanks for all the help, guys.

Andy

==================================================================
 Andy Kunz - Montana Design - http://www.users.fast.net/~montana
==================================================================

1998\12\28@105500 by Andy Kunz

flavicon
face
>  Are you writing this from scratch, or copying someone's template?
>Just as an outside guess, have you tried *not* clearing the secondary
>controller?  I have a *funny* notion the BIOS may do that for you.  Or
>maybe the primary.

Actually, I'm working on some code that I started several years ago, then
abandoned to support only low-number IRQs.  Now I'm in need of a generic
any-IRQ routine for a DOS app in Win95, so I tried reviving it.  Now that I
have a great resource (the PIC list) I thought I would try asking.

When I don't clear the secondary controller, nothing works.

Andy

==================================================================
 Andy Kunz - Montana Design - http://www.users.fast.net/~montana
==================================================================

More... (looser matching)
- Last day of these posts
- In 1998 , 1999 only
- Today
- New search...