Site ELEC344/ELEC381

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

Catégories

Nouvelle avancée : rotation des blocs

Voici une petite vidéo pour illustrer la possibilité de tourner tous les blocs sauf le maître :

Glip: Affichage Mercredi 28 - Vendredi 30

Un résume du travail :

Mercredi:

Finalisation du code d’affichage. Changement de la manière comm on génère le PWM par software. Le Glitch avec l’ancienne routine d’affichage a disparu, par contre un nouveau Glitch dans la troisième ligne est apparu.

Création d’une librarie pour la construction des images et une autre pour la configuration des animation

Jeudi:

Correction du Glitch de la deuxième ligne de la matrice. Le problème, une variable qui n’était pas définie comme ‘static’ comme il fallait. Affichage d’une image fixe 100% fini

Début de la confection d’une barrière pour les modules. Après plusieurs heures de travail avec Alexis, le groupe a opté pour une solution qui incluait de la mousse. Finalement un commande a été envoyé à Farnell.

Vendredi :

Adaptation de la routine d’affichage d’une image en incluant une table de couleurs. Test dans une animation.

Lecture et compréhension de différents parties du code python de gif2glip.

Création d’un programme en C qui crée des fichiers include (DATA0, DATA1, …. ) à partir des données d’un fichier .glip pour la configuration des images à afficher dans chaque bloque.

Test dans les modules. L’image montré est similaire à celle qui est montré dans l’écran de l’ordinateur par gif2glip.

La vidéo d'illustration ...

Voici la vidéo dont Julie a parlé :

EDIT : Les positions sont recalculées après déplacement !

EDIT2 : Avec une (petite) animation !

GLiP le retour

Aujourd’hui, on a enfin fait des progrés visibles !

On a pu mettre des caches « convenables » sur 6 blocs, on a donc fait nos test sur 6 blocs. Un bloc est le maître. On le place toujours en haut à gauche de la figure. Chacun des autres blocs lui envoie qui sont ses voisins. Le maître calcule alors la position des glips et la leur envoie. Quand les glips reçoivent leur numéro de position, ils l’affichent.

On numérote les positions de cette façon : la 1 est en haut à gauche puis on augmente  de gauche à droite, de haut en bas.

Vous pouvez voir une démo sur le post de Micka(chu). Notez que le maître attend 10 secondes avant de calculer la position de chaque bloc, ce temps sera réduit par la suite.

Merci Alexis pour les réparations :)

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)

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 !…).