tux-droid-user — tuxdroid-user

Re: [tuxdroid-user] Including dfu-programmer in tuxsetup

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

Hi,

Don't you think a single, unique package could be best ? Because maybe
tuxdroid won't always use the mainstream version...

There is something special about tuxdroid: it's a commercial open
source product (which is something to encourage IMHO); maybe the time
to get into the repository (or set one oneself) could be shortened...

Cheers

Florent

Re: [tuxdroid-user] Including dfu-programmer in tuxsetup

[Jan W. <jan...@gm...>]

neimad schreef:

>> Usually when I don't know what to do, I try to do both and check later
>> on  what's the best option. We can try to support dfu-programmer as
>> packages  for some distributions and also include it in tuxsetup. If
>> it already  exists on the system, it's not used, otherwise it tries to
>> launch it, use  it if it works or tell the user to compile from
>> sources otherwise.
> This may work as a first step towards user-friendliness, yes. Anyone
> experienced with Debian/Ubuntu packaging ? :-)

There is already someone who has created a Debian-package for
dfu-programmer <http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=416436>.

The 'problem' at the moment is finding a sponsor (Debian developer who
uploads it to the Debian repositories). See
<http://www.mail-archive.com/deb...@li.../msg48941.html>.

Finding a sponsor is not always easy. I maintain the picprog package
for Debian and it has taken a long time ( > 3 years) before someone has
sponsered¹ my picprog package.


[¹] <http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=208692>
-- 
Met vriendelijke groetjes         - Jan Wagemakers -

 - Debian GNU/Linux lenny/sid - Up : 45 days 

Re: [tuxdroid-user] svn mailing list broken ?

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

>
> Same issue here, got everything today. It's possible it comes from 
> sourceforge as I already experienced such things. Though it may also 
> come from the server of tuxisalive, I don't know.
Yes indeed, I had all when I read you didn't but probably all in once too.

Re: [tuxdroid-user] svn mailing list broken ?

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

On Wed, 13 Jun 2007 07:29:00 +0200, neimad <ror...@gm...> wrote:

> Philippe Teuwen <ph...@te...> writes:
>
>> Here I got all your last revisions.
>> Check if you're still properly subscribed!
>> Phil
>
> Well, got 2 commit messages yesterday evening, and the rest today
> (both svn and user mailing lists), at last ! Didn't do anithing wrt
> [un]subscription, do I don't know what happened...

Same issue here, got everything today. It's possible it comes from  
sourceforge as I already experienced such things. Though it may also come  
 from the server of tuxisalive, I don't know.

Re: [tuxdroid-user] Including dfu-programmer in tuxsetup

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

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

>> What makes it hard for joe user to compile ? Couldn't it be seamlessly
>> integrated in the "tuxup procedure" (neved used it) ?
>
> Well, the feedback we get from the marketing is that a lot of geeks
> whiich  are not programmers think tux is still at the prototype stage.
> Which  somehow is ot wrong neither. I think that the next firmware
> update will be  a good improvement mostly for the energy savings. But
> people are afraid  when they read that the first thing you have to do
> is get the sources of  dfu-programmer, compile it, then upgrade the
> firmware. Then we still don't  have any real end user software with
> polished gui so that also makes them  stay doubtful about the project
> status.

As a first step, could tuxup automatically download, compile and
install dfu-programmer and all necessary tools ? Of course, it won't
help much on Ubuntu, as you point out below...

> Most newbies are using ubuntu so maybe another solution would be to
> maintain a debian/ubuntu dfu-programmer package. I could also do an
> ebuild  for gentoo but I don't think gentoo users will get trouble on
> that side.  On ubuntu, you can't compile dfu-programmer without
> installing a bunch of  developer packages like build-essentials,
> libusb-devel, etc. GCC isn't  installed by default. It took me some
> time to look around the first time I  used ubuntu to get all the
> dependencies necessary to compile. So I guess  some users will really
> benefit from a package. Even worse it seems there's  a debian package
> around which doesn't work, so some people end up there  too.

Oh, I forgot about that. The first time I installed Ubuntu, I was
puzzled and unnerved I couldn't do any programming on it ! You're
right, packages would indeed be the right thing for this distribution.

> Usually when I don't know what to do, I try to do both and check later
> on  what's the best option. We can try to support dfu-programmer as
> packages  for some distributions and also include it in tuxsetup. If
> it already  exists on the system, it's not used, otherwise it tries to
> launch it, use  it if it works or tell the user to compile from
> sources otherwise.

This may work as a first step towards user-friendliness, yes. Anyone
experienced with Debian/Ubuntu packaging ? :-)

	Damien

Re: [tuxdroid-user] svn mailing list broken ?

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

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

> Here I got all your last revisions.
> Check if you're still properly subscribed!
> Phil

Well, got 2 commit messages yesterday evening, and the rest today
(both svn and user mailing lists), at last ! Didn't do anithing wrt
[un]subscription, do I don't know what happened...

Re: [tuxdroid-user] svn mailing list broken ?

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

> My last commit is r371, and the last message I received from the
> commit mailing list is r359 (from 3 days ago). I guess there's a
> problem with the mailing list... Any info on this ?
>   
Here I got all your last revisions.
Check if you're still properly subscribed!
Phil

[tuxdroid-user] svn mailing list broken ?

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

Hello,

My last commit is r371, and the last message I received from the
commit mailing list is r359 (from 3 days ago). I guess there's a
problem with the mailing list... Any info on this ?

	Damien

Re: [tuxdroid-user] Including dfu-programmer in tuxsetup

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

On Fri, 08 Jun 2007 21:04:49 +0200, neimad <ror...@gm...> wrote:

> What makes it hard for joe user to compile ? Couldn't it be seamlessly
> integrated in the "tuxup procedure" (neved used it) ?

Well, the feedback we get from the marketing is that a lot of geeks whiich  
are not programmers think tux is still at the prototype stage. Which  
somehow is ot wrong neither. I think that the next firmware update will be  
a good improvement mostly for the energy savings. But people are afraid  
when they read that the first thing you have to do is get the sources of  
dfu-programmer, compile it, then upgrade the firmware. Then we still don't  
have any real end user software with polished gui so that also makes them  
stay doubtful about the project status.

Most newbies are using ubuntu so maybe another solution would be to  
maintain a debian/ubuntu dfu-programmer package. I could also do an ebuild  
for gentoo but I don't think gentoo users will get trouble on that side.  
On ubuntu, you can't compile dfu-programmer without installing a bunch of  
developer packages like build-essentials, libusb-devel, etc. GCC isn't  
installed by default. It took me some time to look around the first time I  
used ubuntu to get all the dependencies necessary to compile. So I guess  
some users will really benefit from a package. Even worse it seems there's  
a debian package around which doesn't work, so some people end up there  
too.

Usually when I don't know what to do, I try to do both and check later on  
what's the best option. We can try to support dfu-programmer as packages  
for some distributions and also include it in tuxsetup. If it already  
exists on the system, it's not used, otherwise it tries to launch it, use  
it if it works or tell the user to compile from sources otherwise.

David

Re: [tuxdroid-user] Daemon to USB connection

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

On Fri, 08 Jun 2007 20:06:46 +0200, neimad <ror...@gm...> wrote=
:

>
> More coding style stuff. This time from commit r357:
>
> [...]
>     switch (data[0])
>     {
>     case TUX_CONNECTION_DISCONNECT:
>         if (disconnect_from_tux() >=3D 0)
>             result[1] =3D TUX_CONNECTION_ACK;
>         else
>             result[1] =3D TUX_CONNECTION_NACK;
>         break;
>     case TUX_CONNECTION_CONNECT:
>     {
>         union_uint16_t id;
>         id.b[1] =3D data[1];
>         id.b[0] =3D data[2];
>         printf("coucou\n");
>         if (connect_to_tux(id.w) >=3D 0)
>             result[1] =3D TUX_CONNECTION_ACK;
>         else
>             result[1] =3D TUX_CONNECTION_NACK;
>         break;
>     }
>     case TUX_CONNECTION_ID_REQUEST:
> [...]
>
> I can't agree with the block indentation in TUX_CONNECTION_CONNECT:
> the curly braces are at the same depth as the switch's braces, which
> is badly readable.
>
> I'd indent it as follows:
>
> [...]
>     switch (data[0])
>     {
>     case TUX_CONNECTION_DISCONNECT:
>         if (disconnect_from_tux() >=3D 0)
>             result[1] =3D TUX_CONNECTION_ACK;
>         else
>             result[1] =3D TUX_CONNECTION_NACK;
>         break;
>     case TUX_CONNECTION_CONNECT:
>         {
>             union_uint16_t id;
>
>             id.b[1] =3D data[1];
>             id.b[0] =3D data[2];
>
>             printf("coucou\n");
>
>             if (connect_to_tux(id.w) >=3D 0)
>                 result[1] =3D TUX_CONNECTION_ACK;
>             else
>                 result[1] =3D TUX_CONNECTION_NACK;
>         }
>         break;
>
>     case TUX_CONNECTION_ID_REQUEST:
> [...]
>
> (Note that I also spaced things out, most notably the variable
> declaration, but that's another topic ;-))
>
> The block is a sub-block of the switch()'s block and as such must be
> indented. Yes, as a consequence the code within this case is indented
> one depth level more than the code in other, block-less cases, but
> that's a small price to pay for increased readability.
>
> I also moved the closing brace *before* the break, as in my view all
> the code in a case should appear before the break (unless, of course
> there are several places where break appears) just like in the
> block-less cases.
>
> This last point is debatable, but I think the indentation level should=

> *really* be as I pointed out above :-)
>
> 	Damien, coding-style integrist

I was a bit surprised at the beginning, not being used to get switch and=
  =

case on the same level. I must admit I didn't know what to do with the  =

curly braces.
I changed in my code, it'll be soon on svn. Thanks for keeping attention=
  =

to my commits :-)

vi lovers can use that option to indent switch statements that way:
    :set cino=3D:0

David

Re: [tuxdroid-user] Daemon to USB connection

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

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

[...]
> 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 ;-) )

Well, I'd like the daemon to use real *structures* instead of byte
arrays. At least for client communication (i.e., commands coming from
and replies to the API).

The byte arrays' contents is anonymous, needs the declaration of
symbolic index constants, makes the code bigger (and less readable)
than necessary.

On the Python side, sending data to a C program that expects structs
can be achieved by the use of marshaling. I'm not aware of the latest
and greatest ways to do this in Python, but 10+ years ago there were
already such facilities, so I guess it must be possible and even
easier today ;-)

	Damien

Re: [tuxdroid-user] Daemon to USB connection

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

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

[...]
> 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?

A few ideas:

  (1) I'd rename the daemon to "tuxd", to follow conventions in the
      Unix world (okay, "tuxdaemon" matches "tuxttsdaemon", but maybe
      that can be changed too ?). This is nitpicking.

  (2) I'd get rid of the "USBDaemon" prefix. It's long and annoying to
      type with its mixed upper and lowercase, even with filename
      completion.

      Having a prefix is generally a good idea, though: it avoids
      ending up with files in different directories but with the same
      name, which eventually leads to troubles. The project is quite
      small, so we don't have this problem yet.

  (3) Merge USBDaemon_usb_enum.[ch] and USBDaemon_usb_readWrite.[ch]
      into tuxd_usb.[ch] (for example). Both these files handle USB
      and are small enough to be merged.

  (4) Except for USB, logging, and maybe command_tux and pidfile,
      there's no point in keeping any of the libs/ source as pseudo
      libraries.

  (5) The current "main.c" is an empty shell: the daemon is actually
      implemented in tcp_server, command_tux and status_table. Hence
      these files should be moved to the daemon's toplevel directory,
      and main.c somehow merged with tcp_server.

This is a very rough outline, but I think it will lead to a more
sensible daemon file structure.

	Damien

Re: [tuxdroid-user] Daemon to USB connection

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

Yet more coding style, this time in the Python API...

_Continued lines_

In tuxapi_class.py, there are lots of continued lines indented (or
rather, *not* intended) like the following:

        # create and insert a frame to match
        data_to_match =3D (SOURCE_TUX,SS_DEFAULT,DATA_TP_RSP,\
        SUBDATA_TP_STATUS,DATA_STATUS,DATA_VALUE,0,0,0,0,0,\
        0,0,0,0,0)
        data_to_match_list.append(data_to_match)

Readability is very bad, and this is against the Python coding
style[1] pointed to by tuxisalive[2]:

    =C2=AB The preferred way of wrapping long lines is by using Python's
    implied line continuation inside parentheses, brackets and braces.
    If necessary, you can add an extra pair of parentheses around an
    expression, but sometimes using a backslash looks better. *Make
    sure to indent the continued line appropriately*. =C2=BB

So the code snippet above should be written like this:

        # create and insert a frame to match
        data_to_match =3D (SOURCE_TUX,SS_DEFAULT,DATA_TP_RSP, \
            SUBDATA_TP_STATUS,DATA_STATUS,DATA_VALUE,0,0,0,0,0, \
            0,0,0,0,0)
        data_to_match_list.append(data_to_match)


_Private methods and variables_

In tuxapi_class.py again, class TUXcmd has a big doc string listing all
functions available to the users of the class. This is not necessary
as the list can be found out using dir().

Some methods have a doc string saying "Not a user function". Their
name should start with "__" (double underscore) to make them really
private, which also makes such doc strings useless.

	Damien

[1] http://www.python.org/dev/peps/pep-0008/
[2] http://www.tuxisalive.com/documentation/how-to/guidelines-for-creating-=
and-packaging-an-application

Re: [tuxdroid-user] Including dfu-programmer in tuxsetup

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

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

> Still working hard on the sleep and id update. Most stuff work now but
> it's still very unstable due mainly to the new RF firmware.
> I'd like to publish a preview of the firmwares on tomorrow so you can
> give  it a shot if you want.

I'm willing to test it \o.

> OTH I'm thinking about this major firmware update for lambda users.
> When  they just bought their tux, it seems they're quickly discouraged
> by the  firmware update procedure and some get into much troubles
> compiling and  installing dfu-programmer. tuxup already facilitates
> the use of  dfu-programmer but including a binary of dfu-programmer
> would remove that  burden.
>
> A few questions:
>
> - Is it a good idea?

The binary would have to work on all distributions and platforms. I
myself don't like binaries too much (but then, I've been a Gentoo user
for quite some time now, which might explain...)

> - I guess we can freely redistribute dfu-programmer in a binary only
> format, but I may be wrong. dfu-programmer is under GPL. Do I have to
> attach a license file with the binary or display the license
> somewhere?

You have to make the sources available, but not necessarily bundled
with the binary. A readme with an URL to download the sources from
should suffice.

> - If I compile it on my linux box, what is it supposed to run on? As
> long  as you have the dependencies, should it work on any computer or
> are there  other stuff to take into account? I'm thinking about BSD,
> OSX, ...

Library versions, as you point out below, may break your application.

> ldd /usr/local/bin/dfu-programmer
>         linux-gate.so.1 =>  (0xffffe000)
>         libusb-0.1.so.4 => /lib/libusb-0.1.so.4 (0xb7f21000)
>         libc.so.6 => /lib/libc.so.6 (0xb7df9000)
>         /lib/ld-linux.so.2 (0xb7f43000)

What makes it hard for joe user to compile ? Couldn't it be seamlessly
integrated in the "tuxup procedure" (neved used it) ?

	Damien

Re: [tuxdroid-user] Daemon to USB connection

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

More coding style stuff. This time from commit r357:

[...]
    switch (data[0])
    {
    case TUX_CONNECTION_DISCONNECT:
        if (disconnect_from_tux() >= 0)
            result[1] = TUX_CONNECTION_ACK;
        else
            result[1] = TUX_CONNECTION_NACK;
        break;
    case TUX_CONNECTION_CONNECT:
    {
        union_uint16_t id;
        id.b[1] = data[1];
        id.b[0] = data[2];
        printf("coucou\n");
        if (connect_to_tux(id.w) >= 0)
            result[1] = TUX_CONNECTION_ACK;
        else
            result[1] = TUX_CONNECTION_NACK;
        break;
    }
    case TUX_CONNECTION_ID_REQUEST:
[...]

I can't agree with the block indentation in TUX_CONNECTION_CONNECT:
the curly braces are at the same depth as the switch's braces, which
is badly readable.

I'd indent it as follows:

[...]
    switch (data[0])
    {
    case TUX_CONNECTION_DISCONNECT:
        if (disconnect_from_tux() >= 0)
            result[1] = TUX_CONNECTION_ACK;
        else
            result[1] = TUX_CONNECTION_NACK;
        break;
    case TUX_CONNECTION_CONNECT:
        {
            union_uint16_t id;

            id.b[1] = data[1];
            id.b[0] = data[2];

            printf("coucou\n");

            if (connect_to_tux(id.w) >= 0)
                result[1] = TUX_CONNECTION_ACK;
            else
                result[1] = TUX_CONNECTION_NACK;
        }
        break;

    case TUX_CONNECTION_ID_REQUEST:
[...]

(Note that I also spaced things out, most notably the variable
declaration, but that's another topic ;-))

The block is a sub-block of the switch()'s block and as such must be
indented. Yes, as a consequence the code within this case is indented
one depth level more than the code in other, block-less cases, but
that's a small price to pay for increased readability.

I also moved the closing brace *before* the break, as in my view all
the code in a case should appear before the break (unless, of course
there are several places where break appears) just like in the
block-less cases.

This last point is debatable, but I think the indentation level should
*really* be as I pointed out above :-)

	Damien, coding-style integrist

Re: [tuxdroid-user] Including dfu-programmer in tuxsetup

[Jan W. <jan...@gm...>]

David Bourgeois schreef:

> installing dfu-programmer. tuxup already facilitates the use of  
> dfu-programmer but including a binary of dfu-programmer would remove that  
> burden.

People who make use of Debian, can take a look at this ITP for
dfu-programmer <http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=416436>.

I have used this to compile a dfu-programmer_0.4.0-1_i386.deb and have
installed that on my system. 

 |  pts/3  jan ~$ dpkg -s dfu-programmer
 | Package: dfu-programmer
 | Status: install ok installed
 | Priority: optional
 | Section: devel
 | Installed-Size: 48
 | Maintainer: Andrew Straw <str...@as...>
 | Architecture: i386
 | Version: 0.4.0-1
 | Depends: libusb-0.1-4
 | Description: device firmware update (DFU) based USB programmer for Atmel chips
 |  A linux based command-line programmer for Atmel chips with a USB
 |  bootloader supporting in system programming.
 |  .
 |  This is a mostly Device Firmware Update (DFU) 1.0 compliant
 |  user-space application. This program was created because the Atmel
 |  FLIP program for flashing devices does not run on Linux and because
 |  standard DFU loaders do not work for Atmel chips.
 |  pts/3  jan ~$ 

Hopefully Andrew Straw fill find a sponsor soon, so dfu-programmer can be
part of the Debian-distribution.


I Cc: this to 41...@bu... so that Andrew knows that there are
people who appreciate his work :-)


-- 
Met vriendelijke groetjes         - Jan Wagemakers -

... My other computer is a Sun Javastation Krups
    <http://javastation.is.dreaming.org>

Re: [tuxdroid-user] usb_read_TuxDroid() correctness

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

On Mon, 04 Jun 2007 22:29:30 +0200, neimad <ror...@gm...> wrote:

>
> I have comments and questions about usb_read_TuxDroid():

Looking into it, it seems to be an old function which is not used anymore.  
In the previous usb firmware, status were read one at a time (4 bytes) and  
usually 5 different status were generated each 100ms, that's where the  
loop and the upper bound come from. This didn't make much sense that's why  
I suggested to change the usb protocol to be able to request all status  
that are available in one shot.

I'm going to remove that function.

>   (3) The documentation[1] of usb_interrupt_read() doesn't say much,
>       but I guess it may read fewer bytes than requested, and even
>       return 0 in case of a timeout. This means that the loop could
>       have read data in several iterations and still reset the loop
>       index to 0.

The USB IC has a transfer queue and it's not possible to request more  
bytes than present in the queue. I guess it was a kind of synchronisation  
trick though I'm not sure it was useful.

Sorry for the trouble,
David

[tuxdroid-user] Including dfu-programmer in tuxsetup

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

Still working hard on the sleep and id update. Most stuff work now but  =

it's still very unstable due mainly to the new RF firmware.
I'd like to publish a preview of the firmwares on tomorrow so you can gi=
ve  =

it a shot if you want.

OTH I'm thinking about this major firmware update for lambda users. When=
  =

they just bought their tux, it seems they're quickly discouraged by the =
 =

firmware update procedure and some get into much troubles compiling and =
 =

installing dfu-programmer. tuxup already facilitates the use of  =

dfu-programmer but including a binary of dfu-programmer would remove tha=
t  =

burden.

A few questions:

- Is it a good idea?

- I guess we can freely redistribute dfu-programmer in a binary only  =

format, but I may be wrong. dfu-programmer is under GPL. Do I have to  =

attach a license file with the binary or display the license somewhere?

- If I compile it on my linux box, what is it supposed to run on? As lon=
g  =

as you have the dependencies, should it work on any computer or are ther=
e  =

other stuff to take into account? I'm thinking about BSD, OSX, ...

ldd /usr/local/bin/dfu-programmer
         linux-gate.so.1 =3D>  (0xffffe000)
         libusb-0.1.so.4 =3D> /lib/libusb-0.1.so.4 (0xb7f21000)
         libc.so.6 =3D> /lib/libc.so.6 (0xb7df9000)
         /lib/ld-linux.so.2 (0xb7f43000)

Thanks,
David

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

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

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

> As of now, you can only connect one tux to the daemon. But once we'll
> have  dropped that limit, we will indeed provide a status table of all
> available  tux. The idea of R=C3=A9mi and Thierry was also to be able to
> connect multiple  daemons together so that a client connected to one
> daemon will see all tux  available on the daemon network. But I don't
> think this will be  implemented soon.
> And as I explained above, it's not possible to connect to an already
> connected tux in order to get information from them. I don't know if
> it's  possible to scan the RF band in order to catch some patterns
> that would  indicate a connected tux, without knowing it's ID. But
> anyway the RF flash  memory is already overfilled so there's no
> chances that such a thing could  get in.

Ok, thanks for these detailed explanations :-)

	Damien

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

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

On Tue, 05 Jun 2007 18:54:40 +0200, neimad <ror...@gm...> wrote:

> What if there are several Tuxes around one's computer ? Will the
> daemon return a list of available IDs, pick the first one, or pick a
> random one ?

It will pik a random one. The first tux that will get the dongle request  
will answer it's ID. This is how the RF firmware is done now. By repeating  
this a lot of times, you should get all disconnected tux lying around.
I'd like to change it so that after a request, a tux will wait something  
like 10 seconds before answering to an id_lookup again so that it's easier  
to repeat id_lookups and get all tux around.

> What if a client wants to connect to an already connected Tux ? Is it
> forbidden (as you said) so as to ensure exclusive access, or are there
> other reasons ?

You simply can't. When initialized, both RF modules will change their  
protocol which is completely different than the initialization phase. So  
it's not really forbidden, it's a limitation of the firmware.

> What about sending to the client a list of *all* Tuxes with their
> connection state (connected, not connected) ? (assuming it's not
> forbidden to request a connection of an already connected Tux, of
> course)

As of now, you can only connect one tux to the daemon. But once we'll have  
dropped that limit, we will indeed provide a status table of all available  
tux. The idea of Rémi and Thierry was also to be able to connect multiple  
daemons together so that a client connected to one daemon will see all tux  
available on the daemon network. But I don't think this will be  
implemented soon.
And as I explained above, it's not possible to connect to an already  
connected tux in order to get information from them. I don't know if it's  
possible to scan the RF band in order to catch some patterns that would  
indicate a connected tux, without knowing it's ID. But anyway the RF flash  
memory is already overfilled so there's no chances that such a thing could  
get in.

David

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

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

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

[...]
> Yes, that's what I meant. The connect_to_tux(id) function of the
> daemon is  triggered by the client and the above ACK will be returned.
> The  id_lookup() function is also triggered by the client and the ACK
> will  contain the id that has been found or a nack is no tux is found.
> By the  way, the id_lookup function can only find an unconnected tux.
> Practically  that means that you switch on your tux, plug the dongle,
> the RF modules  don't connect yet, id_lookup() will return the id of
> your tux and  connect_to_tux(id) will initialize the RF connection.
> Once the client kows  the id of your tux, you can skip the first step.
>
> I guess you should get the point now. If you think about modifications
> or  improvements, they're welcome of course.

Yes, thanks for the clarification.

What if there are several Tuxes around one's computer ? Will the
daemon return a list of available IDs, pick the first one, or pick a
random one ?

What if a client wants to connect to an already connected Tux ? Is it
forbidden (as you said) so as to ensure exclusive access, or are there
other reasons ?

What about sending to the client a list of *all* Tuxes with their
connection state (connected, not connected) ? (assuming it's not
forbidden to request a connection of an already connected Tux, of
course)

	Damien

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

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

On Mon, 04 Jun 2007 19:32:02 +0200, neimad <ror...@gm...> wrote:

> "David Bourgeois" <da...@ja...> writes:
>
> [...]
>> I forgot something here. The daemon will start when the dongle is
>> plugged,  will open the USB connection, but the connection to tux
>> won't be  initialized. It's the client that will request to conenct to
>> tux with a  specific id or do a id lookup. So during this function,
>> the client is  connected to the dongle. Anyway, during the id lookup,
>
> I didn't get this. What do you mean with "the client is connected to
> the dongle" ? In my mind, a client is a program that connects to the
> daemon; how could it be connected to the dongle ?

Sorry, that's indeed not very clear. I meant of course that:
the client will request the daemon to request the USB IC to request the RF  
module to connect to a specific tux depending on it's id. Hum, that's not  
clearer actually, the chain is too long ;-)
So the daemon is started as soon as you physically connect the USB cable  
(udev or start the daemon manually.) But the RF connection between the  
dongle and tux is not started yet. The daemon will never initialize an RF  
connection by itself (unless we find a good reason to do so). The client  
will connect to the daemon and request it to initialize the RF connection  
to a specific tux (with the id as parameter) or do the id_lookup in which  
case the id which is returned by the dongle will be sent back to the  
client so it can use it to request a connection.

>
>> there's nothing  else to send back to the client but the client might
>> send another request  to the daemon (though I don't have an exmaple on
>> hand yet but we may find  the need sometime). So I'll probably cut it
>> in 2 parts like a normal tux  command.
>
> Why allow the connection of clients if the id lookup is not completed ?
>
> Do you mean that the id lookup is *triggered* by the connection of a
> client that specifically requested to talk to a given Tux ? If so,
> okay, but then the client should await for an ack from the daemon
> ("ok, i've found the Tux you requested, proceed") or a nack ("sorry,
> no such Tux here").

Yes, that's what I meant. The connect_to_tux(id) function of the daemon is  
triggered by the client and the above ACK will be returned. The  
id_lookup() function is also triggered by the client and the ACK will  
contain the id that has been found or a nack is no tux is found. By the  
way, the id_lookup function can only find an unconnected tux. Practically  
that means that you switch on your tux, plug the dongle, the RF modules  
don't connect yet, id_lookup() will return the id of your tux and  
connect_to_tux(id) will initialize the RF connection. Once the client kows  
the id of your tux, you can skip the first step.

I guess you should get the point now. If you think about modifications or  
improvements, they're welcome of course.

[tuxdroid-user] usb_read_TuxDroid() correctness

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

I have comments and questions about usb_read_TuxDroid():

  (1) It uses a for loop to read data from USB, and tampers with the
      loop index within the loop's body. This is generally not a good
      idea; a while loop would be preferable in such a case.

  (2) Where does the loop's upper bound (5) come from ? Does it have
      anything to do with TUX_RECV_LENGTH, which also happens to be
      5 (but soon to be fixed) ?

  (3) The documentation[1] of usb_interrupt_read() doesn't say much,
      but I guess it may read fewer bytes than requested, and even
      return 0 in case of a timeout. This means that the loop could
      have read data in several iterations and still reset the loop
      index to 0.

[1] http://libusb.sourceforge.net/doc/function.usbinterruptread.html

I don't get what this is supposed to do. If this code is indeed
correct, it should be rewritten and/or commented.

	Damien

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

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

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

[...]
> I forgot something here. The daemon will start when the dongle is
> plugged,  will open the USB connection, but the connection to tux
> won't be  initialized. It's the client that will request to conenct to
> tux with a  specific id or do a id lookup. So during this function,
> the client is  connected to the dongle. Anyway, during the id lookup,

I didn't get this. What do you mean with "the client is connected to
the dongle" ? In my mind, a client is a program that connects to the
daemon; how could it be connected to the dongle ?

> there's nothing  else to send back to the client but the client might
> send another request  to the daemon (though I don't have an exmaple on
> hand yet but we may find  the need sometime). So I'll probably cut it
> in 2 parts like a normal tux  command.

Why allow the connection of clients if the id lookup is not completed ?

Do you mean that the id lookup is *triggered* by the connection of a
client that specifically requested to talk to a given Tux ? If so,
okay, but then the client should await for an ack from the daemon
("ok, i've found the Tux you requested, proceed") or a nack ("sorry,
no such Tux here").

>>> 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.
>
> R=C3=A9mi doesn't know neither, so you know what to do :-)

Done.

	Damien

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

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

On Sat, 02 Jun 2007 10:04:59 +0200, neimad <ror...@gm...> wrote:

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

I forgot something here. The daemon will start when the dongle is plugged,  
will open the USB connection, but the connection to tux won't be  
initialized. It's the client that will request to conenct to tux with a  
specific id or do a id lookup. So during this function, the client is  
connected to the dongle. Anyway, during the id lookup, there's nothing  
else to send back to the client but the client might send another request  
to the daemon (though I don't have an exmaple on hand yet but we may find  
the need sometime). So I'll probably cut it in 2 parts like a normal tux  
command.

>> 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;
>
> Ok, I'll repress my urges until then.

Rémi doesn't know neither, so you know what to do :-)

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