On Sun, 03 Jun 2007 18:00:34 +0200, neimad <[EMAIL PROTECTED]> wrote:
Hello again,
In usb_get_status_TuxDroid(), cmd_dispath is declared as being
unsigned char [5]. Entries 0..3 are used indeed, but entry 4 looks
like it's merely an "end of string" byte (being always 0) and it's
never used in update_raw_status_table().
The latter only accesses entries 0..3 of the array, but its parameter
is declared as being unsigned char [TUX_RECV_LENGTH] (ugly, btw) whose
value happens to be 0x05.
Is that the "same 5" (if I may say) than the 5 in the declaration of
cmd_dispatch[5] in usb_get_status_TuxDroid() ?
If the terminal 0 is of no use, as it seems, usb_get_status_TuxDroid()
could be greatly simplified.
In the old USB firmware (the buggy one) I think status were retrieved from
the dongle one 5 bytes frame at a time. I guess that's where all this
comes from. Now we get the complete buffer in one request (64 bytes) in
which the 4 first bytes are various information from the USB IC ad the 60
remaining bytes can be 15 status from tux. A status frame is 4 bytes, the
first byte is the status type and the 3 remaining bytes are the values. (I
still don't like this 4 byte frame but that's how it's been done in the RF
so we don't much choice here.)
So to answer your question, yes we should drop that last byte together
with TUX_RECV_LENGTH.
David
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
tux-droid-user mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/tux-droid-user
