PS/2 mouse to a BS2

BobbyJ

I am still trying to hook up a PS/2 mouse to a BS2. I haven't had a lot time to get much done on it. But I got lucky last night, things were pretty slow at work and I was able to spend a couple hours working on it. This is only part of what I came up with. It's by no means complete, and it still needs more work. But since it is what does most of the work receiving data from the mouse, I figure it's the most important part. I guess my big question here is to see if I am on the right track. Some of the commands, and especially the array modifiers, still have me a bit confused.

Incase anybody isn't familiar with the PS/2 mouse protocol, and to maybe help this make a bit more sense, here's a really simplified description of the protocol.·It uses synchronous data transmssion.·The mouse sends the clock signal. Data is sent from the mouse·in 3-byte packets to the host. In this case the host is a Basic Stamp 2. The first byte is overflow and button state (pressed/not pressed) data, the second byte is X axis movement, and the 3rd byte is Y axis movement. The byte's are sent in 11-bit frames as follows:

1 start bit, always 0
8 data bits
1 parity bit, odd parity
1 stop bit, always 0

If no data is being sent, both the clock line and the data line will be high.

'Clock Line is on PIN 0

'Data Line is on Pin 1

[b][/b]

[b]BitCounter VAR Byte[/b]

[b]BitIndex VAR NIB[/b]

[b]ByteIndex VAR NIB[/b]

[b]ParityBit VAR BIT[/b]

[b]ParityCount VAR NIB[/b]

[b]RxData VAR BYTE(3)[/b]

[i]'[noparse][[/noparse]insert code here to initialize mouse][/i]

[b]Start:[/b]

  'resest BitCounter, counter used to determine which bit is being recieved

  [b]BitCounter = 0[/b]

  'three cycle's, one for each byte

  [b]FOR ByteIndex = 1 TO 3[/b]

    'reset parity counter

[b]    ParityCount = 0[/b]

    'wait for clock line to go low

[b]    WaitForClock:[/b]

[b]      IF INS0 = 1 THEN WaitForClock[/b]

    'wait for data line to go low...start bit, always 0

[b]    WaitForData:[/b]

[b]      IF INS1 = 1 THEN WaitForClock[/b]

    'each cycle recieves 1 of 8 bit's

    [b]FOR BitIndex = 1 TO 8[/b]

      'see description below

      [b]GOSUB ClockWaffle[/b]

      'the big question mark in my mind. RxData is a 3-varible array which

      'has a combined total of 24 bits numbered 0 to 23. If this works the

      'way I assume it does, it should get each bit and put it into the array

      'in a usefull order. array modifiers still confuse me a bit, so I don't

      'know for sure if this is correct.

      [b]RxData.LOW.BIT(BitCounter) = INS1[/b]

      'adds up all the high bits for the current byte. this is used for

      'parity check

      [b]IF RxData.LOW.BIT(BitCounter) = 1 THEN ParityCount = ParityCount + 1[/b]

      'increase bitcounter by 1

[b]      BitCounter = BitCounter + 1[/b]

[b]    NEXT[/b]

    'see description below

    [b]GOSUB ClockWaffle[/b]

    'get parity bit and add that to ParityCounter. PS/2 uses odd parity so

    'ParityCount should end up being an odd number. To check, paritycounter

    'is devided by 2, if there is no remander then something is wrong

[b]    ParityBit = INS1[/b]

[b]    ParityCount = ParityCount + ParityBit[/b]

[b]    IF ParityCount // 2 = 0 THEN SendError[/b]

[b]    [/b]'[i][noparse][[/noparse]Insert code here to handle stop bit][/i]

[b]  Next[/b]

[i]'[noparse][[/noparse]Insert code here to process the 3 bytes and put them to use][/i]

'rince and repeat

[b]GOTO Start[/b]

'assuming the BS2 is fast enough to process everything fast enough, the

'clock line will/may still be low after recieving previous bit. this waits

'for the clock line to go high, and then waits for it to drop back to low

'for next bit to be recieved

[b]ClockWaffle:[/b]

[b]  Wait:[/b]

[b]    IF INS0 = 0 THEN Wait[/b]

[b]  WaitSomeMore:[/b]

[b]    IF INS0 = 1 THEN WaitSomeMore[/b]

[b]RETURN[/b]

[b][/b]

[b]SendError:[/b]

  '[i][noparse][[/noparse]Insert code here to send error message to mouse. this will cause [/i]

[i]  [/i]'[i]mouse to resend current data packet][/i]

[b]RETURN[/b]

I'm not sure what I did to get the lines on there, and I have no idea how to get rid of them. I was trying to retype something and they popped up, it looked a lot better without them. Unfortunatly, i don't feel like typing all that over again just to get rid of them.

Post Edited By Moderator (sswanson) : 8/12/2004 8:26:54 PM GMT

BobbyJ

all that typing and I forgot to add soemthing to the subject line, whoops

Jon Williams

You definitely have errors in your code:

RxData.LOW.BIT(BitCounter) --> should be RxData.LOWBIT.(bitCounter)

Wait --> is a PBASIC keyword

Even if you get the code working correctly, I doubt that it will be reliable as interpreted PBASIC is probably not fast enough to load instructions in between clock pulses. You may need to use an external processor.

Or ... you could get an old serial mouse; but then you'll need some kind of buffer. One of our staff engineers, Andy, has connected a stock serial mouse to our Javelin microcontroller and used it in some fun experiments.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Jon Williams
Applications Engineer, Parallax
Dallas Office

AlWilliamsAWC

I can promise you from experience that the PS/2 clocks generated by just about any device you will find will overrun a plain BS2. I doubt you could even do it with a BS2SX. The PAK-VIa or PAK-XI will do the job, of course, but that's all they do and they are running much faster than a BS2 program.

I keep wanting to experiment with going the other way; Stamp to PC. That should be possible since the PC would probably just think the PS/2 device was really slow (which is allowed). I have a PS2 cable sitting here.... maybe a project of the month soon.

Al Williams
AWC
Add Floating Point to your Stamp
http://www.awce.com/pak12.htm
·

BobbyJ

'Wait' was actually supposed to be 'WaitABit'. I'm not sure why I put a dot between LOW and BIT, wasn't what I had wrote down. But was my interpretation of how the LOWBIT() modifier would work with an array? I don't know how many times I read the manual on that one. For some reason each time I tried to figure out how the modifiers work with arrays, the more confused I got.

I pretty much figured everything would come down to one single thing...timing. Based on the PS/2 protocol, I kinda figured it would either be cutting it seriously close, or not cutting it at all. The clock pulses come from the mouse every 30 to 50 microseconds. But even if I was able to get it to work, I've already discovered a potencially fatal problem with my project. The whole point of it is to connect a mouse to an XBox controller. I realized the controller must poll it's 18 inputs at a specific rate, but I don't know what that rate is. The basic stamp would be used to close the circiut for some of the inputs. Diodes would replace buttons and a digital potentiometer would replace joystick. If the timing isn't exactly right, the controller would miss the inputs.

BobbyJ

er, not diode...transistors

Jon Williams

It think you're probably going to need an SX (not BS2sx, but a straight SX) to accomplish your task. As you said, timing is the issue. BS2 instructions, on average, take about 150 microseconds to be fetched [noparse][[/noparse]from EEPROM] and setup -- so you're in trouble right from the get-go.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Jon Williams
Applications Engineer, Parallax
Dallas Office

KenM

Yeah, A straight SX. 20nS per clock cycle (running at 50 MHz) and many instructions are 1 or 2 clock cycles, some 3, some 4.

Yeah, the SX blows away a stamp as far as speed. On the other hand, a Stamp blows away the SX on ease of programming, I use both.

Typically a Stamp to get the concept working, then an SX for the "real thing" that is usually sold to somebody.

Ken

Jon Williams

There are lots of BASIC Stamp modules and OEM BASIC Stamp controllers built into "the real thing." The choice is usually has to do with cost versus time to market -- yes, the BASIC Stamp module is more expensive, but for getting a product to market quickly, it is very hard to beat.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Jon Williams
Applications Engineer, Parallax
Dallas Office

KenM

Couldn't agree more!· In my small world, it would be impossible to beat the time to market using a Basic Stamp. Most of my projects are one or two offs. I also enjoy the challenge of writing assembly for the SX, however, sometimes I wonder why, especially at 2 am when the dang thing is not working! Ha!

Jon Williams said...
There are lots of BASIC Stamp modules and OEM BASIC Stamp controllers built into "the real thing." The choice is usually has to do with cost versus time to market -- yes, the BASIC Stamp module is more expensive, but for getting a product to market quickly, it is very hard to beat.

JohnnyV

I don't really understand what you mean by " The whole point of it is to connect a mouse to an XBox controller. " If all you want to do is have a mouse for your xbox (for linux?) then you simply have to buy a usb mouse and solder a usb connector to a cut off controller wire. Xbox controllers are just usb.

BobbyJ

The point is to use the mouse with XBox games. I am a huge fan of using a keyboard/mouse setup for first person shooters. Obviously, Microsoft is not, and neither are any after market controller manufactures. Everything I've read says a regular USB keyboard and/or mouse will not work with games unless the game developers specifically write the code to support them. So, I am making a custom controller that allows the kind of input I prefer. The mouse will replace the right thumb-stick and I'll use the kind of buttons you find on full size arcade games to replace everything else. The core of the controller will be the pcb from a Microsoft XBox Controller S.

The bad news is the BS2 I had planned on yanking out of a previous project to use for the mouse interface won't be used since it is too slow. The good news is now I don't have to yank the BS2 out of one of my previous projects. I'm going to be using an SX chip, big speed + low cost = more likely chance of success.