Site ELEC344/ELEC381

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

Catégories

Avancées depuis mercredi

Ça faisait quelques temps mais voici une mise à jour :)

Mercredi et jeudi ont été quasiment entièrement réservés à la soudure des composants de nos cartes ! Mise à part jeudi matin langues obligent.

Vendredi nous avons testé les cartes et commencé à encoder des animations pour les visualiser sur les blocs. On a ainsi pu voir que les couleurs devaient être retravaillées et le script gif2glip a été adapté pour permettre de générer le code d’affichage par lui-même. Merci à Sam pour l’adaptation du Makefile :)

Aujourd’hui j’ai continué les tests de transfert par IrDA et à présent nous avons un transfert de paquets fonctionnel avec calcul du checksum et vérification de la validité des paquets transmis. Bon point très peu d’erreurs de transmission après quelques tests.

On a de plus mesuré le temps de transfert d’un paquet entre 8 blocs et ce temps est quasi instantané donc le transfert est plutôt efficace.

Par contre nous avons dû faire face à un nouveau problème : le signal émis par l’IrDA passe en dessous des cartes et nous allons donc devoir mettre des caches aussi sous les cartes pour éviter qu’un bloc soit court circuité par ses voisins.

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.

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 !

Résumé des jours précédents

Celà fait quelques temps que je n’ai pas posté, je vais donc résumer ce que j’ai fait ces derniers jours :

  • Vendredi : j’ai testé (toujours avec le simulateur en python à base de threads, queues, etc…) les derniers algorithmes pour l’initialisation de GLiP (choix de l’orientation, …) ; j’ai commencé à intégrer les différents algos, qui étaient testés indépendamment, dans un simulateur « global » pour voir les éventuels problèmes de transition entre les différentes étapes (temps d’attente, critère de passage à l’étape suivante)
  • Lundi : j’ai continué et fini la simulation globale, j’ai réfléchi à une façon de détecter les « faux voisins » (blocs séparés d’un vide, qui captent leurs signaux réciproques, cf post de Julie) mais ma solution n’a pas été retenue au final !…
  • Mardi : j’ai implémenté en C les mêmes algorithmes afin de les mettre sur les cartes mais de nombreuses questions sont encore en suspens (API pour l’envoi/réception de messages IrDA notamment)… Je me suis aussi renseigné sur la façon de générer un ID unique pour les blocs sans avoir à les programmer un par un : Alexis avait évoqué un identifiant unique pour chaque STM32 (décrit section 28.2 du manuel de référence) que j’ai essayé d’exploiter sur ma carte de TP. Ce fut un échec puisque je n’ai réussi à lire que des « 1″ dans le registre concerné. Après quelques recherches, je suis tombé sur ce post sur le forum de ST qui explique que seuls les micro-contrôleurs produits après 2008 exploitent ce registre. Sans être sur de moi, je pense avoir lu sur le chip que les notres ont été produits en 2009 donc on devrait pouvoir accéder à cet ID… À confirmer et, le cas échéant, ça serait une bonne façon de déterminer les ID de chaque bloc GLiP.

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.

GLiP : carte et solutions

Nous avons aujourd’hui trouvé une solution au problème de la dernière fois : quand il y a un « trou » entre deux blocs, ils croient qu’ils sont voisins. On n’a abandonné l’idée de trouver l’erreur pour pouvoir la corriger. Au lieu de ça, on intègre l’erreur : l’algorithle d’établissement de la carte consiste à comparer deux graphes (celui des positions et celui des blocs réels) et à les mettre ensemble. Lorsque deux blocs se croient voisins alors qu’ils ne le sont pas, on n’arrive pas à trouver un isomorphisme entre les deux. Il suffit donc de modifier le graphe des positions. Ainsi, lorsque deux positions sont séparées par un « trou », on dit quand même qu’elles sont voisines.

On a donc maintenant toute la partie d’initialisation : élection d’un leader, orientation, établissement de la carte. Pour établir la carte en cours d’animation, seule la partie portant sur le choix de l’orientation diffère de l’initialisation.

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.

Affichage d’images dans GLiP

Je décrit mes activités et avances de hier 9 avril et aujoud’hui:

Hier, j’ai fini une premier version du code d’affichage (En fait j’ai pris les recommandations d’Alexis et Sam pour ajuster mon idée originale). Mon code utilise les interruptions par SPI (transmission) et Timer2 (mode counter). Ce dernier travaille à 8KHz, ce qui représente la fréquence de ligne des modules. Je suis arrivé à faire allumer une ligne de la matrice (ce qui signifie que ma configuration du SPI était bien), mais pas à faire marcher l’affichage dans le module complète (mauvaise configuration du Timer 2).

Aujourd’hui j’ai utilisé environ deux heures pour corriger la configuration du Timer 2, faire une test de couleurs (pour vérifier que la matrice montre les couleurs exactes que je voulais montrer) et créer une fonction qui actualise l’image que se montre dans la matrice.

Finalement le code  est capable maintenant de montrer une image fixe et grâce à la fonction d’actualisation, on pourra gérer aussi les animations. Il manque maintenant faire le lien entre le code de Micka (celle des animations) et le mien!

Envoi de paquets

Alors hier et aujourd’hui j’ai travaillé sur les communications entre les blocs. Donc le bilan est qu’aujourd’hui les cartes s’envoient des paquets, les identifient et les écrivent. Il manque juste le calcul du checksum et la validation des paquets.

J’ai aussi (enfin) trouvé d’où venait un problème de bus fault qui me suivait depuis le challenge :) Donc je sais pourquoi je buggais au challenge et sur les communications.

Normalment demain le checksum devrait être mis en place et à partir de lundi je commence sur les infrarouges.

GLiP : verification du voisinage ...

Aujourd’hui j’ai fini l’algo d’établissement de la carte. Il peut maintenant bien tourner quand il manque des blocs par rapport à ce qui est prévu dans le fichier glip.

Je me suis ensuite intéressée au problème suivant : quand deux blocs sont séparés par un trou (par exmple, la forme est un U), ils se croient voisins. J’ai pu mettre en place un petit algorithme qui détecte ce genre d’erreurs mais je ne vois pas comment pouvoir les corriger. En effet, avec cet algorithme je n’arrive pas à trouver quels sont les blocs qui posent problème … et je n’ai pas d’idée pour l’instant, à part celle-ci, qui est lourde :

On essaie de casser une liaison, et on regarde si le voisinage devient cohérent, sachant que la figure doit rester connexe

On essaie de casser des couples de liaison et on regarde si le voisinage devient cohérent, etc