Simple non-threaded current state type interface to Wiimotes

[amp]

I think it would be nice to have a simple interface to the wiimote that does not require writing a callback.

I have implemented such an API. It is as follows:

/**
 A callback that saves the most recent message of each type. It is very useful for program that 
 only need the current state (not the changes in state) and don't want to deal with threading.

 There is a race condition in the message copies into wiimote_saved_messages[]. A reader could read
 the message while it is being updated resulting in reading half old and half new data. I don't think
 this will be a big issue. The new and old values will likely be very close to each other and there 
 is no temporary values written to wiimote_saved_messages[]. However if this is a problem maybe a lock
 should be added or people who need accuracy should use the event API.
*/
void wiimote_save_messages(int, int, union wiimote_mesg* []);

/**
 The values saved by wiimote_save_messages(). The data for a given wiimote is in "wiimote_saved_messages[id]".
*/
extern struct wiimote_mesg_set wiimote_saved_messages[];

where wiimote_mesg_set is a structure containing all the message structures. This can be used as follows:

wiimote = wiimote_connect(&bdaddr, wiimote_save_messages, &wiimote_id)

while( true ) {
  printf("Acc: x=%d, y=%d, z=%d\n", wiimote_saved_messages[wiimote_id].acc_mesg.x,
                                    wiimote_saved_messages[wiimote_id].acc_mesg.y,
                                    wiimote_saved_messages[wiimote_id].acc_mesg.z);
  usleep(100*1000);
}

I have attached a patch against svn trunk. It also includes a modified version of wmdemo that uses the API.

[amp]

Patch to add this feature

[martin.wickman@…]

Did you consider adding a queue of messages to this callback? That, and a function wiimote_get_mesg() could be used to create a simple polling system. Make sure each message is tagged with a timestamp though.

I would love to see a polling interface in cwiid. It pretty much sucks using event callbacks in a real-time situation (such as games).

[dsmith]

This is in the works (in my head, at least). Check the Development thread later today for a post of my ideas for a way to support callback, blocking, and state-based interfaces (as well as simplify the internal threading model which has gotten a little out of hand, IMO).

[dsmith]

See Forum: Dev/API Changes.

[dsmith]

state interface added (r101)