dub@pur-phy.UUCP (02/19/87)
*** I would like to be able to use a hardware interrupt (like IRQ5) to signal our IBM PC-AT to perform an interrupt handling routine (this would involve reading data from an external device, doing some manipulation and then storing it away.) The interrupt will be generated by a timing circuit. My problem is how to correctly write the interrupt handling routine in Micorsoft C (latest version). I have been able to redirect the interrupt call to my handler function and even get the handler to work. Alas, returning from the handler is deadly. Is there anyone out thar who has written some software to handle interrupts already that can help me out? Reply via e-mail please. Dwight Bartholomew UUCP:{ihnp4,decvax,seismo,inuxc,sequent,uiucdcs }!pur-ee!pur-phy!galileo!dub {decwrl,hplabs,icase,psuvax1,siemens,ucbvax}|purdue!pur-phy!galileo!dub ARPA: dub@newton.physics.purdue.edu
madd@bucsb.bu.edu.UUCP (02/21/87)
In article <2142@pur-phy.UUCP> dub@pur-phy.UUCP (Dwight) writes: >*** > > I would like to be able to use a hardware interrupt >(like IRQ5) to signal our IBM PC-AT to perform an >interrupt handling routine [...] > My problem is how to correctly write the interrupt >handling routine in Micorsoft C (latest version). >I have been able to redirect the interrupt call to my >handler function and even get the handler to work. Alas, >returning from the handler is deadly. > Is there anyone out thar who has written some >software to handle interrupts already that can help >me out? > Reply via e-mail please. > I'm interested in anything anyone knows about handling interrupts in just about any language except BASIC. Specifically, I need info on the COM interrupts -- what needs to be done to get a routine to handle I/O through COM interrupts? Help? %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% - Jim Frost * The Madd Hacker - UUCP: ..!harvard!bu-cs!bucsb!madd | ARPANET: madd@bucsb.bu.edu CSNET: madd%bucsb@bu-cs | BITNET: cscc71c@bostonu -------------------------------+---+------------------------------------ "Oh beer, oh beer." -- Me | [=(BEER) <- Bud the Beer (cheers!)
backman@interlan.UUCP (02/25/87)
>In article <2142@pur-phy.UUCP> dub@pur-phy.UUCP (Dwight) writes: >> I would like to be able to use a hardware interrupt >>(like IRQ5) to signal our IBM PC-AT to perform an >>interrupt handling routine >> Is there anyone out thar who has written some >>software to handle interrupts already that can help >>me out? > >I'm interested in anything anyone knows about handling interrupts in >just about any language except BASIC. Specifically, I need info on >the COM interrupts -- what needs to be done to get a routine to handle >I/O through COM interrupts? Help? I have written at least half a dozen DOS interrupt handlers, mostly communication oriented. A few years ago, I went through the "I'll do it all in C" phase of programming. I got over it and went back to writing interrupt handlers in assembly. My current approach uses Microsoft Macro Assembler Version 4.0 and Microsoft C, Version 4.0. A brief description of an interrupt handler follows: I place a vector to an assembly interrupt handler in the BIOS vector table. This assembly handler is real simple, it keeps interrupts off long enough to save all registers, place the Microsoft C DS into DS and replace the stack with one of my own with SS the same as DS. At this point, my environment is set up so that I can call a C routine. Before turning on interrupts I capture whatever I need from the interrupt routine and shove it somewhere safe in my Microsoft DS. For instance if I'm in a NETBIOS POST routine I shove ES:BX onto a queue that can be accessed in C. If I'm doing synchronous comms., I grab some Z8530 registers and put them on queues, if I'm doing Ethernet I save some 82586 info. End result... I've got an environ- ment that is C compatable set up, I've got my interrupt information in a safe place that can be accessed from C. At this point I can turn on interrupts, perform the EOI to the 8259 and call a C routine to do the interrupt handling. My C routine can now process the data captured by the interrupt. If its a NETBIOS NCB, get the pointer to the NCB from the queue that it has been saved on, and access the fields within the NCB. This C routine is running on a non-interrupt basis, since we have issued an end of interrupt and re-enabled interrupts. When the C routine is finished, it returns to the assembly handler which restores all registers and does the IRET. This architecture is based on a fast interrupt handler setting up and environment that a slower interrupt consumer can user. The handler (assembler) does the hardware housekeeping, while the consumer (C) does the actual data processing. Warning - this architecture works provided you protect against re-entrancy, a second interrupt occuring before the first is completely processed. This can be easily handled through semaphores and queues. Yes I know that this is not real portable, nor will it be ADOS compatable. However, it allows me the control needed to capture and process real-time interrupts safely without fear of missing a critical interrupt. When Microsoft comes out with a means to handle an interrupt through signals to C code (ADOS?) I will be the first to change, until then assembly sems th safst way. Larry Backman Micom - Interlan 617-263-9929 x291 ulowell mit-eddie !interlan!backman ihnp4