Tony
Excuse my bluntness, but you have alluded to your brain injury and I'm sure that's what giving these manic responses where you're making changes/clutching at straws at random so often its hard to tell exactly what you're seeing or thinking! I feel you are overthinking this and confusing the hell out of yourself....
and anyone else reading this thread...
I prescribe a dark room and stop thinking for a while..... and breathe.... and read this slowly...
You are right, to find a problem we need to remove variables - including the biggest one; ourselves. Its very easy to get blinded to our own ability to screw up and look for problems elsewhere. That's why a slow and logical step by step approach is needed, focussing on one avenue of attack at a time.
Now, to further address your last few posts:
The start byte is data[0]. This is standard serial comms architecture. Data[0] is 0x60. This has bit 7 - the MSB - set to zero. So stop worrying about any of that, the framing looks OK.
The difference between the two data bytes in data[4] 0xE2 followed by 0xC2 is bit 5 which is the top bit of the 3 LSB of speed. For that to change means speed goes from 132 to 128. If you are putting the same speed value its extremely unlikely that this value being changed after encoding but we need to test this - I will come back to that.
should Data [4] have bracket around the whole statement...or all of the bit sliced data bytes for that matter.. ? It has to be something tiny i am missing...
no, its fine and works as expected. Set maxSpeed and speed to 0, for values of direction 0 - 1023 test boundary conditions of:
- Code: Select all
value = 0 gives data[2] = 0x80, data[4] = 0x80
value = 7 gives data[2] = 0x80, data[4] = 0x87
value = 8 gives data[2] = 0x81, data[4] = 0x80
value = 15 gives data[2] = 0x81, data[4] = 0x87
value = 16 gives data[2] = 0x82, data[4] = 0x80
value = 1023 gives data[2] = 0xFF, data[4] = 0x87
A similar table for speed and MaxSpeed with the other two set to zero can be created. I'll leave that as a useful exercise for you to try.
When I write code such as this I always use a technique called test-driven development where you write tests first then put the code into a procedure and subject it to rigorous testing. It takes a minute longer but saves time as every time you change something the tests are rerun automatically to check nothing else got changed or broken. I won't say more here else this post gets too long but happy to explain further elsewhere.
On the subject of testing, when I talk about eliminating ourselves, you provided a great 'for instance'. The code you posted
@ 9:04am UK post 83383 has a glaring error:
- Code: Select all
// Assign joystick and speedpot MSBs values to data[1 ] - data[3], setting MSB = 1
data[1] = 0x80 | ((speed >> 1) & 0x7f); // Joystick speed reading (7 MSbs)
data[2] = 0x80 | ((direction >> 1) & 0x7f); // Joystick direction reading (7 MSbs)
data[3] = 0x80 | ((maxSpeed >> 1) & 0x7f); // Speed pot reading (7 MSbs)
instead of
- Code: Select all
// 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)
Is that because you retyped it for the post, or cut and pasted it from code you're testing with???
Also this statement
Using above as example, i build a 2D matrix (spaces so its easier to read)
Bit8 to 1000 0000 (1 when active)
bit7 to 0000 0000 (not used)
suggests you're still not fully comfortable with bit numbering (ordinal) in relation to its position (index) in a byte/word/dword etc, e.g. the 1st bit is bit 0 so in your example, the 8th bit, bit 7 IS used, its 1000 000, there is no bit 8 in a byte. Nor are you fully comfortable with the natural conversion between bit index, its binary and/or decimal value and how to add it in (bitwise or) and remove (bitwise and with complement) to the byte.
Your last point about data stream elements and bootup sequence may or may not be relevant,
so follow that up until you are sure one way or the other before we do anything else.
Since you can't print anything at the moment the way I would debug this is to start with the base code and make some simple but clean changes to eliminate any variable elements. I'll come back to this in a subsequent post, but put the base code for the hardware serial version here so I can see what you are testing with right now.
)
)
