tux-droid-user

Re: [tuxdroid-user] [tuxdroid-svn] Duplicate enum

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

On Sat, 16 Jun 2007 14:25:08 +0200, neimad <ror...@gm...> wrote=
:

> Enum usb_tux_connection_t (USBDaemon_usb_enum.h) seems to duplicate
> most of enum tux_connection_t (USBDaemon_status_table.h):
>
>     typedef enum
>     {
>         USB_TUX_CONNECTION_DISCONNECT =3D 1,
>         USB_TUX_CONNECTION_CONNECT =3D 2,
>         USB_TUX_CONNECTION_ID_REQUEST =3D 3,
>         USB_TUX_CONNECTION_ID_LOOKUP =3D 4,
>         USB_TUX_CONNECTION_CHANGE_ID =3D 5,
>         USB_TUX_CONNECTION_WAKEUP =3D 6,
>         USB_TUX_CONNECTION_WIRELESS_CHANNEL =3D 7,
>     } usb_tux_connection_t;
>
>     typedef enum
>     {
>         TUX_CONNECTION_DISCONNECT =3D 1,
>         TUX_CONNECTION_CONNECT =3D 2,
>         TUX_CONNECTION_RANDOM =3D 3,
>         TUX_CONNECTION_ID_REQUEST =3D 4,
>         TUX_CONNECTION_ID_LOOKUP =3D 5,
>         TUX_CONNECTION_CHANGE_ID =3D 6,
>         TUX_CONNECTION_SLEEP =3D 7,
>         TUX_CONNECTION_WAKEUP =3D 8,
>         TUX_CONNECTION_WIRELESS_CHANNEL =3D 9,
>     } tux_connection_t;
>
> They seem to represent the same thing, so I think we should get rid of=

> one of them.
>
> 	Damien

Indeed for now they look rather the same but the second ones are at a  =

higher abstraction level.
usb_tux_connection_t are all commands supported by the USB dongle and th=
e  =

values for the USB frames so these defines can't be chnaged. There's a  =

dedicated command (first byte of the USB frame) group for all these  =

commands.
tux_connection are the commands made available to the end user through t=
he  =

api. Most of them are similar though it's not a simple call of the usb  =

functions. And we can offer more commands here that will never be  =

implemented in the USB dongle, like the random connection. It would also=
  =

be possible to have some USB commands not made available to the end user=
  =

but used as primitives by other user commands.

Actually we should have the same kind of similarity between all commands=
  =

sent to tux (commands.h) and all commands available through the api. Rig=
ht  =

now they're pretty much the same but I'd like to add more and more high =
 =

level functions in the daemon that will use the same basic set of tux  =

commands.

Now that I pointed out the difference, improvements on this are welcomed=
  =

of course.
If I rewsrite the usb files as a usb module, usb_tux_connection_t should=
  =

be private to the module and should be the basis for the USB interface a=
s  =

it's part of the functionalities of the USB dongle. This is hardware  =

driven so should be quite static.

On the other hand, we do whatever we want with tux_connection_t. If we  =

redesign the structures, we should also find a way to organize all  =

functions supported by the daemon, and these included.

David

Re: [tuxdroid-user] [tuxdroid-svn] Duplicate enum

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

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

[...]
> Now that I pointed out the difference, improvements on this are
> welcomed  of course.
> If I rewsrite the usb files as a usb module, usb_tux_connection_t
> should  be private to the module and should be the basis for the USB
> interface as  it's part of the functionalities of the USB dongle. This
> is hardware  driven so should be quite static.

Making usb_tux_connection_t private would help indeed ;-) As for the
usb module, I'm all for it - see my post <87v...@gm...>
(in thread "Daemon to USB connection").

> On the other hand, we do whatever we want with tux_connection_t. If we
> redesign the structures, we should also find a way to organize all
> functions supported by the daemon, and these included.

Btw, aren't these _commands_ (tux_connection_t, at least) ? And thus,
shouldn't they be named tux_cmd_t or something ? Right now they sound
like connection operations only, whereas they're not. And this will be
even more true in the future, with more high-level operations, as you
describe. (Not high priority, so this may be postponed to after we've
cleaned up the usb stuff.)

	Damien

Re: [tuxdroid-user] [tuxdroid-svn] Duplicate enum

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

On Sat, 16 Jun 2007 19:40:26 +0200, neimad <ror...@gm...> wrote:

> "David Bourgeois" <da...@ja...> writes:
>
> [...]
>> Now that I pointed out the difference, improvements on this are
>> welcomed  of course.
>> If I rewsrite the usb files as a usb module, usb_tux_connection_t
>> should  be private to the module and should be the basis for the USB
>> interface as  it's part of the functionalities of the USB dongle. This
>> is hardware  driven so should be quite static.
>
> Making usb_tux_connection_t private would help indeed ;-) As for the
> usb module, I'm all for it - see my post <87v...@gm...>
> (in thread "Daemon to USB connection").

I didn't reply to your post yet as I've still to dig into this first, but  
I'm already converted to your usb module approach, that's where my  
statement came from actually :-)

>> On the other hand, we do whatever we want with tux_connection_t. If we
>> redesign the structures, we should also find a way to organize all
>> functions supported by the daemon, and these included.
>
> Btw, aren't these _commands_ (tux_connection_t, at least) ? And thus,
> shouldn't they be named tux_cmd_t or something ? Right now they sound
> like connection operations only, whereas they're not. And this will be
> even more true in the future, with more high-level operations, as you
> describe. (Not high priority, so this may be postponed to after we've
> cleaned up the usb stuff.)

Yes they are commands, but these are special as they deal with the RF  
connection (connect, disconnect, wakeup) and don't follow the same  
protocol as standard commands (eyes, mouth, leds, etc.) They're managed by  
the 2 RF modules, and tux (the core and audio CPUs) don't have any clue  
about these directly. So they can be mixed with other commands from a user  
point of view but they still make a category of their own. I don't mind  
merging them in a tux_cmd_t. I think we'll have the opportunity to discuss  
this structure when dealing with the api. I'll make a list of all hardware  
commands (handled by tuxdroid) and all end user functionalities we already  
have.

David