As of today my 18F4520 is able to receive from / transmit to an optical mouse as per the PS/2 protocol.
For the moment, the code, writen in Assembler, just transmits, receives (and displays).
My (unorganized) comments:
AFAIK only reference available to check my micro against to, were the CLK + DATA signals from the mouse. To start with something, my sole chance was to catch the actual initialization where the mouse issues a predictable / known code: AA 00.
First I did was to show through an additional pin, how my software detected the mouse's CLK. Once I knew that, I spent a whole afternoon trying to understand what was going wrong until I realized the START pulse from the mouse, was being largely missed by some millions of microseconds.
To overcome that, I decided to power up the mouse well after the snoopying software was up and running and then ensure I had a stable IDLE condition to now yes, try to catch the initialization.
The additional-pin trick, allowed, by creating a narrow pulse inside every DATA-pulse to faithfuly confirm the START was missing from the screen.
Tried two mice up to now. In the WRAP mode, one sends back every single code I transmit. The other, every three or four bytes OK, sends FE and later FC. Standards? What standards?
It took me a while to understand who does what and when. Once I got clear that the clock was providing the pulses for all the reads and writes, drawing the flow diagram was easy.
One stupid mistake had me several hours trying to understand why my display was showing 170 and not AA.
I know I wrote a too long post but I am happy with the start. So, off now for lunch and a glass of good Malbec.
For the moment, the code, writen in Assembler, just transmits, receives (and displays).
My (unorganized) comments:
AFAIK only reference available to check my micro against to, were the CLK + DATA signals from the mouse. To start with something, my sole chance was to catch the actual initialization where the mouse issues a predictable / known code: AA 00.
First I did was to show through an additional pin, how my software detected the mouse's CLK. Once I knew that, I spent a whole afternoon trying to understand what was going wrong until I realized the START pulse from the mouse, was being largely missed by some millions of microseconds.
To overcome that, I decided to power up the mouse well after the snoopying software was up and running and then ensure I had a stable IDLE condition to now yes, try to catch the initialization.
The additional-pin trick, allowed, by creating a narrow pulse inside every DATA-pulse to faithfuly confirm the START was missing from the screen.
Tried two mice up to now. In the WRAP mode, one sends back every single code I transmit. The other, every three or four bytes OK, sends FE and later FC. Standards? What standards?
It took me a while to understand who does what and when. Once I got clear that the clock was providing the pulses for all the reads and writes, drawing the flow diagram was easy.
One stupid mistake had me several hours trying to understand why my display was showing 170 and not AA.
I know I wrote a too long post but I am happy with the start. So, off now for lunch and a glass of good Malbec.
