gt3070b@prism.gatech.EDU (Jeff Watkins) (09/09/90)
Well, I have been assigned the jolly task of writing a device driver for a piece of hardware that we have. The fun and interesting part of all this is that I had planned to simply poll this hardware every 8ms and handle the data in a big loop. This way I could write the routines as part of a DLL and that would be that. Now if you are quick, you'll notice the problem. A timer event has a maximum resolution of 54ms. There is no way to poll the card quickly enough. That means that I must enable the hardware interrupt that the card generates and trap that. THIS IS THE PROBLEM! How does one trap a hardware interrupt in Windows? I really am in a bind until I can do this, so any help is appreciated. If sample source code is available that would be great... thanks in advance... jeff -- Jeff Watkins gt3070b@prism.gatech.edu Convergent Media Systems (404) 315-0105 voice (404) 315-0231 data "I speak for no-one. AND NO-ONE SPEAKS FOR ME... oh, yes, _dear_...I gotta go..."
roger@bjcong.bj.co.uk (ROGER JAMES) (09/10/90)
In article <13464@hydra.gatech.EDU> gt3070b@prism.gatech.EDU (Jeff Watkins) writes: >Well, I have been assigned the jolly task of writing a device driver for a >piece of hardware that we have. The fun and interesting part of all this is >that I had planned to simply poll this hardware every 8ms and handle the data >in a big loop. This way I could write the routines as part of a DLL and that >would be that. > >How does one trap a hardware interrupt in Windows? I really am in a bind until > If you only need to drive the device from windows, I suggest the following. 1. Make sure the interrupt is masked off before going into windows. (Write a small prog to do this.) 2. Write your service routine as a DLL. 3. Make sure your service routine has fixed code and data segments. 4. If you are going to run in 386 enhanced mode make sure you GlobalSegLock all code and data that the service routine might use. (This stops page faults at interrupt time.) 5. Grab the interrupt vector and unmask the interrupt from inside the DLL. Windows will intercept the DOS calls that do this and will correctly virtualise the interrupt. The penalty will be a delay in servicing the interrupt if a virtual 8086 machine is active when the interrupt occurs. 6. Remember to release and mask the interrupt before your DLL is unloaded or you will have problems. 7. If you cant live with the delay then either write the whole lot as a tsr, load it before windows and communicate with it via a software interrupt (remember that you cant use the segment registers in the soft int). Or do it the right by using the services provided by the DPMI (spec available from Intel). I think thats about it, but the usual disclaimers apply. If you havent had a nervous breakdown yet, you will have by the time you get it working :-). -- roger@bj.co.uk (UK only) roger@boldon-james-limited.co.uk (Internet) ..!mcsun!ukc!pyrltd!bjcong!roger