shearer@cis.udel.edu (Rob Shearer) (10/10/90)
I have hooked the INT 8 interrupt (IRQ 0, Clock_Tick Interrupt) on my PC. Normaly I want the routine to happen on a set schedule.. but there are times that I want the INT 8 routines to occur out of sync and I call it from another part of my code with a geninterrupt(8); (I take care of the REAL Clock no matter what...). Can you Gurus inform me how to detect if the interrupt was hardware or software driven?? It is all probably in the PIC... but ALL my reference books basically inform me that there IS such a think as the PIC. (Before anyone tells me to hook INT 1C instead.. I NEED INT 8, that is why I hooked it... and if I can differentiate between a hw and sw interrupt then life is fantastic!) Thanks in Advance... Robb Shearer shearer@sol.cis.udel.edu
Bob.Stout@p6.f506.n106.z1.fidonet.org (Bob Stout) (10/10/90)
The minute you do a geninterupt(8), you screw up your machine's time. Although AT and higher class PC's include a battery backed real-time clock, the only time it's used is when the machine's booted and its time is loaded into DOS. Thereafter, DOS time (i.e. the TIME command, all file time/date stamps, etc.) are based on the time as maintained by Int 8. Start throwing in spurious interrupts (bad idea anyway since Int 8 is a hardware interrupt) and you mess up all sorts of things. Int 1Ch is provided for just this purpose - a software interrupt triggered off the Int 8 hardware interrupt. Generating asynchronous Int 8's means your system will also have to figure out why your Int 8 handler is sending out spurious EOI commands to the timer chip when it hasn't previously signalled an interrupt to the CPU via the interrupt controller chip.
news@heitis1.uucp (News Administrator) (10/17/90)
In article <32905@nigel.ee.udel.edu> shearer@cis.udel.edu (Rob Shearer) writes: >of the REAL Clock no matter what...). Can you Gurus inform me how to >detect if the interrupt was hardware or software driven?? It is all I had to work around this same problem once upon a time. My solution was to actually use 2 routines. I called a non-interrupt specific routine from the actual interrupt routine. This way, all interrupt specific tricks could be handled for me. And if I decided to call the routine manually, I simply called the non-interrupt machine from elsewhere in my code. The only problem with this method is if you are in a very timing critical portion of the code, in which case I would suggest having parallel routines for the same function, its not elegant, but it will work. brian