ELECINF344/381

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

Catégories

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.

[CASPER] Choix du système de fichiers

Comme décrit par le précédent post de Thomas, nous avons été amené à faire un choix quant au système de fichiers utilisé sur la carte SD afin de stocker le système d’exploitation.

Le choix en la matière est relativement large, notamment en ce qui concerne les systèmes de fichiers spécialisés pour les périphériques de stockage par blocs (ntfs, fat, extx et autres).

Les mémoires flash ne sont pas des mémoires à blocs tels que les disques durs, et notre attention s’est donc portée dans un premier temps sur les systèmes de fichiers spécialisés tels que JFFS, YAFFS ou encore UBIFS.

Ces systèmes de fichiers prennent en compte la durée de vie limitée des secteurs de la flash et répartissent donc leurs écritures sur toute la mémoire, ce qu’un système de fichiers par blocs ne fait pas, menant ainsi à la rapide destruction des secteurs fréquemment écrits, comme ceux stockant la table d’allocation par exemple.

Cependant une remarque des développeurs du système de fichier UBIFS a retenu notre attention: Étant donné que la plupart des cartes mémoires et clefs usb utilisent à présent le système propriétaire FAT qui ne respecte pas la fragilité de la mémoire et l’use rapidement, les fabricants ont donc décidé d’incorporer des chips FTL (flash translation layer) qui se chargent d’émuler un périphérique par blocs vu de l’extérieur, tout en répartissant les écritures en interne.

Ce faisant, les systèmes de fichiers par blocs de type FAT ou extx ne détruisent plus aussi rapidement la mémoire flash, mais les systèmes de fichiers spécialisés sont devenus inadaptés, bien qu’en principe plus efficaces car ayant une vue plus globale des écritures et lectures à effectuer sur la mémoire que la puce interne à la carte.

Ces systèmes de fichiers sont donc à recommander pour les mémoires flash pures, et déconseillés pour les cartes SD/MMC.

Notre choix s’est donc tourné finalement vers un système de fichiers par blocs.

Étant donné qu’un système de fichiers non journalisé limite le nombre d’écritures sur la carte, prolongeant ainsi sa durée de vie, notre choix final s’est donc porté sur l’ext2.