ELECINF344/381

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

Catégories

IRL : avancées de la journée

Ajourd’hui nous avons travaillé en parallèle sur deux thèmes : le FPGA, et l’interface web.

Côté FPGA, nous avons pu simuler une RAM lisible et inscriptible depuis le processeur, ce qui est encore peu mais nous permet de penser qu’on a compris comment le lien fonctionne. Nous avons ensuite une une réflexion sur l’architecture fonctionnelle des modules du FPGA.
La mémoire du FPGA doit pouvoir servir de tampon, étant donné que Linux (peu précis au niveau du timing) enverra des paquets de données par à-coups, alors que la sortie vers le laser devra être cadencée bien régulièrement. Nous utiliserons les blocs de RAM internes du FPGA comme buffers avant et après la RAM (cf schéma), et les RAMs SPI de manière à ce que l’ensemble soit vu comme une FIFO par l’extérieur.
Le module de sécurité surveille les sorties du bloc de contrôle des DACs pour s’assurer que le laser ne reste pas allumé dans une trop petite zone durant un temps trop long. La taille de la zone (du moins sa traductions en déplacements « absolus » au niveau des coordonnées numériques) devra être fonction de la distance minimale à laquelle un observateur peut potentiellement se trouver. La durée maimale d’exposition sera à déterminer à partir de la puissance du Laser et des recommandations médicales. Cet ajustement n’est clairement pas la priorité actuelle.

 

 

 

Du côté du serveur Web, ça a été plus chaotique. Nous étions partis depuis deux jours sur l’utilisation de WebPy. Cependant son intégration avec SQLite impose l’utilisation de modules Python tierce partie, et la cross-compilation de ces modules nous pose beaucoup de problèmes. Dernièrement nous avons tenter de passer à la daily-build de la µClibC pour résoudre un problème avec l’importation de pysqlite3, ce qui a eu pour résultat de casser notre rootfs (kernel panic au démarrage à cause de dl_iterate_phdr()). Une simple recompilation en rechangeant de version de µClibC semble ne pas suffire (pour une raison inconnue), nous tenterons une recompilation depuis zéro demain.
Ces problèmes nous ont pris assez de temps et nous allons probablement chercher sur d’autres pistes, peut-être du côté de Mongrel2 comme Sam nous l’a conseillé.

Sur le même sujet :

  1. IRL : Avancées de la journée
  2. IRL : avancées du vendredi
  3. IRL : Mise en marche de l’armadeus, et autres
  4. Communications internes et externes
  5. IRL : Journée PCB 1/2

Commentaires fermés.