ELECINF344/381

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

Catégories

[CASPER] Beagleboard, pilotes et pwm

Voici un petit compte rendu de ce que Thomas et moi-même avons réalisé hier et aujourd’hui.

 

Bootstrap

Partant de ce que Thomas avait réalisé précédemment, nous avons automatisé l’installation de la carte SD pour la beagleboard. En effet, celle-ci doit contenir dans une première partition FAT les fichiers du noyau nécessaires au démarrage, et sur une deuxième partition du format de notre choix la racine du système de fichiers.

Afin de pouvoir choisir plus finement quel noyau et quel paquets nous souhaitons installer sur notre beagleboard, et pour pouvoir la placer rapidement dans une configuration « prête à utiliser » lors d’une éventuelle réinitialisation, nous avons choisi de ne pas utiliser les images de rootfs proposées sur internet par la communauté de développeurs beagleboard.

Nous avons donc construit notre propre image rootfs à l’aide de l’outil debootstrap couplé à l’émulateur qemu, ce qui permet de créer sur un ordinateur portable classique une distribution pour une architecture arm, par exemple. Nous avons inclus de nombreux paquets tels que la bibliothèque opencv qui nous sert pour le traitement de l’image, et SVOX pico, qui nous sert pour la synthèse vocale.

Nous avons ensuite configuré la distribution afin d’obtenir une console sur le port série et paramétré la distribution afin de la rendre directement utilisable.

Ces étapes ont été totalement automatisées dans un script, ce qui nous permettrait éventuellement de regénérer tout ceci très rapidement, tout en faisant évoluer nos paramètres.

Nous avons ensuite généré les fichiers de boot à partir du noyau de sorte qu’il supporte le système de fichiers nilfs2¹ (Le garbage collector du nilfs2 sera lancé automatiquement, dès lors que les paquets nilfs-tools et nilfs2-tools sont installés sur le système. Il faut donc les ajouter dans le script debootstrap_init.sh).

 

Le système de fichiers nilfs2 offre en résumé deux avantages : sa structure garantit l’intégrité des fichiers écrits ce qui évite la corruption de la carte en cas de coupure de courant ou de plantage et il offre d’excellentes performances sur la carte SD en comparaison avec l’ext2 par exemple.

Cela est certainement dû à sa structure circulaire, et à son mode de fonctionnement avec garbage collector. En effet, les fichiers supprimés ne sont pas effacés immédiatement, ce qui aurait pour effet de ralentir les opérations. Ces effacements ne sont réalisés que beaucoup plus tard, à la fin d’un compte à rebours ou lorsque les segments propres sont en nombre insuffisant. Ainsi, l’écriture est rapide puisque sans effacement, et l’effacement est retardé ce qui à nouveau permet de gagner beaucoup en vitesse de fonctionnement. (L’installation de paquets logiciels est aussi rapide que sur un ordinateur moderne avec nilfs2, ce qui était loin d’être le cas avec ext2 puisqu’en fonction des dépendances, il fallait entre 15 et 60 min)

 

Ensuite, un autre script que nous avons réalisé automatise la génération d’une archive tarball rootfs.

Une version adaptée du script setup_sdcard.sh (http://github.com/RobertCNelson/omap-image-builder/blob/master/tools/setup_sdcard.sh) nous permet ensuite, là encore de manière automatisée, de formater la carte mémoire et de créer les partitions, de générer les fichiers uImage et uBoot, et enfin de copier les fichiers de boot et d’extraire le tarball rootfs sur les partitions correspondantes.

Nous avons de plus écrit une notice détaillant l’utilisation de ces scripts en vue de générer rapidement une installation pleinement fonctionnelle et incluant tous les paquets logiciels nécessaires sur la carte SD.

 

¹ Merci PHH pour les conseils !

 

 

Pilotes et PWM

Thomas continue de se pencher sur la question des pilotes. Il a réalisé un helloworld que nous ne pouvions malheureusement tester sur la beagleboard, du fait que celle-ci était immobilisée par les opérations de préparation de la carte SD. Maintenant que celle-ci est prête, nous allons pouvoir tester la compilation et l’installation dynamique de ce module de communication helloworld dans le noyau.

Étant donné que la beagleboard n’était pas prête, et outre sa participation à la création de la nouvelle distribution au travers de son expérience précédente avec la première installation que nous avions réalisée avec le script setup_sdcard.sh, Thomas a continué de se documenter sur la réalisation de pilotes et sur l’utilisation des modules PWM sur la beagleboard.

MB Led: Depuis la soutenance intermédiaire…

Notre dernier article datant de mardi dernier. Je vais faire un résumé de mes avancées des derniers jours:

Mercredi et jeudi:

J’ai terminé de coder les fonctions de communications avec le driver de LED. J’ai désormais un exécutable censé afficher une image décrite pour l’instant en dur (pixels écrit un par un à la main dans un tableau). Je ne peux pas avancer plus de ce côté sans nos blocs, une fois ceux-là soudés,  je pourrais passer au debugage

Voici comment fonctionne cet affichage dans les grandes lignes:

Initialisation:

  1. On initialise la communication SPI: messages de 16 bit, fréquence d’envoi de 18MHz, LSB transmis en premier.
  2. On initialise le DMA.
  3. On initialise l’horloge qui servira de référence pour le PWM du driver.
  4. On configure les différentes luminosités pour les trois groupes de couleur (rouge, vert et  bleu)
  5. On configure la fréquence de l’interruption qui rafraichira l’affichage de l’image. Cette fréquence n’est pas définitive, elle dépendra de la puissance des LED qui influe sur la persistance rétinienne. Plus cette puissance sera grande plus on pourra réduire la fréquence de rafraîchissement. Cette fréquence ne peut donc être réglée qu’empiriquement. Pour l’instant 80KHz en se basant sur le code des GLiP.

Routine d’affichage:

Les 8 lignes sont affichées les unes après les autres. Une seule ligne est allumée à un instant donné.

L’affichage d’une ligne se fait de la façon suivante:

  1. On récupère la ligne dans l’image courante.
  2. On extrait, des pixels de cette ligne, les valeurs des 24 LED.
  3. Ces valeurs sont pour l’instant sur 4 bit, une fonction est chargée « d’étirer » ces valeurs sur 12 bits pour correspondre aux attentes du driver. C’est cette fonction qu’il faudra modifier lorsque nous déciderons d’élargir le champ de couleur disponible (pour l’instant on garde le format GLiP).
  4. On construit finalement, sous forme de 18 messages de 16 bit, le vecteur de 288 bit attendu par le driver pour piloter ses 24 sorties (24*12bit).
  5. Ces 18 messages sont envoyés en SPI par accès direct à la mémoire au driver de LED qui va afficher la ligne courante.

Vendredi et samedi:

Depuis vendredi je réfléchi à une façon de faire des mises à jour de firmware via l’IrDA. En effet si nous avons 36 blocs, dès qu’il s’agira de flasher une nouvelle version de notre code, cela s’avérera être une opération fastidieuse. Petit calcul: 30 secondes (au moins) pour flasher un bloc et 36 blocs. Soit un peu moins de 20 minutes à chaque fois!

Une organisation possible de la mémoire flash, pour la mise en place d’un système de mise à jour que je détaille plus bas, serait la suivante:



Les premières instructions du bloc Flash programmer font « sauter » en _firmware_begin.

Puis, le firmware pourrait être mis à jour de la façon suivante:

  1. Notre firmware courant s’exécute normalement sur un bloc B : affichage d’animations, jeux, etc…
  2. Nous souhaitons faire une mise à jour du firmware depuis la carte microSD d’un bloc A par exemple.
  3. En se reposant sur notre système de transmission de donné par IrDA que je ne détaille pas ici, le bloc A va d’abord envoyer une commande indiquant l’arrivé d’une mise à jour (broadcastée ou non)
  4. Un des blocs, B, recevant cette commande décide de l’accepter ou non.
  5. Si il accepte il va placer les différentes parties du firmware  envoyé par le bloc A (là encore en se reposant sur notre système de transmission IrDA gérant les problèmes de communication, les paquets corrompus, perdus etc.) en flash à partir de l’adresse _new_firmware_begin à la bonne position: _new_firmware_begin + (taille d’un paquet * position du paquet).
  6. Lorsque tous les paquets ont été reçu correctement (on peut redemander une confirmation à ce moment-là), le programme saute à l’adresse  dans le bloc Flash programmer de début de traitement de la copie.
  7. Le nouveau firmware est alors entièrement copié à la place de l’ancien.
  8. Une fois la copie terminée on retourne à l’adresse _firmware_beginn.

La mise à jour est terminée!

Je m’intéresse maintenant à l’implémentation de ce système de mise à jour ainsi qu’au fonctionnement du debugage via le port série prévu pour ça.

Référence :

Pour le flashage « in-application » : AN2557

 

[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.

[CASPER] Dernières avancées…

Vendredi, nous avons avancé dans le projet sur trois fronts :

- Alain a commencé la modélisation physique de Casper. Le but étant de définir les contraintes pour le contrôle des moteurs. Après quelques expérimentations, nous avons déterminé que la meilleure solution à notre problème est d’utiliser des servomoteurs reliés à des bras mécaniques. D’après nos calculs, nous avons besoin d’un couple minimum de 35 Ncm pour un bras de 7 cm.

- Thibault a quant à lui travaillé sur le PCB et rédigera un billet détaillé à ce propos.

- Pour ma part, j’ai commencé à travailler sur la Beagleboard. Nous avons préparé une carte SD qui contient une partition de boot en fat32 et une partition contenant linux (en ext2). Pour l’instant, la carte boote depuis la carte SD sur Ubuntu (Maverick) 10.10. Nous communiquons par le port série avec la Beagleboard, avons activé la connexion filaire et sommes en train d’installer divers packages.

Copterix : les aventures commencent

Changement de planning :

Suite aux semaines mouvementées que nous avons eu, nous avons refait un planning plus réaliste :

20/03 : Design du PCB (peut dépendre des empreintes disponibles sous Mentor)
21/03 : Lukas & Kanade fonctionnel sur PC
24/03 : Communication Wifi avec la Gumstix pour le streaming video
28/03 : Fin de l’étude physique (Simulation, Kalman)
04/04 : Kalman fonctionnel sur l’IMU
15/04 : Vol stable
22/04 : Déplacement de coptérix

Gumstix :

Nous avons depuis hier deux Gumstix. La première (Tide) n’a pas de flash donc on ne peut pas la briquer…par contre elle n’a pas de Wifi intégré. On utilise donc au début la Tide pour bien prendre en main les Gumstix avant de passer sur la deuxième Gumstix (FE) qui elle supporte le Wifi.

La carte doit booter sur une micro SD. On a donc suivi un tutorial pour pouvoir faire une carte SD bootable à partir d’un noyau précompilé. On a pu aujourd’hui tester la carte et y installer ssh. Par contre, le noyau que nous utilisons ne reconnait pas la caméra. Il faudra soit utiliser un autre noyau pré-compilé soit compiler nous-même le noyau en y rajoutant le driver pour pouvoir utiliser la caméra.

Tracking :

Axel s’est intéressé à l’algorithme de Lucas and Kanade.  Il utilise OpenCV. Voici quelques résultats :
Il a implémenté un petit programme qui montre d’une image à l’autre les déplacements sous forme de traits rouges. L’idée à terme est de faire un filtre médian sur ces vecteurs pour en tirer un vecteur de déplacement fiable.

MB Led: PCB et algorithmique

Aujourd’hui, nous avons terminé le routage du PCB le TP stm32 et après une semaine nous avons pu reprendre activement l’avancement de notre projet.

Guillaume a continué à voir l’algorithme de notre système réparti avec la première et difficile question pour un bloc qui est de savoir où il est et où est son nord et cela qu’il soit seul ou dans un réseau de bloc. Ici se posent les problèmes de savoir quel bloc prendre comme base pour l’orientation dans le cas d’une modification importante du réseau de blocs (ex: on disperse tout et on reconstruit ou on colle brusquement deux réseaux de blocs). Nous sommes d’abord partis du principe que chaque bloc est une entité indépendante, mais nous envisageons maintenant de considérer le problème par réseau de blocs (un bloc seul étant un réseau d’un bloc) afin de coller à l’idée de système réparti et de permettre de traiter plus globalement les différents cas possibles. Par exemple lorsque l’on fait la jonction de deux réseaux, les deux réseaux échangent leurs états pour construire l’état du nouveau réseau. Se pose la question de la réactivité de ce système dans le cas d’une jonction simultanée de plusieurs réseaux. Il a également mis en place les bases et défini les différents types d’envois d’information en cas de transmissions extérieures (Via Bluetooth, port série) ainsi que la gestion des échanges et mise à jour de la liste des programmes et du firmware des blocs.

Benjamin a repris le schéma de GLIP comme base pour notre PCB pendant que je me penchais sur la question de l’achat des composants et des divèrses transformations que cela entraine dans le circuit. Nous nous sommes posés le problème de modulation de l’intensité d’émission des transceivers IrDA qui se fera grâce à un petit potentiomètre ainsi que celui l’intégration de la SD avec la recherche d’un connecteur (nous hésitons encore entre des cartes SD ou microSD) interfacé par le mode SDIO du STM32F103RET6 en 64 pins (48 ne seraient pas suffisants). Tout ceci nous a permis de commencer à évaluer le coût des composants des blocs pour un total d’environ 60€ (sans compter le PCB).