Test Parallax Mouse vs. PS/2 Spec
coryco2
Posts: 107
I was experimenting with the Test Parallax Mouse object, and wanted to have it return the mouse x/y values for any given moment, instead of incrementing/decrementing the value for each. I thought this could be done by simply changing the add operators to variable assignment operators:
The PS/2 mouse spec indicates an x/y movement range from -255 to 255 utilizing a byte for each and a third byte containing a sign and overflow bit for each. But I am seeing returns values well outside that range however. Does anyone know why this is? Is Test Mouse not using the PS/2 spec, and if not, how are the data packets from the mouse being interpreted?
PUB MouseDisplay | mousex, mousey, mousez, mousebtns mouse.start(24, 25) ' Start mouse debug.start(31, 30, 0, 57600) ' Start serial connection waitcnt(clkfreq + cnt) ' Wait 1 s before starting ' Display static text. debug.str(String(CLS, "Mouse", CR, "x = ", CR, "y = ", CR, "scroll = ", CR, "CRL", HOME)) repeat { mousex += mouse.delta_x ' Get mouse data (original) mousey += mouse.delta_y mousez += mouse.delta_z mousebtns := mouse.buttons } mousexread := mouse.delta_x ' Get mouse data (altered) mousex := mouse.delta_x mousey := mouse.delta_y mousez += mouse.delta_z mousebtns := mouse.buttons debug.str(string(CRSRXY, 4, 1)) ' Display mouse data debug.dec(mousex) debug.str(string(CLREOL, CRSRXY, 4, 2)) debug.dec(mousey) debug.str(string(CLREOL, CRSRXY, 9, 3)) debug.dec(mousez) debug.str(string(CLREOL, CR, CR)) debug.bin(mouse.buttons, 5) waitcnt(clkfreq/20 + cnt)
The PS/2 mouse spec indicates an x/y movement range from -255 to 255 utilizing a byte for each and a third byte containing a sign and overflow bit for each. But I am seeing returns values well outside that range however. Does anyone know why this is? Is Test Mouse not using the PS/2 spec, and if not, how are the data packets from the mouse being interpreted?
Comments
I adapted the code (adding a couple of local variables for the mousereads) to capture the max delta values returned to test it for sure; they do exceed 255:
Any thoughts?
There is also a bound_limits method which appears to set the max/min x,y, and z.
http://www.parallax.com/sites/default/files/downloads/28060-PS2-Adapter-v1.0.pdf
So the delta_x and delta_y methods are giving the change in the values between calls of those methods then; and not the x and y movement bytes the mouse is reporting?
I'm not proficient in assembly, but it looks like the x and y received movement bytes are being immediately added to their previous values. How could I retrieve just the raw bytes received from the mouse?
That would be the absolute values suggested by Duane Degn in post #4.
You could roll up your sleeves and study mouse.spin. I guarantee it will help your assembly proficiency.
If you told us more about what you're trying to do, we might be able to help you better.
I agree with your assessment of the PASM code.
As Mike G. suggests, this could be a good time to try a bit of PASM yourself.
To catch the raw values and write them to the hub. I added a few lines to the PASM indicating where I think you'd want to write data to the hub.
Besides the delta x and y values, I also included a "readCount" variable so the parent object could know when new information was read and how many reads had occurred.
There's a big problem doing it this way though. Your Spin loop is going to miss a bunch of these delta values.
If you were to monitor the readCount value, this would be jumping in by large amounts. There would be many delta values you'd miss.
Here's what the output looks like:
When I tried this modified version I noticed the readCount amount only changed when the mouse was moved. Apparently the code only writes to the hub when there's new data to write. When the mouse data does change, it changes too fast for Spin to keep up with. I think this is one reason the raw delta information isn't normally written to the hub. The information changes too fast to be useful to code running in Spin.
add _y,data
and likewise for _x and just use the existing delta method calls to get the values. Does that seem reasonable?
It depends on what you are trying to do.
The code attached to post #9 lets you access the raw delta amounts but these amounts change so fast they don't do you much good in Spin.
This is exactly what the demo application does.
The PS2 movement data packet returns the relative offset in position from the previous packet. It does NOT return an absolute X/Y values alluded to in your original post. The mouse has no idea if it is on your forehead or mouse pad.
Is there any more verbose annotation or just a written explanation available for how the Mouse object works? It's pretty slow going for me trying to decode what's going on. So far, this is what I think is happening:
I kind of see how "entry" is setting up a port to coincide with the dpin and cpin values passed from Start, but from there are steps where I can decode what the PASM is doing, I just can't quite grasp why. Could anyone please shed a little light for me overall on what is going on in this driver? Thanks.