From: Olivier Matz Date: Thu, 31 Oct 2013 18:50:03 +0000 (+0100) Subject: save some documentation in notes.txt X-Git-Url: http://git.droids-corp.org/?p=protos%2Fxbee-avr.git;a=commitdiff_plain;h=77bb6b12d54cdf65955a57cb897727b156685a82 save some documentation in notes.txt --- diff --git a/notes.txt b/notes.txt new file mode 100644 index 0000000..f8c697a --- /dev/null +++ b/notes.txt @@ -0,0 +1,161 @@ +dump xbee stats +=============== + +read rf-errors +read good-packets +read tx-errors +read tx-ack-errors # does not work +read rx-signal-strength +read duty-cycle +read rssi-for-channel # does not work + +configure xbee module +===================== + +write bcast-multi-xmit 0 +write unicast-retries 0 +write power-level 0 + +radio protocol +============== + +- tout en network order +- avoir le paquet le plus petit possible +- grouper les informations en un paquet si possible. certaines infos + non critiques pourraient attendre en file qu'un paquet de même + puissance sorte + +Octet 1: type + +- si type est < 0x3f, alors il s'agit du bitmask des servos qui seront + présents dans le corps. Les servos sont présents par blocs de 10bits. + la puissance d'émission est également embarquée sur 3 bits. + Cette commande doit être bien compacte car c'est celle qui va être + envoyée le plus souvent. + + Exemple, on veut envoyer le servo 0 (=0x123) et 4 (=0x234). Puissance = 2. + + type = 0x5 + seq_num sur 5 bits + puis pow sur 3 bits + puis val[0] sur 10 bits + puis val[2] sur 10 bits + padding à 0 pour arondir sur un octet + + -> 0x11 0x9 0x1c 0x68 + +- sinon, type correspond à la commande qui est mappée sur une structure + +rc_command +---------- + +- on récupère l'état du PPM provenant de la télécommande en tache de + fond (période 20ms pour chaque servo, et les servos arrivent les + uns après les autres) + +- toutes les 1 à 5ms + + - on compare les valeurs ppm aux dernières valeurs envoyées: si + elles sont différentes: + + - on les stoque en mémoire dans "valeurs à envoyer" + - on incrémente un numéro de séquence de cette structure sauf si + le dernier numéro d'acquitement reçu est trop ancien + + - si le numéro de séquence est différent du numéro de seq reçu, + et que le dernier paquet a été émis il y a plus de 30ms, on émet + les nouvelles valeurs et le numéro de séquence local + +- lorsqu'on reçoit un paquet d'acquitement, on stoque le numéro de + séquence + +- lorsqu'on reçoit un paquet de stats, on le traite (affichage, beep, + log, osd) + +- lorsqu'on reçoit un paquet de "ping", on note le RSSI et la puissance + à laquelle il a été émis. + +- la puissance d'émission est choisi avec l'algorithme suivant: + + - si on n'a pas reçu d'acquitement ou de ping depuis 500ms, alors + on émet alternativement à 0 et 4. + + - sinon, on émet à la puissance la plus faible qui a un RSSI supérieur + à un seuil, ce que l'on peut déterminer grâce au ping. + +wing +---- + +- lorsqu'on reçoit un paquet de commande + + - on met à jour les valeurs des servos + - si le dernier paquet d'acquitement a été émis il y a plus de 200ms + on émet un paquet d'acquitement. La puissance d'émission du paquet + d'acquitement est la même que la puissance du paquet reçu. + +- toutes les 500ms, on émet un paquet de "ping" à une puissance + différente (0 à 4). La puissance est contenue dans le message. + +- toutes les 100ms, on émet un paquet de stats à la puissance du dernier + paquet reçu. + +interrupt, software interrupts and background tasks +=================================================== + +problem description +------------------- + +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. + +solution +-------- + +xbee rx and timers should be executed in a low prio scheduler +event. With this modification, the command line can block. However we +must prevent a xbee transmission to be interrupted by a task doing +another xbee transmission. For that, we will use scheduler_set_prio(). + +The problem with that is that we can loose precision for low prio +events if the scheduler interrupt occurs when the scheduler priority +is low. It could be fixed in scheduler, but maybe we don't need it. + +Priorities +---------- + +From highest to lowest priority. + +- Interrupts: + + - timer + - uart + - spi + - i2c + +- 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 + structure updated by i2c, and writing commands using + spi_set_servo() + - XBEE_PRIO: read pending chars on xbee serial line and process xbee commands, + send xbee commands. + - I2C_PRIO: send requests and read answers on i2c slaves + - CALLOUT_PRIO: calls low priority events using the callout + code. This method allows to execute timers with a fixed period + without drift. Even if the event cannot be executed during some + time, periodical events will keep the proper period. + +- Main loop: + + - command line + +Rules +----- + +Calling a xbee function needs to set prio to XBEE_PRIO only. +Calling i2c_send_command must be done from a lower prio than I2C_PRIO. diff --git a/rc_proto.c b/rc_proto.c index 528fa84..a910b47 100644 --- a/rc_proto.c +++ b/rc_proto.c @@ -16,9 +16,6 @@ #include "rc_proto.h" #include "main.h" - - - struct power_levels { int ttl; int power_db;