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.

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)

Initialisation et Irda

J’ai essayé de mettre en place l’initialisation mais c’est loin d’être aussi simple qu’on avait pu le croire ! Rien que la première étape : les blocs s’envoient des hellos pour connaître leurs voisins. Entre deux blocs, ça fonctionne. Mais dès que 3 blocs entrent en jeux, tout se met à bugger, les blocs affichent n’importe quoi… Je me suis dit que c’était peut-être à cause des Irda qui émettent un peu partout, mais normalement, l’algorithme est censé gérer les cas où une même interface reçoit des messages de plusieurs blocs différents (le bloc considère alors qu’il n’a pas de voisin sur cette interface). Donc … pas beaucoup d’avancées pendant ces vacances …

Bootloader GLiP

Ces derniers jours, je me suis attelé à programmer un bootloader pour GLiP. En effet, lorsqu’on devra flasher les 16 blocs, ça serait beaucoup plus pratique de le faire via IrDA plutôt que par JTAG.

Dans un premier temps (vendredi, samedi après-midi, lundi après-midi), je me suis donc basé sur le bootloader du projet serpent de l’année dernière (qui flashait via le bus CAN) et j’ai adapté le système de paquets pour le bootloader. En effet, le checksum est indispensable (on ne va pas flasher n’importe quoi) mais on peut se passer de certains champs (TTL, émetteur, …).

J’ai repris la bibliothèque pour l’écriture dans la Flash de l’année dernière (mardi).

Aujourd’hui (jeudi), j’ai enfin réussi à jumper à une adresse mémoire donnée au bout d’un Timeout (lorsqu’aucune commande bootloader n’a été reçue), ce qui est une fonction assez intéressante pour un bootloader !

Programme de demain : débugger la communication IrDA qui ne semble pas fonctionner (le bootloader jump même si une commande a été envoyée !…).

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.

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.

IrDA

Aujourd’hui j’ai continué à coder la configuration du stm32 pour utiliser l’USART1 en mode irda et tester les communications entre deux cartes de TPs.

J’ai de plus commencé mes recherches sur le CRC16 pour calculer le checksum des paquets à transmettre.