ELECINF344/381

Partie interactive du site pédagogique ELECINF344/ELECINF381 de Télécom ParisTech (occurrence 2011).

Catégories

Copterix : communications

Depuis mercredi, je me suis occupé d’implémenter la communication via UART entre STM32 et Linux.

Comme nous ne disposions ni de la gumstix parfaitement fonctionnelle, ni du STM32, j’ai commencé à communiquer entre ma carte de TP et mon ordinateur, via un cable micromatch 4 / USB.

J’ai commencé par réaliser la partie du code du STM32, sous FreeRTOS. Je me suis alors rendu compte que contrairement à ce que je pensais, le protocole XModem n’était pas vraiment adapté à ce que je voulais, mais qu’il y avait dans celui-ci de bonnes idées, il a donc constitué un très bon départ pour un protocole maison. Voici le protocole que j’ai finalement adopté :

Les données à envoyer sont regroupées au sein de structures C (une pour l’ensemble des données des capteurs, une pour l’ensemble des commandes des moteurs). On envoie les données structures par structures, de cette manière :
On commence par envoyer un octet qui caractérise le paquet (dans notre cas, j’ai choisi 0×03 si c’est les données du capteur, 0×01 pour les commandes moteur, 0×02 pour les commandes RF). Ensuite on envoie la structure, octet par octet, sachant que l’émetteur et le receveur connaissent la structure, donc sa taille, et donc le nombre d’octet attendu. Enfin, on envoie un checksum, constitué de la somme de tous les octets modulo 256. Le récepteur va ensuite vérifier le paquet reçu avec le checksum, et l’utiliser s’il est correct, l’ignorer sinon : il n’y a pas de renvoi des paquets erroné, car cela me semble inutile, vu l’aspect temps réel des paquets échangés.

Du coup, on peut se passer d’acquittement, ce qui nous permet de fonctionner en full duplex : on devrait pouvoir envoyer les données des capteurs et recevoir les données des moteurs en même temps.

Hier donc, j’ai codé la partie STM32 (sauf les commandes RF, il faudra que je les rajoute après), puis j’ai vérifié, en dialoguant avec le PC via des scripts Python, que cette partie fonctionnait correctement.

Aujourd’hui, je me suis occupé de la partie côté Linux, en C : j’ai implémenté le protocole de réception, pour stocker les données reçues dans la structure correspondante. Ensuite, j’ai mis en place une communication 0MQ basée sur le système de Publisher/Suscriber : le module de réception publie ainsi chaque update. J’ai également créé un programme qui souscrit à ces updates, et les affiches : ses fonctions pourront être intégrées au filtre de Kalman, pour qu’il puisse souscrire aux updates.

Il me reste donc à implémenter le module d’émission côté Linux, à ajouter les paquets provenant du module RF, et je pense qu’ensuite j’aurais intérêt à faire quelques simulations pour estimer le taux d’erreurs, ainsi que le taux d’erreurs non détectées.

 

Sur le même sujet :

  1. Architecture logicielle de Copterix
  2. Communications internes et externes
  3. Copterix : FQA, PCB et Communication avec le STM32
  4. Copterix : PID & Uart
  5. Copterix : Architecture

Commentaires fermés.