Mouse input - Can it be done ?

Has anybody interfaced a PS2 mouse or touchpad directly into PICAXE ?.

A colleague of mine has just done it on his A******o.
He just wired up a PS2 mouse, downloaded a chunk of code, and was up and running in few minutes.

So I investigated the possibility of doing similar on a PICAXE.
After a few hours reading up on PS2 protocol it looked like it might be possible.
It would use lots of bit banging, and I'm still not sure if PICAXE would be fast enough.

But then I thought about KBIN. This must use much of the same protocol as a mouse, so a better solution would be to have a similar MOUSIN command added to the language, with a corresponding MOUSSETUP command to initialise the mouse.

This could give the PICAXE features similar to the ( very over-priced ~) PAK-XI.

So RevEd, is this a feature that could be added in the future ?

( My colleague is using the active parts of an optical mouse under his buggy. The intention is to detect tracking errors which wheel rotation counting will miss. It will be interesting to see how he gets on. )

Buzby

I thought the PS2 mouse interface was the same as the keyboard. If it is then maybe the standard PICAXE keyboard feature could be used.

The electrical interface is the same, but the commands are different.

For a mouse there is an initial flurry of two way comms which is used to determine the capabilities of the mouse ( scroll wheel, how many buttons, etc. ), then the host sends commands to tell the mouse how to behave ( streamed or polled ). This is the stuff I envisage would go in MOUSSETUP.

After initialisation the mouse can be polled to get the current values of X, Y, and buttons. This is the purpose of MOUSIN.

KBIN and KBLED must use elements of the PS2 protocol, so it does not seem unreasonable to envisage these new commands.

Having a mouse input to PICAXE opens up a new range of possibilities. There are a lot of mouse-like devices, such as touchpads, joysticks, and trackballs, which use the same protocol.

Have a look here at what I started to look into
http://www.picaxeforum.co.uk/showthread.php?t=13995
PICAXE is too slow to bit bang.

The link in post 1 to AWE has an interesting chip as a possible interface but I did not pursue that further

The topic has come up a few time over the past year without anyone reaching a conclusion (finished published project)

Hi Westie, I saw your post, but as the thread petered out I thought no one had progressed the idea.

Possible methods I've thought of upto now are :

1 - Bit banging, but PICAXE is too slow.

2 - Use the PAK XI chip, but way too expensive.

3 - A raw PIC programmed with custom code, ( some available online ), but I don't want to get involved with PIC programming.

4 - Some kind of hardware Shift Register may be an option worth following.

5 - Ask RevEd to add MOUSE commands to PICAXE BASIC. This certainly looks the best way to do it. No extra chips, and simple syntax for the user.

With the expanded firmware space in the newer chips it should be possible to do this, then we can get away from writing 'drivers' and start using 'devices'.

Cheers,

Buzby.

A 64MHz PICAXE is too slow?

The PS2 clock pulses can vary between 60 and 100 uS per cycle, which is the equivalent of about 16KHz to 10KHz. I don't thing even a 64MHz could do that using a bit bang method.

Trying to use the HSER function has problems because the rate is not constant between different mice, after all, they are using chips with internal oscillators !.

It may be possible to auto-find the correct effective "baud rate", but even then it may vary if the mouse is busy doing different things.

The next problem is parity. The HSERSETUP doesn't allow users to change the parity. It may be possible by POKEing somewhere, but as I said before, I don't want to write a driver, I want to use a device !.

Lego sounds like a possible way to bridge the gap...

Mouse >>> NXT >>> I2C >>> Picaxe ???

http://www.bartneck.de/wp-content/uploads/2009/02/lego-beyond-toys-jansen-small.pdf

I miss Lego build a big tower - smash it - build a big tower..

Wow !. That's a real tour-de-force if ever I saw one !.

He removes the camera from the mouse, leaving behind the electronics which generated the PS2 signals.

Then he uses an A*****o to process the raw camera data into signals suitable for the NXT. ( This is far more complex than decoding PS2, - and it's not using a PICAXE acceptable solution ! )

After that he uses a 3D-Printer to build a new housing for the A*****o and the bits he stripped out of the mouse.

He has not made a PS2-to-NXT convertor, he's made an I2C interfaced LEGO shaped mouse !.

Very impressive, but it's not Speckled Hen.

Thanks for the link anyway, it's good reading.

Cheers,

Buzby

There's always the option of a serial (RS232) mouse. Harder to find these days but there should be a few around in the back of drawers, gathering dust in charity shops, car boot sales, even eBay etc.

Historically, lack of MOUSE support in the PICAXE has probably been two-fold; lack of firmware space plus lack of demand for it. I've noted the thread so I'm sure it will get reconsidered as a future possibility, but as always, no promises.

One current option may be to put a PICAXE ( or two ) in the mouse, read the encoders and create a means of talking to a PICAXE; maybe even serial. I haven't really studied mice so that may not be that practical but could be on a PICAXE with two hardware 16-bit counters and some SFR poking. Agreed, it's not as simple or as flexible as some other options.

Rather ironically my 'mouse needs' are the opposite; wanting to take an RS232 trackball and turn that into a PC-usable PS/2 or USB mouse device. USB-to-Serial works, but Windows doesn't pick it up as the (serial) primary pointer device.

Encoder wheels?

Actually all my mice have optical sensors or magnetic sensors.

Hi Hippy,

After trying a few tests with a frequency generator and a 20X2, I have confirmed that even a 64MHz PICAXE is too slow to handle the PS2 protocol.The fastest I could read the clock line was about 3KHz, nowhere near the 16KHz needed.

Regarding the lack of mouse support in PICAXE, I fully understand the historic restraints. Even with the latest PIC chips the overhead involved in continuously monitoring the lines and updating the mouse related PICAXE variables may interfere too much with 'normal' PICAXE behaviour.

Maybe a better solution would be for RevEd to produce a PS2 coprocessor. This way any PS2 device could be interfaced without straining the main PICAXE.

A PS2 interface for PICAXE would open up a whole new range of ideas. A joystick control for a buggy, a trackpad for scrolling around an LCD, etc.

It would be interesting to take a poll to see if there would be any demand for such a product.

--

Regarding your RS232 trackball to PC problem, if you can hack the trackball you could replace the electronics with the gubbins from a PS2 mouse.

Either wire the trackball rotation sensors in place of the mouse ball sensors, or, more interesting, put the PCB from an optical mouse in close proximity to the ball. This option means you can leave all the existing RS232 and sensors intact, and end up with a track ball that talks RS232 and PS2 at the same time !.

If you can't hack the ball then you need to build an RS232 to PS2 interface. Discovering the RS232 protocol should be easy, and making a PICAXE work as a PS2 device is much easier than making it a PS2 host. You can do it with a simple 8x1 FIFO. It might even be possible to do it with HSPI and no extra chips, it depends on how fast you can get the bits out.

Cheers,

Buzby

Agreed, mouse input would be spectacular. Several of my recent robotics projects have used the PicAxe's ability to read PS/2 keyboards. My next PicAxe project will be a hack along the lines of hippy's suggestion. Steeping back in time to the kinder, gentler days of a mechanical mouse with a rubber ball and mechanical encoders (optical chopper wheels). I'm sure a 20M2 can make short work of keeping track of two quadrature encoders and a few buttons. I had a BASIC Stamp 2 tracking a quad encoder on a motorized disk at 394 pulses/second. The motor blew up before the Stamp ever missed a stripe: