Joystick to mouse

I suspect that may not be possible at all. The PS/2 mouse port is not just some hardware port, it also implies a predefined communication protocol, which I'm rather sure doesn't include any support for more than two directions of motion data.

Ever noticed that all those multi-axis joysticks out there are either connected to the "game port", or, if they're more recent, to the USB? I would guess the reason for that (besides that there's usually already an actual mouse connected to the only PS/2 port) is that it couldn't be done otherwise.

--
Hans-Bernhard Broeker (broeker@physik.rwth-aachen.de)
Even if all the snow were burnt, ashes would remain.

The comm protocol is well defined and can be found with google, even code examples. But the biggest problem is that the mouse protocol only provides incremental information (x-ticks up or down, y ticks left or right), while the joystick provides absolute values. This is very hard to convert without 'drift' problems.

Meindert

I'm thinking that the OP could "calibrate" the joystick so that the Atmel knows where the center position is. Then he could generate that mouse move/click messages based upon how far from center the handle was positioned. He would still send relative moves, but they could be scaled based upon how far the stick is pushed. IOW, the farther the stick is pushed from center, the more numerous the mouse move messages equating to a faster moving mouse. I don't see any problem with getting that to work. Of course I would use a PIC instead. ;-)

michael brown

Try this out, pertty detailed explanation of how the mouse creates describes it's change in position to the PC:

Here's an explanation of the electrical signals and mechanical construstion of the PS/2 interface:

I assume, when you say analog(ue) :), you would like to have the speed of the cursor dependant on how far the joystick is deflected. Simply send positon updates faster as the stick is deflected more, see the links above for more detail.

-Jim

Hi Anthony (or is it Michael),

There are two options. I currently have a three axis analogue joystick which needs a three channel ADC to interface and I was thinking along the same lines as you. The Z-axis (rotation) would translate to the wheel on a mouse for scrolling.

The second option is to use a digital joystick and translate the length of time that it is held in any direction to an increase in movement speed.

I would go with you on the PIC if I was writing in assembler but I'll probably do in C for the AVR as I have the Imagecraft tools.

John

It's actually michael, the Anthony thing is a bit of a joke.

I don't see why that couldn't be done. As for the Z axis, I personally might prefer using one of the extra buttons and moving the stick back and forth to do the wheel action, but that is just me. That's the great thing about using the microcontroller electronic "glue", you get to make things work exactly the way you personally want, instead of in some one size fits all mentality. ;-)

This too is quite possible, you could use something a simple as a hat switch type stick, like in an Atari.

That's fine, I've done some C on the 8052 types and it was quite fun. I've never done any C on a PIC because I just don't have the tools, so I only use assembler. I've always been more of an assembly language kinda guy anyway. The important thing is to not let others discourage you.

I've never "talked" to a PS-2 mouse port before, but I have hooked up a PC keyboard to a micro and successfully received scan codes from it. It's been a while since I did that, but IIRC it's an I2C type interface and quite easy to use.

michael

I think two thing spoil the fun: potmeter/AD noise and mechanical tolerance. Can you quarantee that the potmeter produces exactly the same resistance variation when moved from one mechanical stop to the other? I think not.

Meindert

port.

without

If the joystick is sprung to return to the center then the movement distance can give acceleration, with the mouse pointer not moving when the joystick is in the center. No problem with calibration then. Sounds reasonably simple to me.

Ralph

I don't think that matters. It can be handled in software very easily, just like windos does it with a laptop keyboard/button mouse. All he has to do is allow for some slop in the system. By going thru a calibration procedure he can establish the range of readings he will see and also establish the center point reading. By simply experimenting he can establish how much lee-way he needs to allow for centering stability so that mouse creep can be eliminated. The little button type mouse pointers in laptop keyboards are constantly reestablishing their center point. If you hold a slight even pressure in one direction for more than about five seconds, the mouse will stop moving and think that is the center (finger off) position. If you remove your finger, the mouse will creep off in the opposite direction at a constant speed, it will then stop in about five seconds or so. The OP can simply emulate this behavior by analyizing his readings carefully and "guessing" when the stick is released by "noticing" that the readings aren't varying (by much).

michael

distance

Ah, never thought about that. You can indeed use the joystick to give speed instead of absolute position.

Meindert

I've been trying to write software which handles PS/2 signals, and can only suggest that you do not try to do that yourself. The PS/2 protocol is a big mistake, very impractical to use, and what's more: very difficult to find what all the codes sent between PC and peripheral mean (I found a lot of commands that weren't explained anywhere but were understood perfectly by the devices). I would rather spend time on building an interface betwees a joystick and a PS/2 mouse interface, unless you like programming just for the programming. And if you do: do it either in asembly or in very effective C.

Aart

Anth>

very

Are you referring to a keyboard and it's associated scan codes? I found the electrical interface to be simple and as I recall it was something like I2C or SPI. Now as to some of the actual data going back and forth, that might be cryptic and specific to the device. For example keyboards can usually be "told" to return scan codes using one of three different systems. Scan codes are really cryptic IMO, but not impossible. I suggest that if you are having trouble with device driving, see if Linux has some "example" code for you. ;-)

Since I'm not officially an engineer by trade, nearly all of my projects are just for the learning experience and to see if I can make it work. Right now I'm working on a line powered caller-id display that decodes the modem tones using only software on a PIC. I'm having some success, but I haven't figured out how to ignore the idle train that precedes the data, but I'll get it to work sooner or later.

michael

how

If you did not get the answer you wanted and still want to use PS/2 you should get a document called "PS/2 Mouse Architecture Types 1 and 2" from IBM. It describes this interface and protocol in detail.

I used it a few years ago to implement an IR remote control to PS/2 for a DLP video projector.

If you don't know where to ask, I'll see if I can find it for you.

There are also some information at

Thomas

Hi Thomas,

Unfortunately I have to use PS/2 as the environment in which our machines are used has a lot of aggressive chemicals and mice and touchscreens are out. So a sealed joystick plugged in to a PS/2 mouse port is the only way forward.

I found some good stuff at

and a couple of other pages on the same site. However I would like to get the IBM info too if you have a link.

I've now settled in the Atmel ATtiny26 as it fits the bill exactly and I have the Imagecraft C tools. I never did fancy assembler on the AVR as the instruction set is far too bloated. AVR's are superb chips but I think they gained the 'RISC' title by starting with several hundred instructions and throwing away the ones they couldn't figure out how to implement!!

John

Is a waterproof touchscreen an option? They are used on boats where they are constantly exposed to salt water.

Meindert

I see how that environment would rule out normal ball-and-roller mice. Optical mice or touchscreens, however, shouldn't be any harder to seal than joysticks.

But I don't at all see how that environment would dictate PS/2 as the port to be used. Are there really no other ports on those machines? No USB, no anything?

If you do stick with your joystick plan, this looks like you'll eventually be re-inventing the "Trackpoint" device found on many laptops, more commonly referred to as the "eraserhead" because it looks like someone rammed a pencil into the keyboard so brutally that only the eraser on the back end of it is still visible. At least it should serve as an example of how to translate stick movement into cursor movements. If you're lucky, maybe you can even re-use their existing drivers.

--
Hans-Bernhard Broeker (broeker@physik.rwth-aachen.de)
Even if all the snow were burnt, ashes would remain.

I wonder why you would even use a microcontroller at all... Just get a cheap mouse, remove the case, desolder the opto-interrupters, mount the wheels where the joystick pots go, mount the opto-interrupters where the wheels intersect, and then set the sensitivity/acceleration levels up on the mouse driver. Remove the buttons from the mouse board, connect you your sealed buttons.

The feel might be a bit odd, and there is no "joystick position = screen position", but is that a requirement?

Hi,

That's a good idea, I'll into the possibility of a joystick with USB.

John

wrote:

. . .

. . .