Going about understanding the above differently....
(speedpot & 0x1) = (255 & 0x1) = (1111 1111 & 0000 0001) = 0000 0001 and then shifts it 6 places...giving 0100 0000
(speed & 0x7) = (
190 & 0000 0111) = (1011 1110 & 0000 0111) = 0000 0110 and shifts it 3 places ...giving 0011 0000
(direction &0x7) = (
191 & 0000 0111) = (1011 1111 & 0000 0111) = 0000 0111) and no bitshift = 0000 0111
Bitwise OR is " | " sign, meaning if any of the numbers being summed are 1 then the bit for that position is 1 ?
0100 0000
0011 0000
0000 0111
=0111 0111 = 119 ?
I used the Dec values i see in the trace from the factory joy read...and the factory result is 214...so i am getting closer i feel, to understanding it, definitely getting smaller headaches thinking about it
NO you made a fundamental error above... the decimal values in the trace are already coded. 190 and 191 are only part of the decimal value, already shifted right.
reviewing the data values from the lower trace in
post 81554 above
you have data[1]-[4] = {0xbe, 0xbf, 0xff, 0xd6}. removing MSB this translates to {0x2e, 0x2f, 0x7f, 0x56} which in turn decodes to:
maxSpeed = (0x56>>6) | (0x7f << 1) = 0xff = 255
speed = ((0x56>>3) & 0x7) | (0x2f<<3) = 0x17A = 378
direction = (0x56 & 0x7) | (0x2e<<3) = 0x176 = 374
These the values you need to be inputting for speed and direction. if not, then its no surprise the outputs don't tally.
I am interested in the " & 127 " v's 0x7F .. and there is more, this little bit of code for sure is a lot more complicated than it looks.
'& 127' is the same as '& 0x7f', the former is decimal, the latter hex. Tho identical, the latter is better syntactically as we are dealing with bitwise and/or functions.
As far as I can see there is no issue with 'direction/numbering' of bits. They follow standard convention of bit 0 = LSB of byte. The only confusion is the way the logic analyser shows the data stream LSB to the left which is correct as regards time sequence (time progresses right) but is counter-intuitive to the way bytes are normally written and the reverse of the hex value of the byte in blue above it.
There is however one glaring error in the code I wrote. Remember way back the issue of framing. The first/start byte has its MSB set to 0 to denote start of packet, subsequent bytes of the message have MSB set to 1. So the following corrects that:
- Code: Select all
.
.
.
maxSpeed = 255; // this is a fixed value ...being full speed on the Shark Remote
data[0] = (0x60); // Packet type identifier
// Assign joystick and speedpot MSBs values to data[1 ] - data[3], setting MSB = 1
data[1] = 0x80 | ((speed >> 3) & 0x7f); // Joystick speed reading (7 MSbs)
data[2] = 0x80 | ((direction >> 3) & 0x7f); // Joystick direction reading (7 MSbs)
data[3] = 0x80 | ((maxSpeed >> 1) & 0x7f); // Speed pot reading (7 MSbs)
/* encode LSBs into data[4] as follows
bit 6: Speed pot reading LSB
bits 5-3: Joystick speed reading (3 LSBs)
bits 2-0: Joystick direction reading (3 LSBs)
and set MSB = 1 */
data[4] = 0x80 | ((maxSpeed & 0x1) << 6) | ((speed & 0x7) << 3) | (direction & 0x7);
) ...so that I can investigate some more .
even you had already proved it to be true.