PS/2 Protocol Nightmare!

[Nigel Goodwin]

Obviously using C makes programming SO MUCH EASIER :lol: :lol: :lol:

 

[bsodmike]

Actually it does. Only thing is right now I'm not entirely sure if I'm getting valid or suspect data from the mouse. I'm going to implement a parity check (simply really, copy n' paste from the Tx) and see if what I get *is* valid. Also the fact that the characters were 'randomly jumping' makes sense and inverting the data *should* yield some results...

--Mike

 

[Jay.slovak]

Obviously using C makes programming SO MUCH EASIER :lol: :lol: :lol:

I agree with that. I can do C, but it is much more easier to do Assembly when it comes to PICs. It is pretty hard to some low level stuff with C (and that's what PICs are all about)...

 

[bsodmike]

Obviously using C makes programming SO MUCH EASIER :lol: :lol: :lol:

So Nigel, give me the gist of what needs to be done and I can translate it to C. I can manipulate the bits in vars/registers as easily as I would in ASM so it isn't that much 'harder'...

I'm going to try this sometime later on:

-------

X = (ymovementdata - 1) ^ 0xFF;

if 'sign for y' ==0
{
send '-' to lcd
distance = distance - X;

}else{
distance = distance + X;
}

b5 = distance / 10000;
b4 = (distance % 10000) / 1000;
b3 = ((distance % 10000) % 1000) / 100;
b2 = (((distance % 10000) % 1000) % 100) / 10;
b1 = (((distance % 10000) % 1000) % 100) % 10;

send it to lcd + 48;
send it to lcd + 48;
...
...
send it to lcd + 48;
-------------

Now this is more or less 'psudocode', i.e. it's the 'idea' of what to do. The language used to achieve the goal is a different story and can be debated but isn't going to really help

So what I'm after is ...do you think my 'solution to the problem at hand' is a good one, if not I'd like to hear your solution

Thanks, Mike

 

[Pommie]

Let's suppose I'm being sent 111011101(-35 as a 9-bit 2's comp)
--Mike

OK, lets stick with this bit.

111011101 = 9 bits.

9 bits don't fit in one byte and so are stored in two bytes (byte is a concatenation of by eight).

They are stored as 00000001 11011101.

I said "if the high byte is non zero then set it to 0xff" If you follow that rule, you end up with:-

11111111 11011101

Which is equal to -35 as a signed 16 bit integer.

I would guess that your C code for this would be something like:-

if (variable && 0x100 == 0x100)
variable = variable | 0xff00;

You could then add this to your position variable.

When it comes to sending this to the display, I would guess your compiler has a printf routine that can handle it.

HTH

Mike.
P.S. I typed this once and was told I was not logged on and I had to retype it.
I posted it again and was told I was not logged on. Luckily I had it saved. Is my profile set to log me off after 2 Min's or something?

 

[bsodmike]

Ok I get what you say, but the sign is only stored in a 'bit'..not a byte...or to be even more confusing the sign is bit no. 5 of byte1 of the 3-byte movement packet (haha!)...

Also wouldn't it be easier to just *read* the current distance covered (directly value off the ymovement counter) and just 'add' it to a 16-bit variable?

This way I won't need to actually mess with the 16bit variable now do I?

Also I can't just make the high byte all 1s as this integer will grow past (decimal) 255...

 

[Pommie]

I have now typed a (long) reply twice (now 4 times) and got told I'm not logged in. This 3 min login sucks.

As it's now past midnight here I'm going to bed.

If nobody explains 9 bit numbers, I'll post tomorrow.

Mike.

 

[evandude]

you're right, dealing with it as a 16-bit isn't necessary, you can just do it with an 8-bit variable and an if-else statement, like you have in your pseudo-code, just don't forget that it is a 2's complemented number, so you do have to remember to convert it back to a positive number before you go subtracting it from 'distance', in the case that it's negative, but don't convert if it's positive... in other words, move your first line there (where you convert it) inside the if statement for the negative case.

oh, and isn't assigning a variable called "X" with the Y-axis movement a little confusing? are you going to call your variable for X-axis movement "Y"? :lol:

and as for your display routine, that's very inefficient because division and modulus are not fast routines on a PIC, and you have it calculating up to 4 of those per line. For example, with the CC5x compiler there is documentation of the time it takes for certain math operations. modulus and division both take, on average, nearly 300 instruction cycles to execute for two 16-bit numbers. I would assume your compiler produces comparable delays for these operations.

you can do away with a lot of the operations with intermediate variables.

like so:

b5=distance/10000;
temp=distance%10000;
b4=temp/1000;
temp2=temp%1000;
b3=temp2/100;
temp=temp2%100;
b2=temp/10;
b1=temp%10;

that only involves 8 modulus/division operations, whereas your original code used 14. Granted, in a perfect world the C compiler should be smart enough to realize that it could re-use a lot of its own internal intermediate variables to optimize all of that, however I wouldn't rely on it until I had actually tried writing it both ways, compiling them, and verifying the final code size in each case.

 

[bsodmike]

Hrm, Ok I'll try some stuff and see how it goes. Btw I got it to work with an optical mouse + USB>PS/2 adaptor (init and all that) - reading off it I have yet to try..

--Mike