Site ELEC344/ELEC381

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

Catégories

Après les oeufs de paques…

J’avais la semaine dernière regardé le code de l’année dernière sur tout ce qui était ILDA pour voir ce qu’ils avaient fait et si ca correspondait avec ce qu’on voulait faire.

Finalement on laisse tomber l’ILDA simplifié et on oubliera simplement l’octet inutile au moment d’écrire les informations en RAM.

J’ai lu hier soir la norme DMX et regardé le code de l’année dernière pour me fixer les idées. Les commandes DMX typiques sont:
- « Lancer l’animation x »
- « Démarrer le show y »
- « Afficher l’image z »
- »Eteindre le laser »
- …

La norme DMX spécifie un protocole (pour ce qui nous intéresse) mais on libre des données que l’on transmet. Ils se sont beaucoup basés sur les interruptions l’année dernière pour mettre en place le protocole. A voir si on fait comme eux. D’une manière plus générale, beaucoup de codes de l’année dernière peut être repris pour le DMX. Il faut qu’on voit jusqu’à quel point.

Aujourd’hui j’ai continué à coder la partie sur l’ILDA. Le principe est de remplir un buffer en RAM avec l’image à afficher. Ce buffer sera réutilisé par la carte K12N.

Je développe sur PC pour l’instant mais l’idée est qu’à l’aide d’une simple macro, on peut choisir si c’est pour PC ou pour la carte. Les fonctions utilisés sont FOPEN, FWRITE,… et en fonction sont fopen, fwrite, … ou f_open, f_write (Lib FatFS) qui nécessite l’implémentation de certaines fonctions.

L’idée est de finir la partie sur ILDA pour la fin de semaine et de pouvoir commencer le DMX la semaine prochaine. A moins que quelqu’un ait besoin d’aide sur sa partie.

Romain

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.

Avancement du TP v3

Ce matin, j’ai fini les interruptions (j’ai fait une erreur d’inattention: port B au lieu de port C) puis j’ai bossé sur le projet. J’ai notamment regardé le code du projet laser de l’année dernière pour mieux comprendre ce qu’il fallait faire pour l’ILDA, le DMX et le fonctionnement en général. (3h)
J’ai continué cela en fin d’aprem et mis à jour le wiki (il me reste quelques trucs à faire). (2h)

En début de soirée, j’ai remis en forme tout mon code et j’ai mis les interruptions pour gérer le backlight du lcd. Je vais essayer de finir le wiki et le buzzer avant de me coucher. (2h)

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.

PuLSE, entrée DMX / pilotage de la carte K12N

Avancée actuelle sur le projet PuLSE :
on commence à réaliser les schémas électriques de la carte mère. Le travail a été réparti en 4 tâches :

  • Brochage du processeur STM32F103RET6 : Thibaut
  • Schéma du contrôleur ethernet : Etienne
  • Schéma du contrôleur SD : Romain
  • Schéma de l’entrée DMX et sortie vers la carte K12N : xavier

Donc bilan sur ma partie :
l’entrée DMX est cablée. On aura un connecteur XLR male et un femelle qui seront connectés via un micromatch vers le processeur. On a utilisé un contrôleur d’entrée différentielle (SN75176A) pour faire l’interface avec une UART. Actuellement la carte fait relai pour le flux DMX (elle ne peut que le lire, et les deux connecteurs DMX sont directement reliés)

La sortie vers la carte K12N va nécessiter 2 amplificateurs. Il faut qu’ils aient une bande passante de plus de 20KHz et un gain minimal de 10 (en gros il faut pouvoir passer d’un signal entre 0 et 3.3V à un signal entre 0 et 10V). L’an dernier ils ont utilisé un PGA203KP vendu par Texas Instruments, qui a l’air assez cher (environ 16€), alors que d’autres amplis ont l’air de faire l’affaire et sont moins chers. Actuellement je n’ai pas eu le temps d’aller chercher plus loin. Ca sera pour demain.

Sinon TP STM32, rattrapper du retard. Au total ca a pris la matinée plus 3-4 h réparties entre l’après midi et la soirée.

Le but est en fin de semaine d’avoir routé notre carte mère. Une fois les 4 tâches finies on pourra commencer s’occuper de l’alimentation et des composants moins importants, qui se cableront plus vite (port USB, JTAG, etc…). L’idéal serait d’avoir fini ca d’ici mercredi soir, pour faire le placement jeudi et vendredi.