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 …

Avancement GLiP

Pendant la fin de la semaine dernière, j’ai fini le bootloader pour les GLiPs, piloté par la carte de TP. Je n’avais que deux blocs à ma disposition mais il semblait bien fonctionner. J’ai maintenant beaucoup plus de doutes quand je vois tous les problèmes que l’on rencontre avec 4 blocs !…

Dans l’hypothèse où un GLiP serait directement relié au PC par port série, j’ai aussi écrit (aujourd’hui, mardi) une interface en Python pour le flasher via port série, puis transmis par IrDA. Je n’ai pas pu tester ce mode.

Hier, j’ai regardé avec Julie les différents problèmes que l’on rencontre lors de l’initialisation de la carte. La majorité des problèmes sont du à la communication IrDA plutôt hasardeuse et peut-être à des problèmes de priorités entre les tâches qui gèrent l’IrDA et l’affichage par LED. (cf posts à venir de Mika et Enzo)

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.

Avancé gestion des paquets & crc

Aujourd’hui j’ai continué à configurer le module led pour les transferts de paquets complets. J’ai de plus nettoyé un peu le code qui à force de copier coller devenait très sale !

Les paquets sont donc complétement transmis et ce entre trois IrDA différentes en transmission-réception quasi simultanée donc la prise en charge du half duplex semble correcte. De plus, je me suis aperçu que pour l’instant et malgrè l’utilisation de réflexions, il n’y a aucune erreur de transmission donc c’est plutôt positif quant à la fiabilité des transmissions.

Enfin j’ai tenté de décrypter l’algorithme du crc et j’ai du mal à trouver un algorithme fonctionnel et bien détaillé (tous mes tests même à la main ne me donnent pas de résultat correct…) donc je suis toujours en train de coder quelque chose qui fonctionne !

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.