Site ELEC344/ELEC381

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

Catégories

ILDA

Alors aujourd’hui j’ai repris mon programme Python pour l’améliorer (il était assez sale à certains endroits et notamment j’utilisais un bout de code en C ce qui m’empêchait de le faire évoluer). Je n’ai pas tout à fait fini mais ca devrait plus être trop long.

Ce qui va me permettre de gérer un alphabet bien plus complet ce que j’ai pu faire jusqu’à présent.

J’ai aussi regardé niveau Ethernet ce qu’on pouvait faire avec Etienne, mais sans grand résultat. Une fois que tout ca marchera bien, il ne restera plus grand chose à faire pour finir le programme Python (peut être pas très beau esthétiquement…)

carte SD en grève

aujourd’hui je me suis joint à Thibaut pour travailler sur la carte SD. On était partis pour essayer de lire et d’écrire en mode polling, ce qui est une mauvaise solution car trop gourmande en CPU. Samuel nous a aidé à mettre en place la lecture en mode DMA. Après nous avons passé le reste de l’après midi à comprendre pourquoi la carte ne voulait pas écrire, alors que la procédure (du moins les fonctions de la bibliothèque ST) pour écrire est très proche de celle pour lire.
Cependant nous nous sommes heurtés à des erreurs de validité du CRC sur les données émises. Nous avons cherché à désactiver la vérification du CRC sur les cartes (au moins histoire de voir si on pouvait réellement écrire), et d’après les datasheets, ca n’est pas possible. Ca m’étonnerait que les polynomes utilisés pour le CRC soient différents, car ils fonctionnent en lecture. Ce n’est pas non plus un problème d’horloge (la datasheet demande une horloge AHB égale à FCLK/2, mais les commentaires de la bibliothèque ST disent le contraire (FCLK), nous avons essayé les deux).
Après quelques recherches sur internet, les seules réponses que nous avons vues sur des problèmes similaires sont du type « ta carte est foutue, jette la et prends en une autre ». Ca m’étonnerait aussi qu’il faille faire calculer nous mêmes le CRC, car le module est interne au controleur SDIO, et on n’a pas du tout la main dessus.

A noter que sur une autre carte nous avons eu un problème de délai dépassé pour l’écriture des données, qui du coup a du masquer le problème d’erreur de CRC.

Au final, on s’est cassé les dents. A la rentrée, il faudra qu’on règle ce problème rapidement, ou bien on devra envisager d’autre moyens de faire passer des données vers la carte par ethernet (en streaming par exemple, ce qui avait été écarté jusqu’à présent)

Bonnes vacances à tous !

Ping et dhcp...

…sont opérationnels.
Enfin réglés, les problèmes de SPI, de configuration du contrôleur, de sombres headers IP, de buffers qui ne se vident pas. Finie, la recherche de l’erreur jusque dans les profondes couches de la pile IP (enfin je l’espère)…
Place maintenant à la fructifiaction. Et pour cause, le protocole dhcp (configuration automatique de l’adresse IP) n’aura résisté qu’un après-midi à Xavier et moi-même.
Le comportement du contrôleur semble fiable et nous allons maintenant nous atteler à la communication du module Ethernet avec le module ILDA.

PuLSE, erreur 404

Ce titre en dit long, ethernet ne marche pas. On a quand même un petit peu avancé. On a corrigé un certain nombre d’erreurs, enfin réussi à faire compiler lwip. On s’est vautré sur les tests sur la carte à cause d’un oubli de switch en mode « boot en flash ». Ca sera pour demain matin. Si demain midi ca ne marche toujours pas, on alertera Alexis ou Samuel pour montrer ce qu’on a fait.

Comme dit FX, c’est frustrant de rester coincé sur des problèmes betes, à ce stade du projet.

08/04 : Bilan de la journée

Ce matin j’ai débugué l’initialisation des DAC, et des amplis. J’ai pu valider la sortie d’un signal dans les bonnes bornes (0-10V vers la carte K12N).
Cet après midi je me suis mis à coder la tâche de gestion de la carte K12N, qui regarde s’il y a une image à afficher, et qui l’affiche point par point. Il ne faut pas afficher les points trop vite : 50us par point minimum. Du coup j’ai initialisé un timer qui lève une interruption toutes les 50us. Visiblement le timer s’initialise correctement, puisque j’arrive à faire générer une PWM en lui mettant une sortie sur une patte non attribuée. En revanche les interruptions ne sont pas levées. Entre ca et un autre problème (un vTaskDelay entraine une hardfault) je n’ai pas pu terminer et passer des images sur l’écran de l’oscilloscope. J’essaierai de faire ca demain.

A part ca j’ai aidé Etienne en faisant la configuration du bus SPI nécessaire pour le controleur ethernet.

Au niveau du temps passé je dirais 2h30 ce matin et 6h cet aprem.

modèles et vérification

Non, ce n’est pas le titre d’un cours super intéressant (:D), mais bien ce que j’ai commencé cet après midi. Je me suis attelé à la tâche d’intégration des autres tâches qui tourneront sur la carte.

Il y a plusieurs sources de controle de la carte : entrée DMX, multiples boutons poussoirs. Il y a de même plusieurs facteurs qui peuvent nécessiter l’extinction immédiate du laser : surchauffe de l’un des galvanomètres, déconnection du cable ethernet pendant l’affichage d’une vidéo en streaming.
Le but est donc d’identifier et de centraliser les changements d’état courant dans une machine à états afin de faciliter la programmation dans les autres tâches, et de fournir des fonctions « sécurisées » comme enableLaser(), qui garantissent que l’état courant dans lequel se trouve le système autorise l’exécution d’une telle fonction.

Les états du système sont représentés comme l’ensemble des combinaisons des états suivants (extrait du code source):
typedef enum {DMXControl, localControl} controlInputMode;
typedef enum {ethernet, SDCard} dataInputMode;
typedef enum {present, absent} SDPresenceMode;
typedef enum {connected, unconnected} ethernetPresenceMode;
typedef enum {hot, cold} overheatMode;
typedef enum {idle, image, video, etc} runMode;
typedef enum {read, write, both} controlSDMode;
typedef enum {on, off} updateMode;
typedef enum {allowed, forbidden} enableLaserMode;
typedef enum {enabled, disabled} laserStateMode;

Un certain nombre de combinaisons de ces états sont incompatibles. Il faut donc développer un système de transitions qui garantisse qu’ils ne seront jamais atteints. Si j’ai le temps (dans une autre vie :) ) je pense valider le système de transitions en le codant en lustre et en utilisant un model checker (lesar je pense), mais ce n’est pas la priorité. Je pense que d’ici vendredi matin ca sera codé, en étant pas très efficace j’y ai passé 3h cet aprem et j’ai pas mal avancé.

Sinon j’ai regardé comment envoyer des fichiers ILDA en TCP vers la carte une fois qu’Etienne aura réglé l’ethernet, et j’ai trouvé un code client/serveur en C sur internet. Il faudra adapter le serveur pour qu’il utilise les fonctions de uip et ca sera bon.

mieux vaut tard que jamais

Bilan de ces derniers jours :
- le TP est terminé depuis cet après midi. J’en ai profité pour factoriser au maximum le code et clarifier certains points
- la carte du projet est arrivée, mais on n’a pas de photos. Il semble qu’il y ait un petit problème avec le controleur ethernet, pour lequel on aurait pris l’empreinte d’un modèle qui ne se fait plus. Alexis est en train de regarder ca.

De mon coté sur le projet je n’ai pas eu le temps d’avancer. En début de semaine prochaine je proposerai une modélisaation du syystème complet au groupe pour qu’on finalise ca et qu’on se mette à coder chacun de son coté. Je prendrai également du temps pour souder les composants à la carte (ceux qu’alexis n’aura pas eu le temps de faire :) )

à demain matin pour de nouvelles aventures

Avancement TP et PuLSE

Concernant le TP : Le lcd, le bouton poussoir et le buzzer fonctionnent : il ne me manque plus « que » le ZigBee.

Coté projet, je me suis lancé à la recherche d’une pile TCP/IP qui pourrait nous convenir (notamment uIP et lwIP recommandées par FreeRTOS) et dans la lecture de la datasheet du contrôleur Ethernet.

le lcd ne m’aime pas :’(

bon, bilan de la soirée d’hier, une petite quantité d’heures passées en tete à tete avec un écran LCD noir. Après comparaison avec les codes de Romain (qui marche bien), je n’ai noté aucune différence autre que dans la syntaxe utilisée. Ce sera donc à regarder aujourd’hui.

Au niveau du projet, une répartition des rôles a été effectuée : Thibaut fera la partie transfert de fichiers avec la carte SD, avec l’étude du format fat. Etienne fera la communication avec le controleur ethernet. Romain a déjà commencé la simplification des images ILDA, et fera aussi l’entrée DMX. Je me chargerai du pilotage de la carte K12N et de la fin de l’éléctronique. La suite demain aprem après une réunion de l’équipe.

PCB, LCD et python

Bilan de la journée :

Tout d’abord, concernant les PCBs pour GLiP, j’ai mis en place les plans de masse pour les PCBs des modules maîtres (XBee et Ethernet) normalement on les a terminés : la diode a été changée et les nouvelles capacités mises en places.

Puis je me suis attaqué à la carte de TP : le LCD fonctionne mais j’ai encore un petit soucis : certains caractères mis côte à côte font n’importe quoi ! Donc je suis en phase de débogage !

Enfin toujours sur GLiP j’ai repris l’intégration des délais et normalement je vais pusher sous peu une version qui permet de visualiser une animation avec les délais contenus dans le gif original.

Voilà pour la journée :) Et au dodo rapidement pour récupérer du WEED !