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 at
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 USB
chip. This frame contains a few RF and dongle status (in which the RF ACK
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 = NULL)
2. The USB gives the 4 bytes raw command to the RF module (I) (RF_ACK =
WAITING)
3. The RF(I) sends it to the other RF module (II) (RF_ACK = WAITING)
4. The RF(II) sends back an acknowledge to the RF(I)
5. If RF(I) receives the ACK, then RF_ACK = OK
else after a timeout, RF_ACK = 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 case
the flag is never reset. It's the USB status thread which was supposed to
poll the status regularly and reset the flag. As this thread is not there
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 the
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
-------------------------------------------------------------------------
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
