On Sun, 03 Jun 2007 18:00:34 +0200, neimad <ro...@fr...> 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
|
