tux-droid-user — tuxdroid-user

Re: [tuxdroid-user] cmd_dispatch size inconsistency

[neimad <ror...@gm...>]

"David Bourgeois" <da...@ja...> writes:

> 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.

Great, I'll patch this tomorrow.

       Damien

Re: [tuxdroid-user] cmd_dispatch size inconsistency

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

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

[tuxdroid-user] cmd_dispatch size inconsistency

[neimad <ro...@fr...>]

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.

	Damien

Re: [tuxdroid-user] Daemon to USB connection

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

On Sun, 03 Jun 2007 08:30:32 +0200, neimad <ror...@gm...> wrote:

>>>> There's the same for function calls, should we do
>>>>      void my_long_function_call(parameter_1, parameter_2,   
>>>> parameter_3,
>>>>                                 parameter_4)
>>>> or
>>>>      void my_long_function_call(parameter_1, parameter_2,   
>>>> parameter_3,
>>>>              parameter_4)
>>>
>>> Both styles are ok and I have used both. Depends on the coding style
>>> conventions. (For the second one, it is advised to indent the second
>>> part with two indentation levels.)
>>>
>>> I prefer the first one though, as I find it a bit cleaner (and it is
>>> how Emacs indents C by default ;-)).
>>
>> vi defaults to the second, I think we'll never agree on this ;-)
>
> So, which style to you choose ? (the second one, I bet) I'll set up my
> Tuxdroïd mode to use that style.

Just kidding ;-)
Most of the code is already inlining with the opening parenthesis so we  
can just keep on with that.

Re: [tuxdroid-user] Daemon to USB connection

[neimad <ror...@gm...>]

"David Bourgeois" <da...@ja...> writes:

[...]
> What about defines, enums, etc., you'd put the comment/description of
> define_1 on the right or on the line before?
> enum my_enum {
>     define_1,
>     define_2,
> }

For enums, I write the comment about the enum itself above it and the
comments describing each enum member (not always necessary, sometimes
the names speak for themselves) to the right of the member. Using dox
comments:

    /** My very nice enum */
    enum my_enum {
        define_1,  /**< Blah blah 1 */
        define_2,  /**< Blah blah 2 */
    };

>>> There's the same for function calls, should we do
>>>      void my_long_function_call(parameter_1, parameter_2,  parameter_3,
>>>                                 parameter_4)
>>> or
>>>      void my_long_function_call(parameter_1, parameter_2,  parameter_3,
>>>              parameter_4)
>>
>> Both styles are ok and I have used both. Depends on the coding style
>> conventions. (For the second one, it is advised to indent the second
>> part with two indentation levels.)
>>
>> I prefer the first one though, as I find it a bit cleaner (and it is
>> how Emacs indents C by default ;-)).
>
> vi defaults to the second, I think we'll never agree on this ;-)

So, which style to you choose ? (the second one, I bet) I'll set up my
Tuxdro=C3=AFd mode to use that style.

[...]
> Looking into this again (to find you some pointers), I'm not sure my
> previous statement was right, I'll have to do some tests again. This
> was  discussed on the avrlibc mailing list some time ago. But what I'm
> sure now  is that a swicth can be very efficient if all cases are
> incremental as it  can use a lookup table, otherwise it generates a
> if-then-else sequence  which takes much more space. In i2c.c (tuxcore)

Yeah, I have some memories about lookup tables being generated for
small switches on contiguous values. Never bothered to look at the
generated code, though.

> I created the lookup table  manually as the compiler never wanted to
> do it, and I saved more than 100  bytes doing so.
> I'll let you know if I find something interesting.

Okay, thanks.

[...]
> Yep, my fault, I was probably asleep at the time I wrote that. I'll
> fix  it, write it 100 times and go to sleep without eating ;-)

We'd rather add the things we discuss here to the coding style
guidelines when we're set :-)

	Damien

Re: [tuxdroid-user] Daemon to USB connection

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

On Sat, 02 Jun 2007 10:01:06 +0200, neimad <ror...@gm...> wrote=
:

> [...] I always put the comment on the line before the statement, so
> I would write your example above as follows:
>
>     /* wait 200ms for the pull-up to rise before next standalone
>      * behavior otherwise position switches signals are wrong */
>     event_timer =3D 2;
>

Thanks, that's what I wanted to know, though I'm so used to it that I'll=
  =

have a hard time ... ;-)
What about defines, enums, etc., you'd put the comment/description of  =

define_1 on the right or on the line before?
enum my_enum {
     define_1,
     define_2,
}

>> There's the same for function calls, should we do
>>      void my_long_function_call(parameter_1, parameter_2,  parameter_=
3,
>>                                 parameter_4)
>> or
>>      void my_long_function_call(parameter_1, parameter_2,  parameter_=
3,
>>              parameter_4)
>
> Both styles are ok and I have used both. Depends on the coding style
> conventions. (For the second one, it is advised to indent the second
> part with two indentation levels.)
>
> I prefer the first one though, as I find it a bit cleaner (and it is
> how Emacs indents C by default ;-)).

vi defaults to the second, I think we'll never agree on this ;-)

> [...]
> Hmm, ok then. If you have pointers on embedded-specific programming
> practices, I'd be very interested (if only to avoid committing code
> considered bad from an embedded pov).

Looking into this again (to find you some pointers), I'm not sure my  =

previous statement was right, I'll have to do some tests again. This was=
  =

discussed on the avrlibc mailing list some time ago. But what I'm sure n=
ow  =

is that a swicth can be very efficient if all cases are incremental as i=
t  =

can use a lookup table, otherwise it generates a if-then-else sequence  =

which takes much more space. In i2c.c (tuxcore) I created the lookup tab=
le  =

manually as the compiler never wanted to do it, and I saved more than 10=
0  =

bytes doing so.
I'll let you know if I find something interesting.

> In commit r335:
>
>      typedef enum
>      {
>          USB_CONNECTION_CONNECT =3D 1,
>          USB_CONNECTION_DISCONNECT =3D 2,
>          USB_CONNECTION_ID_LOOKUP =3D 3,
>          USB_CONNECTION_CHANGE_ID =3D 4,
>          USB_CONNECTION_WAKEUP =3D 5,
>          USB_CONNECTION_WIRELESS_CHANNEL =3D 6,
>      } USB_ID_PARAM1;
>
> The type is badly named: "USB_ID_PARAM1" is about its *use* whereas
> its name should really be about what it *is*.

Well, it *is* the first parameter of the USB ID command which I later  =

renamed USB connection command and probably forgot about it here.

>
> Thus I would rather have the following:
>
>      typedef enum
>      {
>          USB_CONNECTION_CONNECT =3D 1,
>          USB_CONNECTION_DISCONNECT =3D 2,
>          USB_CONNECTION_ID_LOOKUP =3D 3,
>          USB_CONNECTION_CHANGE_ID =3D 4,
>          USB_CONNECTION_WAKEUP =3D 5,
>          USB_CONNECTION_WIRELESS_CHANNEL =3D 6,
>      } usb_connection_t;
>
> The type is in lower case suffixed instead of all-uppercase, it is
> suffixed with _t (a widespread convention) and it is consistent with
> its values: usb_connection_t / USB_CONNECTION_xxx

Yep, my fault, I was probably asleep at the time I wrote that. I'll fix =
 =

it, write it 100 times and go to sleep without eating ;-)

Thanks,
David

Re: [tuxdroid-user] usleep in send_daemon_disconnect()

[neimad <ror...@gm...>]

"David Bourgeois" <da...@ja...> writes:

> There are 3 usleep in the code right now:
> 1. in id_lookup(), the RF is not connected and an id_lookup request is
> sent, usleep is used to wait for the answer that should be in the
> dongle  100ms to a few seconds later, there's nothing else to do while
> waiting  here so usleep maybe still makes sense, no?

That's ok, i guess.

> 2. in send_daemon_disconnected() but I don't understand what it's for,
> I'll ask r=C3=A9mi on Monday but I guess we can just remove it;

Ok, I'll repress my urges until then.

> 3. in usb_write_TuxDroid(), we first send the request to get the
> status,  then the USB IC stores all data in the buffer and then it's
> available on  the USB bus, usleep is meant to wait for the data here.
> That's the part  I'd like to change by cutting the function in 2 parts
> as we can process  some TCP stuff while waiting for the USB.

Agreed, we definitely need to make this asynchronous.

	Damien

Re: [tuxdroid-user] Daemon to USB connection

[neimad <ror...@gm...>]

"David Bourgeois" <da...@ja...> writes:

[...]
> so I may prefer this
>      event_timer = 2; /* wait 200ms for the pull-up to rise before next
>      standalone behavior otherwise position switches signals are wrong */
> or
>      event_timer = 2; /* wait 200ms for the pull-up to rise before next
>              standalone behavior otherwise position switches signals are
>              wrong */

I never ever comment statements like this, because it looks like shit,
really. I always put the comment on the line before the statement, so
I would write your example above as follows:

    /* wait 200ms for the pull-up to rise before next standalone
     * behavior otherwise position switches signals are wrong */
    event_timer = 2;

> There's the same for function calls, should we do
>      void my_long_function_call(parameter_1, parameter_2,  parameter_3,
>                                 parameter_4)
> or
>      void my_long_function_call(parameter_1, parameter_2,  parameter_3,
>              parameter_4)

Both styles are ok and I have used both. Depends on the coding style
conventions. (For the second one, it is advised to indent the second
part with two indentation levels.)

I prefer the first one though, as I find it a bit cleaner (and it is
how Emacs indents C by default ;-)).

>>   * There's a *big* "if else if else if ..." on command[0] which could
>>     be replaced by a switch.
>
> Switch are not optimized correctly most of the times. The last time made
> some experiments (GCC 3.4.6 iirc), switch were fine if all cases were
> growing sequentially, starting from 0 (case 0: ... case 1: ... case 2: ...
> ) otherwise the assembly generated was pretty bad. That's a bit tricky but
> in the embedded world, a good if else sequence brings much more control on
> the assembly and leads to much smaller code.

Hmm, ok then. If you have pointers on embedded-specific programming
practices, I'd be very interested (if only to avoid committing code
considered bad from an embedded pov).

>>   * Some types have all uppercase names, but this should be reserved
>>     for macro constants only. Besides, the naming of some enums types
>>     and their values could be more consistent.
>
> Are you talking about these registers? if so, these are the #defines of
> memory-mapped I/O in avrlibc and some macro aliases to these register
> definitions. I think it's better to keep them uppercased as it's the
> common practice and they're at the end const pointers.
>       CHARGER_INH_DDR |= CHARGER_INH_MK;
> +    PCICR = 0;
> +    EICRA = 0;
> +    ADCSRA = 0;
>
> For the enums, some examples are welcome.

In commit r335:

     typedef enum
     {
         USB_CONNECTION_CONNECT = 1,
         USB_CONNECTION_DISCONNECT = 2,
         USB_CONNECTION_ID_LOOKUP = 3,
         USB_CONNECTION_CHANGE_ID = 4,
         USB_CONNECTION_WAKEUP = 5,
         USB_CONNECTION_WIRELESS_CHANNEL = 6,
     } USB_ID_PARAM1;

The type is badly named: "USB_ID_PARAM1" is about its *use* whereas
its name should really be about what it *is*.

Thus I would rather have the following:

     typedef enum
     {
         USB_CONNECTION_CONNECT = 1,
         USB_CONNECTION_DISCONNECT = 2,
         USB_CONNECTION_ID_LOOKUP = 3,
         USB_CONNECTION_CHANGE_ID = 4,
         USB_CONNECTION_WAKEUP = 5,
         USB_CONNECTION_WIRELESS_CHANNEL = 6,
     } usb_connection_t;

The type is in lower case suffixed instead of all-uppercase, it is
suffixed with _t (a widespread convention) and it is consistent with
its values: usb_connection_t / USB_CONNECTION_xxx

[...]
> That part is fine. Moreover there's only 1 status (4bytes) maximum that
> can be sent each 2ms and I think it's more 1 every 4ms maximum with the
> current ack scheme. Moreover I only generate 6 status (24 bytes) each
> 100ms from tuxcore so there's no need to read them each 2 ms, each 50ms or
> 100ms is good enough.

Okay. We'll need detailed docs about this so that we don't slowly drift
away from the protocol.

[...]
>> Solution 2 would indeed be more optimized, but is it necessary ? I
>> mean, do we have performance problems, could we do with 2 commands
>> flying things we can't do know ?
>
> Well, it's more for the challenge, I like to build asynchronous stuff ;-)
> The problem may occur if in the future we want to send more data to tux,
> like if we send raw IR codes for the IR emitter, we could send 100 bytes 2
> at a time (1st=header, 2nd=index, 3 and 4 are parameters) and that may
> take some more time (400ms if we do it correctly, more around 1200ms if we
> do it like now.) I'd also want to uplad the eeprom through the RF in order
> to change the configuration of tux easily, and that's 512 bytes in case we
> use them all.
> But 1. can still do fine I think.

Your call. I don't mind implementing solution 2, just wanted to know
if there were "good" reasons (other than "let's do it 'cause it's
cool" ;)).

> By the way, I saw your commit about changing the const local arrays into
> static const arrays. So that was the opportunity to understand what's the
> difference as I thought the C compiler was smart enough to output the same
> code in both situations. I don't know about GCC but some do and some
> don't. For those interested; here's the link:
> http://www.embedded.com/story/OEG20011129S0065 (local constant objects at
> the bottom)
> I really like the articles of Dan Saks and there's one that explains why I
> used 'uint8_t const' instead of 'const uint8_t' as normally used:
> http://www.dansaks.com/articles/1999-02%20const%20T%20vs%20T%20const.pdf

Interesting point in favor of placing "const" to the right, but I'm so
used to placing it to the left I'd have a hard time adopting this way
of writing !

	Damien

Re: [tuxdroid-user] usleep in send_daemon_disconnect()

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

On Sat, 02 Jun 2007 08:16:06 +0200, neimad <ror...@gm...> wrote:

> I'm itching to remove the usleep(10000) in send_daemon_disconnected()
> but I want to know first: why was it here in the first place ? Same
> reason as for the other usleep()s that were necessary to avoid busy
> looping before select() was used ?

There are 3 usleep in the code right now:
1. in id_lookup(), the RF is not connected and an id_lookup request is  
sent, usleep is used to wait for the answer that should be in the dongle  
100ms to a few seconds later, there's nothing else to do while waiting  
here so usleep maybe still makes sense, no?
2. in send_daemon_disconnected() but I don't understand what it's for,  
I'll ask rémi on Monday but I guess we can just remove it;
3. in usb_write_TuxDroid(), we first send the request to get the status,  
then the USB IC stores all data in the buffer and then it's available on  
the USB bus, usleep is meant to wait for the data here. That's the part  
I'd like to change by cutting the function in 2 parts as we can process  
some TCP stuff while waiting for the USB.

Re: [tuxdroid-user] [tuxdroid-svn] r336 - daemon/trunk/libs

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

Yep, that's the externals that byte me again ;-),
STATUS_ID_CMD is defined in tuxdefs/commands.h which wasn't committed as=
  =

it's an external. Anyway there's nothing changed in the daemon  =

functionality compared to earlier revisions as the new functions are not=
  =

used yet. I'll fix this next week when implementing the whole sleep/id  =

stuff. You'll also need a firmware update to test the whole thing,  =

including the RF and USB that are not on SVN yet as these codes would ma=
ke  =

neimad drop dead instantly ;-)

On Fri, 01 Jun 2007 21:45:17 +0200, Philippe Teuwen <ph...@te...>  =

wrote:

> jaguarondi wrote:
>> Modified: daemon/trunk/libs/USBDaemon_status_table.c
>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>> @@ -62,6 +68,11 @@
>>  {
>>      switch (new_status[0])
>>      {
>> +    case STATUS_ID_CMD:
>>
> It seems r336 is broken:
>
> STATUS_ID_CMD is undefined
>
> Commenting out this case makes the stuff compiling.
> I didn't dig into it, just that I saw it failed on NSLU2 after an svn
> update .
>
> Phil
>
>
> ----------------------------------------------------------------------=
---
> 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
> tux...@li...
> https://lists.sourceforge.net/lists/listinfo/tux-droid-user

Re: [tuxdroid-user] Daemon to USB connection

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

On Fri, 01 Jun 2007 20:04:42 +0200, neimad <ror...@gm...> wrote:

> Well, since you asked... In the recent firmware commits:

Great, all recent commits are in my code, so I can only blame myself then  
:)
>
>   * Several lines exceed the 80 column limit (as stated in the coding
>     style guidelines) quite a bit (100+).

Yes, I'm sensible about that but still not very good about where to break  
the lines.
I still have problems with comments. What to do when I get a long comment  
this kind of line?
     event_timer = 2; /* wait 200ms for the pull-up to rise before next  
standalone behavior otherwise position switches signals are wrong */

vi seems to indent like this:
     event_timer = 2; /* wait 200ms for the pull-up to rise before next
                         standalone behavior otherwise position switches  
signals
                         are wrong */
but then i sometimes get this:
     event_timer = long_variable_that_spans_most_of_the_line; /* wait 200ms  
for
                                                                 the  
pull-up to
                                                                 rise before
                                                                 next  
standalone
                                                                 behavior
                                                                 otherwise
                                                                 position
                                                                 switches
                                                                 signals are
                                                                 wrong */

so I may prefer this
     event_timer = 2; /* wait 200ms for the pull-up to rise before next
     standalone behavior otherwise position switches signals are wrong */
or
     event_timer = 2; /* wait 200ms for the pull-up to rise before next
             standalone behavior otherwise position switches signals are
             wrong */

There's the same for function calls, should we do
     void my_long_function_call(parameter_1, parameter_2,  parameter_3,
                                parameter_4)
or
     void my_long_function_call(parameter_1, parameter_2,  parameter_3,
             parameter_4)

Any suggestion?

>
>   * There's a *big* "if else if else if ..." on command[0] which could
>     be replaced by a switch.

Switch are not optimized correctly most of the times. The last time made  
some experiments (GCC 3.4.6 iirc), switch were fine if all cases were  
growing sequentially, starting from 0 (case 0: ... case 1: ... case 2: ...  
) otherwise the assembly generated was pretty bad. That's a bit tricky but  
in the embedded world, a good if else sequence brings much more control on  
the assembly and leads to much smaller code.

>   * Some types have all uppercase names, but this should be reserved
>     for macro constants only. Besides, the naming of some enums types
>     and their values could be more consistent.

Are you talking about these registers? if so, these are the #defines of  
memory-mapped I/O in avrlibc and some macro aliases to these register  
definitions. I think it's better to keep them uppercased as it's the  
common practice and they're at the end const pointers.
      CHARGER_INH_DDR |= CHARGER_INH_MK;
+    PCICR = 0;
+    EICRA = 0;
+    ADCSRA = 0;

For the enums, some examples are welcome.

> That's something I'll have to check. When I removed the threads, I had
> a strange feeling about the locking that I wasn't able to pinpoint at
> that time, so I may have overlooked something...
>
> Right now, what happens is that select() has a timeout of 50000 µs,
> and when it times out, it calls update_tux_status():
>
>         ...
>         r = select(fdmax + 1, &rset, NULL, NULL, &timeout);
>         if (r == 0)
>         {
>             if (!update_tux_status())
>         ...
>
> This triggers the following calls:
>
>     update_tux_status()
>       \_ usb_get_status_TuxDroid()
>           \_ update_system_status_table()
>                => cmd_status_flag = 0
>
> Two things worth of note:
>
>   (1) Something I intended to fix but forgot about: currently, if
>       select() always has data to process, the timeout may well never
>       happen. We have to ensure that update_tux_status() is called
>       every 50000 µs, *no matter what*.
>
>   (2) I got the 50000 µs from the pre-r322 code. Not sure how it fits
>       the 2ms you mention below.

That part is fine. Moreover there's only 1 status (4bytes) maximum that  
can be sent each 2ms and I think it's more 1 every 4ms maximum with the  
current ack scheme. Moreover I only generate 6 status (24 bytes) each  
100ms from tuxcore so there's no need to read them each 2 ms, each 50ms or  
100ms is good enough.

>
> That's just after a quick look, I'll have to read the code and my
> commit more thoroughly.

The problem was only in the usb_write_TuxDroid() function where there was  
a loop waiting for the thread to read the status, which doesn't occur  
anymore. Nothing bad as it didn't affect the end applications and it's now  
fixed.

> I'd rather avoid using threads, as it eludes portability problems (see
> the NSLU2 problem). We can do just the same with a state machine using
> select().

pthreads should be part of uclibc but if I agree we better avoid them.

>> 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).
>
> Solution 2 would indeed be more optimized, but is it necessary ? I
> mean, do we have performance problems, could we do with 2 commands
> flying things we can't do know ?

Well, it's more for the challenge, I like to build asynchronous stuff ;-)
The problem may occur if in the future we want to send more data to tux,  
like if we send raw IR codes for the IR emitter, we could send 100 bytes 2  
at a time (1st=header, 2nd=index, 3 and 4 are parameters) and that may  
take some more time (400ms if we do it correctly, more around 1200ms if we  
do it like now.) I'd also want to uplad the eeprom through the RF in order  
to change the configuration of tux easily, and that's 512 bytes in case we  
use them all.
But 1. can still do fine I think.

By the way, I saw your commit about changing the const local arrays into  
static const arrays. So that was the opportunity to understand what's the  
difference as I thought the C compiler was smart enough to output the same  
code in both situations. I don't know about GCC but some do and some  
don't. For those interested; here's the link:  
http://www.embedded.com/story/OEG20011129S0065 (local constant objects at  
the bottom)
I really like the articles of Dan Saks and there's one that explains why I  
used 'uint8_t const' instead of 'const uint8_t' as normally used:
http://www.dansaks.com/articles/1999-02%20const%20T%20vs%20T%20const.pdf

Thanks for that feedback, really appreciated!
David

[tuxdroid-user] usleep in send_daemon_disconnect()

[neimad <ror...@gm...>]

I'm itching to remove the usleep(10000) in send_daemon_disconnected()
but I want to know first: why was it here in the first place ? Same
reason as for the other usleep()s that were necessary to avoid busy
looping before select() was used ?

	Damien

Re: [tuxdroid-user] [tuxdroid-svn] r336 - daemon/trunk/libs

[Philippe T. <ph...@te...>]

jaguarondi wrote:
> Modified: daemon/trunk/libs/USBDaemon_status_table.c
> ===================================================================
> @@ -62,6 +68,11 @@
>  {
>      switch (new_status[0])
>      {
> +    case STATUS_ID_CMD:
>   
It seems r336 is broken:

STATUS_ID_CMD is undefined

Commenting out this case makes the stuff compiling.
I didn't dig into it, just that I saw it failed on NSLU2 after an svn 
update .

Phil

Re: [tuxdroid-user] Daemon to USB connection

[neimad <ror...@gm...>]

"David Bourgeois" <da...@ja...> writes:

> 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.

Well, since you asked... In the recent firmware commits:

  * Several lines exceed the 80 column limit (as stated in the coding
    style guidelines) quite a bit (100+).

  * There's a *big* "if else if else if ..." on command[0] which could
    be replaced by a switch.

  * Some types have all uppercase names, but this should be reserved
    for macro constants only. Besides, the naming of some enums types
    and their values could be more consistent.

That's from the top of my head, I'll post more as I read the code.

> 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.

That's something I'll have to check. When I removed the threads, I had
a strange feeling about the locking that I wasn't able to pinpoint at
that time, so I may have overlooked something...

Right now, what happens is that select() has a timeout of 50000 =C2=B5s,
and when it times out, it calls update_tux_status():

        ...
        r =3D select(fdmax + 1, &rset, NULL, NULL, &timeout);
        if (r =3D=3D 0)
        {
            if (!update_tux_status())
        ...

This triggers the following calls:

    update_tux_status()
      \_ usb_get_status_TuxDroid()
          \_ update_system_status_table()
               =3D> cmd_status_flag =3D 0

Two things worth of note:

  (1) Something I intended to fix but forgot about: currently, if
      select() always has data to process, the timeout may well never
      happen. We have to ensure that update_tux_status() is called
      every 50000 =C2=B5s, *no matter what*.

  (2) I got the 50000 =C2=B5s from the pre-r322 code. Not sure how it fits
      the 2ms you mention below.

That's just after a quick look, I'll have to read the code and my
commit more thoroughly.

> 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:

[...]

> 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

I'd rather avoid using threads, as it eludes portability problems (see
the NSLU2 problem). We can do just the same with a state machine using
select().

> 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).

Solution 2 would indeed be more optimized, but is it necessary ? I
mean, do we have performance problems, could we do with 2 commands
flying things we can't do know ?

> 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?

Agreed, we'll have to shuffle things around quite a bit ;-)

	Damien

[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

Re: [tuxdroid-user] Tuxdroid ans slug (NSLU2) II

[neimad <ror...@gm...>]

Philippe Teuwen <ph...@te...> writes:

>> I've been quiet for a while since I just got a son 2 weeks ago but I'm=20
>> now back at my desk.
> Toutes mes f=C3=A9licitations!
> Pas trop dures, les nuits? ;-)

I propose a new Tux application: the Baby Simulator, for training
future fathers. It would cry, require strokes on the wings and patting
on the head at random hours, preferably in the middle of the night.

Too bad it won't crap. Next model, maybe ?

[...]
> This is very easily done.
> I tried with tuxgi, just modify around line 109
> tux.tts.auto_connect(True)
> =3D>
> tux.daemon.auto_connect(True,'slug_name')
>
> Now that would be nicer to have a kind of configuration file for the=20
> python lib, so the config is available not only for the tuxgi alone but=20
> for all the tools of the remote machine.

Agreed. The config file should have a list of IPs/hostnames allowed to
connect to Tux.

> But getting the possiblity from the tuxgi GUI to select manually another=
=20
> distant host could be also nice.

And we could even use avahi to publish the existence of Tuxes (very
easy) and have tuxgi discover them automatically on the local network.

	Damien

Re: [tuxdroid-user] Tuxdroid ans slug (NSLU2) II

[Philippe T. <ph...@te...>]

> I've been quiet for a while since I just got a son 2 weeks ago but I'm 
> now back at my desk.
Toutes mes félicitations!
Pas trop dures, les nuits? ;-)
> And I eventually got some time to setup gentoo on my slug. I got the 
> daemon working on it, thanks to the latest patch of neimad that 
> removes the pthreads. I didn't test it much yet but could control tux 
> from a python shell without problem. Next step will be to connect to 
> the daemon from another computer.
This is very easily done.
I tried with tuxgi, just modify around line 109
tux.tts.auto_connect(True)
=>
tux.daemon.auto_connect(True,'slug_name')

Now that would be nicer to have a kind of configuration file for the 
python lib, so the config is available not only for the tuxgi alone but 
for all the tools of the remote machine.
But getting the possiblity from the tuxgi GUI to select manually another 
distant host could be also nice.

Phil

Re: [tuxdroid-user] Tux Droid and Pidgin!!

[CARPENTIER T. <car...@fr...>]

Hi all!

Tux_pidgin.py  is on SVN!! Update your folders!!!

Thomas


car...@fr... a écrit :
> hi David!
>
> I think i have developer rights. I put scripts this evening.
>
> Thomas
>
> Selon David Bourgeois <da...@ja...>:
>
>   
>> On Sat, 26 May 2007 17:44:20 +0200, Julien Ruchaud
>> <jul...@gm...> wrote:
>>
>>     
>>> Good work !
>>>
>>> This script is enough well, it is possible to put this on svn ? it
>>> will be more easy to work.
>>>
>>> Julien
>>>       
>> Good idea. Thomas, do you have the developer rights yet? Otherwise contact
>> me.
>> You can add your project under /software.
>>
>> Thanks,
>> 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
> tux...@li...
> https://lists.sourceforge.net/lists/listinfo/tux-droid-user
>
>
>   

Re: [tuxdroid-user] Python API: store() and restore() unused

[neimad <ror...@gm...>]

"David Bourgeois" <da...@ja...> writes:

> I just asked R=C3=A9mi and he now uses them for the widgets stuff. He
> changed  them somehow but that's still not on svn so better leave that
> until he  commits his changes. AFAIK he changed a lot on the API but
> unfortunately  he doesn't like to use SVN so commits are not regular.

I'll wait for R=C3=A9mi's commits before I do anything on the API. Too bad
he doesn't like svn: we'd know which parts are being touched...

	Damien

Re: [tuxdroid-user] Tuxdroid ans slug (NSLU2) II

[neimad <ror...@gm...>]

"David Bourgeois" <da...@ja...> writes:

> Hi guys,
>
> I've been quiet for a while since I just got a son 2 weeks ago but I'm
> now  back at my desk.

Congratulations !

> And I eventually got some time to setup gentoo on my slug. I got the
> daemon working on it, thanks to the latest patch of neimad that
> removes  the pthreads. I didn't test it much yet but could control tux
> from a  python shell without problem. Next step will be to connect to
> the daemon  from another computer.

Got mine a week ago and even though I do have some free time, I
managed not to do anything with the slug yet...

	Damien

Re: [tuxdroid-user] Tux Droid and Pidgin!!

[<car...@fr...>]

hi David!

I think i have developer rights. I put scripts this evening.

Thomas

Selon David Bourgeois <da...@ja...>:

> On Sat, 26 May 2007 17:44:20 +0200, Julien Ruchaud
> <jul...@gm...> wrote:
>
> > Good work !
> >
> > This script is enough well, it is possible to put this on svn ? it
> > will be more easy to work.
> >
> > Julien
>
> Good idea. Thomas, do you have the developer rights yet? Otherwise contact
> me.
> You can add your project under /software.
>
> Thanks,
> David
>
>

Re: [tuxdroid-user] Tuxdroid ans slug (NSLU2) II

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

On Tue, 29 May 2007 11:23:13 +0200, Florent THIERY <ft...@gm...>  
wrote:

>> I've been quiet for a while since I just got a son 2 weeks ago but I'm  
>> now
>> back at my desk.
>
> :) Félicitations !!!

Merci ;-)

>
>> And I eventually got some time to setup gentoo on my slug. I got the
>> daemon working on it, thanks to the latest patch of neimad that removes
>> the pthreads. I didn't test it much yet but could control tux from a
>> python shell without problem. Next step will be to connect to the daemon
>>  from another computer.
>
> Great news. I should buy one myself, but right now i'm getting a
> server in an other room; did you guys experiment with the wireless
> range? There are just 2 (thin) walls in between, i have to check out
> if it's enough.

It should be OK I think.

Re: [tuxdroid-user] Tux Droid and Pidgin!!

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

On Sat, 26 May 2007 17:44:20 +0200, Julien Ruchaud  
<jul...@gm...> wrote:

> Good work !
>
> This script is enough well, it is possible to put this on svn ? it
> will be more easy to work.
>
> Julien

Good idea. Thomas, do you have the developer rights yet? Otherwise contact  
me.
You can add your project under /software.

Thanks,
David

Re: [tuxdroid-user] Tuxdroid ans slug (NSLU2) II

[Florent T. <ft...@gm...>]

> I've been quiet for a while since I just got a son 2 weeks ago but I'm no=
w
> back at my desk.

:) F=E9licitations !!!

> And I eventually got some time to setup gentoo on my slug. I got the
> daemon working on it, thanks to the latest patch of neimad that removes
> the pthreads. I didn't test it much yet but could control tux from a
> python shell without problem. Next step will be to connect to the daemon
>  from another computer.

Great news. I should buy one myself, but right now i'm getting a
server in an other room; did you guys experiment with the wireless
range? There are just 2 (thin) walls in between, i have to check out
if it's enough. If not, i'll have to go get an NSLU2 / WL500G.

Cheers

FLorent

[tuxdroid-user] Tuxdroid ans slug (NSLU2) II

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

Hi guys,

I've been quiet for a while since I just got a son 2 weeks ago but I'm now  
back at my desk.

And I eventually got some time to setup gentoo on my slug. I got the  
daemon working on it, thanks to the latest patch of neimad that removes  
the pthreads. I didn't test it much yet but could control tux from a  
python shell without problem. Next step will be to connect to the daemon  
 from another computer.

Cheers,
David