Site ELEC344/ELEC381

Partie interactive du site pédagogique ELEC344/ELEC381 de Télécom ParisTech (occurrence 2010).

Catégories

GLiP : Problème d'affichage

Lundi matin, j’ai commencé à réviser la routine d’affichage car de différents problèmes sont apparues quand on a testé la communication par IRDAs avec l’affichage. Cela est dû au fait que les 4 UARTS qui gèrent les IRDAs interrompent la tâche qui gère l’affichage. Comme résultat des petits points se voient dans les LEDS.

L’après midi, SAM à recommandé de refaire la routine de d’affichage en utilisant que l’interruption par le TIMER.

Hier soir, j’ai réussi à faire marcher le SPI en utilisant le module DMA.

Aujourd’hui (Mardi) je me suis dédié à continuer l’implémentation d’une nouvelle routine d’affichage. Par contre je suis seulement arrivé à montrer une ligne, mais pas une image complète correcte. Après d’avoir parlé avec SAM, une modification plus profonde dans ma façon de générer le PWM pour les LEDS semble d’être le problème.

GLiP : 1 pas en avant, 3 pas en arrière …

Cf post de Micka… journée assez fatigante pour peu de résultats… J’ai encore l’espoir que certains de nos problèmes viennent de l’affichage sur les leds. Mais grâce à Sam, notre dépot est plus propre  !

IrDA, paquets et … bugs !

Voici le bilan des derniers jours :

Dimanche : j’ai commencé les tests de rapidité de transferts des paquets pour la synchronisation des animations et j’avais commencé à retoucher les niveaux de couleurs que l’on affichait mais a priori ça ne servira à rien vu qu’on reprend le codage de l’affichage des couleurs…

Lundi : lundi j’ai changé la gestion des paquets pour permettre d’envoyer soit des DATA soit des commandes et ainsi éviter de surcharger les transmissions (on envoie 4 octets de données au lieu de 65 octets). Puis on l’a intégré au programme de Julie et on a commencé à tenter de débugger le tout. On s’est alors rendu compte du problème de gestion des LEDs qui entrait en conflit avec l’IrDA et provoquait des glitchs et possiblement des bus fault. Sam nous a donc expliqué qu’il fallait qu’on modifie les priorités des tâches et des interruptions. Malheureusement cela n’a pas suffit et Enzo s’est mis à recoder la gestion des LEDs pour utiliser le DMA.

Mardi : avec Julie on a tenté de débugger le programme de gestion de l’initialisation… pour se rendre compte que dijkstra posait problème à cause de la map de départ. On a aussi choisi de débugger par port série pour éviter d’utiliser les LEDs, a priori par port série tout fonctionne bien et on a un programme plus propre et plutôt efficace pour les 2 premières étapes. Avec Sam on a pu modifier le Makefile pour éviter de copier-coller nos fichiers tous les 2 jours et partager plus simplement nos bibliothèques.

Il nous reste encore à débugger la fin du programme et à trouver le problème des LEDs …

Serpentina : jeudi et vendredi

Jeudi et vendredi derniers, moi et Flavia, on a travaillé sur la communication can de la carte du serpent (entre deux cartes du Tp, le can marchait bien). On ne savait pas la raison (on pensait aux interruptions), mais toujours il y avait quelque chose qui bloquait son exécution. Peu à peu, on a trouvé des morceux de code qui ne nous posaient pas de problème et enfin on a fini par bien transmettre des trames. Juste l’interruption pour la transmission ne marche pas mais on peu envoyer des données quand même.

Ensuite, on s’est lancé à la réception des trames can. Toujours, quand on activait toutes nos tâches, la carte se bloquait. Donc, on a essaie d’utiliser juste une tâche de réception. Après mettre beaucoup de temps pour bien configurer notre carte du Tp et faire des tests, la réception a bien marché avec des interruptions et des masques.

Pendant cette recherche des solutions pour la communication can, on a trouvé un autre problème (peut-être celui qui nous posait des problèmes pour le can) qui ne nous semble pas être simple : on est limité à lancer juste trois ou quatre tâches maximum (cela dépend de ce qu’on configure/initialise). On ne connait pas la raison (on a parlé à Sam, mais il ne le sait pas non plus), et on est maintenant bloqué dans cette partie.

J’ai essayé d’utiliser le code de l’année dernière (juste la configuration des clocks et des leds pour savoir si la carte se bloque ou pas) avec notre bibliothèque STM32 et notre linker, et le blocage continue.

Demain, je continue à chercher une solution pour ce blocage.

GLIP : Programme d’affichage et soudage de cartes

Lundi 12 :

J’ai passé la matin dans le nettoyage du code et j’ai commencé avec la modification de la premier version du programme pour l’affichage d’animations, le travail avec une table de couleurs et la reconnaissance du format envoyé par le programme de Micka (gif2glip). Mon travail dans cette étape a été plutôt de conception (comment allait se comporter le programme).

Étant donné que je ne connait pas python, j’ai passé l’après midi en train de me documenter. Avec l’utilisation d’un éditeur hexadécimal, j’ai pu voir les octets qui conforment le fichier GLIP. Cependant, comme dans cette étape du projet la copie des octets qui conformaient la table de couleurs, les images à montrer, etc; allait être fait directement dans le code à programmer dans le STM32, à la main, j’ai considéré que cela serait mieux de les avoir dans un fichier de type .txt. De cette façon, vers la fin de la journée, et avec l’aide du programme de Julie (une petite explication de Julie inclut), j’ai créé un programme qui me permettait voir en code ascii les octets envoyés.

Mardi 13 :

La matin, j’ai finalisé avec l’implémentation du code de la premier version du programme d’affichage avec une table de couleurs.

L’après midi j’ai parlé avec SAM pour qu’il m’aide avec quelques doutes que j’avais, mais il m’a fait noter que ma solution d’affichage était trop compliqué (beaucoup de pontiers, pas de sémaphores, etc) et il m’a expliqué de manière général l’idée de fonctionnement de son propre programme de test. Alors, j’ai passé l’après midi dans la création d’un deuxième version du programme d’affichage. Mon idée était d’intégrer dans le comportement certains aspects de la premier version du programme. Vers la fin de la journée j’ai eu cette deuxième version finalisé (affichage d’images statiques et dynamiques, sans table de couleurs).

Mercredi 14:

Je suis passé la toute la journée (littéralement) avec Alexis, Florent, Micka et Julie en train de souder les nouvelles cartes GLIP.

Vers 20h j’ai crée un programme qui permettait tester les LEDS des nouvelles cartes. Moins d’une heure après la deuxième version du programme, avec l’inclusion d’une table de couleurs était finalisé: Une animation à été créé pour tester que cette version marche correctement.

Serpentina : contrôle d’un moteur

Hier j’arrivais à écrire dans la flash avec le bootloader de l’année dernière, par contre mon propre programme ne marchait pas.

Aujourd’hui, pas-à-pas, Flavia et moi, on a testé d’abord la configuration des leds et ensuite celle du moteur. Quand on a bien configuré la sortie du moteur, il y a avait juste une petite erreur dans le PWM qui génerait cette sortie, problème qu’on a résolu avec l’aide de l’oscilloscope. La prochaine étape était mettre un moteur en marche à un angle désiré, ce qui a été fait sans soucis.

Ensuite, on a ajouté le can qui était déjà configuré et parciellement testé (pour vérifier les envoies des trames CAN). Dans cette partie, parfois notre carte plante. On essaie de faire un debug du programme pour trouver exactement où se trouve l’erreur.

Prochaines étapes : vérification de la réception des trames CAN par les cartes des vertèbres, soudage des cartes dans les vertèbres, tests du serpent.

IrDA fonctionnel !

Aujourd’hui je me suis attaqué à la configuration de l’IrDA. Après quelques déboires avec le port série de debug, l’IrDA fonctionne très bien à la vitesse maximale supportée par les LEDs infrarouges : 115,2Kbps. Le transfert s’effectue très bien et on s’est aperçu que l’angle d’ouverture du signal transmis est assez faible et donc peut-être qu’on n’aura pas besoin de mettre des caches …

Le transfert de paquet est juste à adapter à l’IrDA donc d’ici demain cela devrait fonctionner correctement.

J’ai fini par rechercher une manière de calculer le CRC16 d’un paquet et j’ai trouvé une bibliothèque qui le calcule et que je pourrais implémenter au stm32.

Premier test du usart GLip

Hier soir (Dimanche 11) j’ai fait un petit test sur les périphériques de communication de la carte de LEDS.

J’ai ajouté à mon programme d’affichage une routine d’interruption par uart 3 (et après pour le uart 1 et 4 aussi), pour qu’il change l’image montré à chaque fois que le module recevait quelque chose dans le porte serial: J’envoyais un caractère depuis une porte et le recevait par une autre (en utilisant une feuille blanche), et après j’envoyai et recevait dans le même porte en utilisant un miroir. Dans le deux cas, il à commencé à interrompe correctement.

Par contre quand j’ai voulu ajouter une condition et voir si effectivement je recevait  ce que j’envoyais, je trouvé qu’il y avait un problème.

En utilisant un multimètre je constaté que le PIN de réception du STM32 était toujours à zéro. Je n’ai pas continué avec le test parce que j’ai pensé qu’il serait mieux de voir qu’est-ce qui se passait avec un oscilloscope.

Mes routines d’affichage d’une image, et ceux du test ont était ajoutés au dépôt du groupe.

Communication et harmonie...

Hier, j’ai harmonisé le code qui avait été codé par chacun d’entre nous et donc avec différentes conventions… ça a ainsi permis au groupe d’arriver à un concensus sur la structure du code.

Aujourd’hui, j’ai enfin réussi à faire marcher la communication par l’UART1, et j’ai donc pu afficher les données filtrés de l’accéléromêtre et du gyroscope, ayant ainsi la confirmation que le code global fonctionne bien.

Ensuite, j’ai fait une fonction qui teste l’identifiant de la carte, pour qu’on ne puisse pas faire fonctionner le code prévu pour la carte logique sur une carte IMU et inversement. Cette fonction focntionne bien.

A l’arrivée de Daniel, nous avons pu tester mon code sur une carte IMU, nous avons bien réussi à allumer les LEDs simplement en changeant le #define dans le fichier de configuration global.

Nous avons eu pas mal de problèmes avec le bluetooth qui ne fonctionnait même plus avec la carte IMU. Nous avons finalement réussi à le faire fonctionner sur la carte logique! Il nous a semblé que les coordonnées que l’on additionne n’étaient plus les bonnes (on additionne le x de l’accéléromêtre avec le y du gyroscope). Daniel fera plus de tests et corrigera les calculs demain.

Et moi, je vais pouvoir me lancer dans le codage du LQR!

Avancement 09/04

Aujord’hui j’ai fait d’abord la configuration du PWM des deux broches (vers les deux moteurs de chaque vertèbre). La largeur du pulse est en fait le duty cycle (ça je ne comprenais pas trop avant…). Pour les tester, j’ai montré sur le LCD le résultat du calcul de la largeur du pulse et j’ai vérifié sur les leds (qui étaient branché sur les mêmes sorties) qu’il y avait une variation de l’intensité de luminosité.

Ensuite, j’ai travaille un peu plus sur la routine qui reçoit sa position, fait le calcul de celle de la prochaine vertèbre et le lui envoie. Pour cela, j’utiliserai au moins une file pour faire la synchronisation.

Par fin, je me suis lancé dans le bootloader, pour pouvoir flasher un programme et faire le « test d’un seul moteur » (étape du diagramme de Gantt). Mais j’ai eu un soucis parce que je ne comprenais pas trop le bootloader de l’année dernière (qui flashe toutes des 10 dix cartes en parallèle). Jon me l’a expliqué (merci, Jon) et je me suis lancé dans l’écriture du code pour utiliser celui de l’année dernière.