ELECINF344/381

Partie interactive du site pédagogique ELECINF344/ELECINF381 de Télécom ParisTech (occurrence 2011).

Catégories

IRL : avancées du vendredi

Un point sur les avancées de ce vendredi.

Côté ILDA (Laurent), le programme de conversion SVG -> ILDA a été refondu, il est plus simple et donne de meilleurs résultats. Nous avons réussi à mettre un alphabet dans un fichier ILDA. Il reste cependant quelques problèmes, notamment les lettres qui ne sont pas bien centrées, à suivre.

Du côté du serveur web avec web.py (Caroline), du développement a été effectué sur un PC. On affiche des pages webs avec des informations venues d’une BDD sqlite. La prochaine étape sera de passer le serveur sur l’Armadeus avant d’aller plus loin pour vérifier que la solution est viable d’un piont de vue des performances.

Pour ce qui est des driverset de la communication entre le processeur et le FPGA (Yoann), Sam et Alexis nous ont remis sur la bonne voie après quelques errements de ma part. Du coup la journée d’hier a été peu productive, ça devrait aller mieux aujourd’hui. J’ai par ailleurs consacré pas mal de temps à la lecture de Linux Device Drivers.

IRL : Mise en marche de l’armadeus, et autres

Fin des PCB : Nos PCB pour la carte additionnelle laser et la carte DMX ont été finis et envoyés vendredi soir. Pas de message d’Alexis, bonne nouvelle…

Installation de l’armadeus : nous avons pris possession de l’Armadeus APF27-dev en fin de semaine dernière, et nous avons commencé à nous en servir. Pour l’instant nous avons :

  • Compilé un noyau sur lequel on a réussi à booter
  • Compilé un rootfs (plusieurs fois pour ajouter quelques fonctionnalités au fur et à mesure), en version UBIFS pour accélérer la vitesse de montage des partitions au démarrage (sur conseil d’Alexis)

Notre carte dispose maintenant d’un serveur SSH (pratique pour travailler à plusieurs dessus), et d’un serveur web boa (qui parfois donne des erreurs au démarrage, on cherche) grâce auquel nous avons pu accéder à une page web hébergée sur l’armadeus. Nous avons également testé un Hello Word en CGI, en bash pour commencer, puis en C++.
À ce propos, nous nous interrogeons sur le langage à utiliser pour l’interface web côté serveur. Nous hésitons entre Python plus facile et adapté (mais buildroot ne propose pas le mode CGI, peut-être est-il par défaut) et du C++ à l’aide de libcgicc (probablement plus rapide mais plus source à embêtements).

Par ailleurs, nous pensons utiliser sqlite pour associer des masques DMX, des images et animatiosn ilda à différents mots-clés que l’on pourrait extraire des tweets, ou à différentes ambiances prédéfinies. Nous ne sommes pas encore sûrs d’utiliser une base de données, c’est à étudier plus en profondeur.

Framebuffer : on nous avait soufflé l’idée d’utiliser le framebuffer de Linux pour se servir du laser comme écran, cette idée était trop complexe et mal adaptée. Sam et Alexis nous ont proposé une autre idée plus abordable (mais qui restera comme du « bonus » et ne sera pas un objectif principal) qui serait d’afficher la sortie d’une console série. Laurent a fait un petit script qui construit un fichier ILDA simplifié au fûr et à mesure des saisies d’un utilisateur. Cette idée paraît donc réalisable, on la garde pour plus tard.

Alphabet ILDA : nous avons besoin d’une bibliothèque de fichiers ILDA (ou ILDA simplifié X, Y, on/off) contenant les caractères affichables par notre laser. Comme Alexis nous l’a conseillé, nous sommes parti d’un alphabet SVG que nous parsons pour aboutir à notre format ILDA simplifié. Nos essais sur une dizaine de lettres sont concluants.

FPGA : on a pris en main l’IDE et synthétisé un exemple (blinking LED) de la doc. Nous pensons l’avoir flashé  correctement sur le FPGA, cependant l’alimentation de la LED requiert le branchement de deux pins de l’Armadeus, nous attendons l’avis de Sam ou Alexis pour être sûrs de ne rien griller. Par ailleurs, Laurent a réalisé un module en Verilog qui gère la communication avec les mémoires SPI, il reste un détail à modifier mais l’essentiel est là et le code est sythétisable.

IRL : Forme générale du projet

Nous avons envisagé différentes idées avant de nous fixer sur la forme suivante :

Nous utiliserons une carte principale, avec Linux, sur laquelle il faudra faire tourner un serveur Web.
Celle-ci sera chargée de :
- Récupérer les mails et les tweets,
- Interpréter ces derniers et choisir en fonction l’ambiance et l’animation associée,
- Commander le laser (écriture d’un driver…),
- Commander un sous-sytème en charge de la modification au vol des trames DMX,
- Proposer une interface accessible via Internet pour modérer le système (et configurer les ambiances DMX ?)

Nous pensons pour l’instant déplacer la complexité de la modification des trames DMX vers un système dédié. Nous hésitons sur sa forme (micro-contrôleur, FPGA ?)