problem description
-------------------
-Today, Both command line code, xbee char reception and callout events
+Today, both command line code, xbee char reception and callout events
are handled in the main loop, with the lowest priority. Therefore, the
command line cannot block, else the timers + xbee rx won't be executed.
+A typical example where the command line blocks is the completion with
+many choices.
+
solution
--------
- Events, called from timer interrupt after a call to sei():
- LED_PRIO: led blink
- - TIME_PRIO: monitor time
- BEEP_PRIO: process beep requests and modifies the beep_mask
- SPI_PRIO: send and receive SPI data to the atmega168p
- CS_PRIO: do the control system of the wing, reading infos from a
xbee_neighbor.[ch]: helper to add/delete neighbors, use malloc()/free()
xbee_rxtx.[ch]: parse rx frames, provides xbee_proto_xmit()
xbee_stats.[ch]: helper to maintain stats
+
+App
+---
+
+move this in library ?
+
+xbeeapp_send(addr, data, len, timeout, cb, arg)
+XXX to detail
+
+Timeout for xbee commands
+=========================
+
+- send_atcmd or send_msg (xbee_prio)
+
+ - allocate a channel and a context
+ - fill the context with info
+ - send the message
+ - load a timeout (xbee_prio)
+
+- on timeout (xbee_prio)
+
+ - log error
+ - call the cb with retcode == TIMEOUT
+ - unregister channel
+ - remove timer
+ - this could be a critical error
+ - if it's a comm error, it's ok
+ - but if the channel is registered again and 1st callback finally occurs...
+
+- on rx (xbee_prio)
+
+ - if there is a context, it's related to a query:
+ - remove the timeout
+ - unregister channel
+ - do basic checks on the frame
+ - log (hexdump)
+ - the frame must be checked in the cb, we can provide helpers
+
+
+Todo
+====
+
+- move callout in an aversive module
+- move xbeeapp in xbee module
+
+