[tuxdroid-user] Daemon to USB connection

[David B. <da...@ja...>]

Hi Damien and the others,

I'm finally looking at the daemon more seriously as I'm adding the sleep=
  =

and ID stuff now. There are a couple things I'd like to discuss.

First, I'm writing some code in the daemon and as I'm still a beginner a=
t  =

linux programming, I would appreciate any kind of feedback regarding my =
 =

commits, would it be the style, the kind of functions I use, the  =

structure, anything I could do better is welcome to point out.

For the current code, it seems that by removing the USB status thread at=
  =

revision 322, the cmd_status_flag (which should probably have been a  =

mutex) is never reset when the usb_write_TuxDroid() function is called. =
To  =

understand what's happening, I need to describe how the USB/RF protocol =
 =

works.

Each 2ms, a frame is sent from the RF module(I) (in the dongle) to the U=
SB  =

chip. This frame contains a few RF and dongle status (in which the RF AC=
K  =

is), the microphone sound data and 4 bytes of raw status from tux. Here'=
s  =

what's happening when sending some raw data to tux:

Sending a command - done by usb_write_TuxDroid():
(RF_ACK is NULL in each USB->PC frame prior to sending a command)
1. Write the command on the USB - usb_interrupt_write(...) (RF_ACK =3D N=
ULL)
2. The USB gives the 4 bytes raw command to the RF module (I) (RF_ACK =3D=
  =

WAITING)
3. The RF(I) sends it to the other RF module (II) (RF_ACK =3D WAITING)
4. The RF(II) sends back an acknowledge to the RF(I)
5. If RF(I) receives the ACK, then RF_ACK =3D OK
    else after a timeout, RF_ACK =3D KO

So basically the daemon sends a raw command, set the cmd_status_flag and=
  =

waits (loop and usleep) for the flag to be reset which means the RF_ACK =
 =

has been received and is either OK or KO, with a timeout of 150ms in cas=
e  =

the flag is never reset. It's the USB status thread which was supposed t=
o  =

poll the status regularly and reset the flag. As this thread is not ther=
e  =

anymore, I guess the flag is not reset during usb_write_TuxDroid and the=
  =

returned value is always ACK_CMD_TIMEOUT.

I don't necessarily want to revert the thread and to improve the  =

communication I think we should divide usb_write_TuxDroid() in 2  =

functions, one that would send the raw, the other that would wait for th=
e  =

ack
1. either they're called alternately and we can't send a raw if the ack =
is  =

not received (as of now)
2. either we can send a second command while waiting for the ack of the =
 =

first one; we can't send more than 2 commands while waiting for the ack =
 =

otherwise it's possible that it will overwrite the previous command.

I'd like to implement 2. and also add a buffer for the incoming commands=
  =

(from the API or anything else).
As of now the API sends one command to the daemon, waits for the ACK and=
  =

store it in a variable which is not used by the applications, this  =

explains why the daemon is still working. The ACK is always TIMEOUT but =
 =

that doesn't matter for the application.

Any thought about this before I start working on it? (Yes I know I have =
to  =

add the protocols on the wiki ;-) )

Finally, I find the file structure quite strange, there's only main.c in=
  =

the root folder, then all files are under /libs and all names start with=
  =

USBDaemon. I don't want to change this right now but any idea on what a =
 =

good structure and naming conventions would be?

Cheers,
David