Chris Giese in your code of serial mouse driver u have cleared "dangling interrupts" while initialising the uart chip.
u have also waited for 100ms before turining power back on to mouse.
can u explain why these steps are neccassary .
question about serial mouse driver of Chris Giese
-
Chris Giese
Re:question about serial mouse driver of Chris Giese
I admit it: the "dangling interrupts" code is probably voodoo :)
As for the delay...
The mouse is powered by the serial port handshaking outputs (RTS and DTR). I shut off those lines in serial_init(), then wait 100 ms and turn them back on in main(). When the mouse is powered, it sends one or more bytes that identify it: 'M' for 2-button mouse or 'M3' for 3-button mouse. New serial mice also send a PnP identifier.
The 100 ms delay is needed in case RTS and DTR (and therefore the mouse) are already on when you run SERIAL.EXE. This delay can probably be omitted if you don't care about identifying the mouse type. serial_mouse() will still work properly without this identification code.
I made a slight change to the serial_mouse() routine to make it more correct. Also, the demo code has a new home: http://my.execpc.com/~geezer/osd/serial/
As for the delay...
The mouse is powered by the serial port handshaking outputs (RTS and DTR). I shut off those lines in serial_init(), then wait 100 ms and turn them back on in main(). When the mouse is powered, it sends one or more bytes that identify it: 'M' for 2-button mouse or 'M3' for 3-button mouse. New serial mice also send a PnP identifier.
The 100 ms delay is needed in case RTS and DTR (and therefore the mouse) are already on when you run SERIAL.EXE. This delay can probably be omitted if you don't care about identifying the mouse type. serial_mouse() will still work properly without this identification code.
I made a slight change to the serial_mouse() routine to make it more correct. Also, the demo code has a new home: http://my.execpc.com/~geezer/osd/serial/