With the creation of the middleware forum I want to move the discussion on tux driver to this forum.
Older info can be found at http://www.tuxisalive.com/tux-droid-forum/copy_of_forumtopic1/896237192 but please do not append to that thread any more.

I have committed some new changes. From memory:
- factoring out common code by introducing common helper functions
- removed the tokenizing in tux_sound_flash.c (using a generic tokenizer function from tux_cmd_parser)
- simplified the detection of the sound device format (the vid/pid will tell what the tux is and the audio is always device 0 on the card)

Things that I am still considering:
- separating the textual part from the C part
(but code like this: ret = tux_cmd_parser_insert_delay_command(to, "TUX_CMD:WINGS:OFF", true); in wings.c complicates things)
- maybe make the time as integer and not as float (at least internal): integers are more efficient on small embedded processors (like the one used in NSLU2 )
(actually maybe some other parts could made int too)

If you feel other things might need rework, drop a line here stating it.

Btw also a question on tux_leds.c:
I see several checks where the code checks if the value is smaller than 0 or 1 and if so adjusts accordingly.
However not all these checks check for upper bound. Is this intentional?
example: in tux_led_pulse() there is:
    if (toggle_count <= 0)
    {
        toggle_count = 1;
    }
but no upper bound check. Should it be there?
This also applies to some other vars (e.g. delay).
Opinion of an expert is appreciated.

FM

A few more things.

First let me clarify that I am not an employee of Kysoh or so (although maybe some of my posts could create that impression).
I am just a enthousiast tuxdroid user who is interested in playing with it and I happen to have some linux and embedded programming experience. So for me this is just about having fun; making something nice etc.

Don't bother asking me questions about when the V2 middleware will be completed, what exactly will be in it, when tux v2 will arrive or whatever. I simply do not know.

After having said that let's go back to the fun stuff. The driver.

Currently the new tux_driver is not really a driver at all (at least not what I consider to be a driver).
The fux communicates with the host os over usb. The current code does allow sending commands to the tux (over usb to fux then wireless to tux). But on the upper side it is more like a library with functions. You can write an app and control the tux (and if desired it is definitely possible to use hotplug or so to launch this prog when the fux is inserted).

If we want multiple apps to be able to use the tux at the same time additional work might be needed.
E.g. maybe some datastructures need to be moved to shared memory.

Alternately the lib could be turned into a complete driver. It would not be too difficult to make code that (just like the current tuxd driver) reads from a socket, then uses the lib to send to the tux).
Actually the current tuxd uses a dedicated interface/protocol over TCP to pass requests from app to driver and tux.
We could go for the same protocol, but we could also decide to move to a mechanism like REST (http://en.wikipedia.org/wiki/Representational_State_Transfer) or maybe something else (RPC, web services, ...) (or even multiple versions).

What is your opinion on this?

Best regards, FM

PS: for those curious about my nick and the weird capitalisation: I have a long name which is difficult to pronounce for foreigners and decided online to abbreviate it to my initials (FM). However as in a lot of places this name was either too short to be possible or already taken, I extended to eFfeM where you say it just like you would say the letters F and M after each other).
(and if you are even more curious: my first name is Frans and my nationality is Dutch).

I'm really interested in this new driver, but I did not got time to have a deep look at it.

That said, I wanted to start something that should be able to communicate with the tuxdroid through d-bus.

D-Bus is used in almost every linux desktop (gnome, kde, ...), there are many language bindings, ... many features, that fits well with a droid driver.

So, I will try to find some time and maybe start to add a dbus layer ontop of your new driver.

And if your library is well constructed, I imagine it should be possible to have a generic daemon with many pluggable communications interfaces.

Hi,

Yes, tux_driver is not really a driver It's a shared library which drives Tuxdroid. Tux_driver comes from the middleware of the new architecture. Tux_driver is not designed to work standalone, it will be used in a service/daemon which offering an API, based on REST architecture. I made some tests of HTTP server in python, and the REST arch with XML by HTTP protocol seems to be a good choice. Others interfaces could be added in the futur.

Progress from today: I've split the driver into smaller helper functions. This makes things more readable and maintainable.
Next step is to move the rest of the string parsing to this function (so e.g. no str_to_* functions in tux_eyes.c).
This gives a better separation of the parser code and the functional code.