ELECINF344/381

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

Catégories

MB Led: Firmware protocol

Since Saturday I have been working on Firmware transmission through IrDA and the use of SD Card.

Transmission protocol for firmware:

The firmware is stored on flash memory, so we are transmitting from flash to flash through IrDA.

As we have to write in flash by pages, we also have to transmit our firmware by pages and as pages important in size we cannot send it at once. Thus each firmware will be sent divided by pages which are divided into packets.

  1. At the beginning of a transaction a first packet is sent with the data needed in order to store the firmware such as number of pages, number of packets sent by pages and for security purpose the id of the sender and the interface used. The bloc send an acceptance packet either it is already on transaction or not.
  2. Then a PAGE_BEGIN packet is sent with its position in the firmware.
  3. During page sending all data is stored in a buffer of 32-bits words.
  4. At the end of a page a packet END_OF_PAGE is sent confirming its position and adding its CRC calculated thanks to CRC unit on STM32 and the CRC is checked(Note that in the IrDA task we already check the integrity of each packet). If everything is okay we write the buffer in flash, if not a request is sent to resend the page.
  5. We continue till we arrive at the end of firmware with the packet END_TRANSACTION and the global integrity is checked. In case of success we send a TRANSACTION_OK packet, if not we have to do it again from the beginning.

SD CARD:

For SD Card we will use FatFS, a free open source FAT file system module which has an implementation on STM32 thanks to Martin THOMAS. I adapt it to our system. I delayed testing because transmitting a huge amount of data seemed more important, SD card coming in second.

[CASPER] : text-to-speech on the beagleboard

Here is a little summary of what has been done today, regarding the text-to-speech on the beagleboard.

Audio with alsa on the beagleboard

First, I would like to explain the step we followed to get the audio output to work on the beagleboard without damaging the TPS6595, which manages the audio, but also the power supply (now I am sure that you understand the reason why we should not burn this one down).

We have on our SD card a bootstrapped version of the ubuntu linux distribution, with alsa installed.

To get alsa to work without being the superuser, you have to add the normal user to the audio group, and reboot the beagleboard.

Then, open the alsamixer program.

Here is was you SHOULD NOT do, despite it is being advised on some forums : enable each and every device in alsamixer.
This will cause the TPS6595 chip to overheat, and may damage it.

 

What you should do is enable only what is necessary :

  • Increase the volume of the DAC2 analog; DAC2 digital coarse and DAC2 digital fine.
  • Increase the volume of the headset
  • Enable headsetL2 and headsetR2

You should now have a working audio output.

 

Text-to-speech

In order for our whole application to work properly on the board, we decided not to use pulseaudio (which requires up to 40% of the CPU on the board). We decided to implement our own interface for the audio output, which would handle all the write requests from internal threads such as the text-to-speech engine’s thread. This interface would store the corresponding samples, pre-process them in order to fit alsa’s interleaved pcm format, and play them on the audio output.

We were able to test successfully this interface today, by synthesizing speech with SVOX pico on the beagleboard, and playing it simultaneously on the audio output.

The whole process requires 30% of the cpu during a short period (synthesis/samples post) and then 0/0.7% of the CPU during the rest of the the process, which is good news compared to the 40% CPU minimum required during the whole process in our previous experiments.

The next step will be to port the CMU Sphinx recognition helloworld we designed to the beagleboard.

MB Led : PSSC pour ces trois prochaines semaines

Suite à la demande d’Alexis et Samuel, nous ajoutons des garants pour nos prochaines étapes:

- Contrôle de la matrice de LED.                                                      => 15 avril (Benjamin)
- Élection de leader sur un ensemble de bloc.                                    => 15 avril (Guillaume)
- Affichage d’une image sur un ensemble de bloc.                              => 18 avril (Benjamin)
- Lecture de données sur la SD Card.                                               => 18 avril (Cédric)
- Détection de la rotation d’un bloc (gauche, droite, demi-tour)            => 20 avril (Guillaume)
- Mise à jour du firmware via IrDA fonctionnelle                                => 24 avril (Cédric)
- Possibilité de jouer au morpion sur 3×3 blocs                                 => 26 avril (Benjamin)

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

MB Led: Article post communication challenge.

Aujourd’hui j’ai enfin réussi à flasher quatre modules conçus par l’équipe GLiP de l’an dernier. J’ai flashé le code maitre pour un bloc contrôlable avec un PC et minicom pour la sélection des animations ainsi que le code pour trois esclaves.

Lors de la compilation de ces codes sont incluses les différentes animations préalablement convertis grâce au script python gif2glip (conçu par l’équipe GLiP).

Nous avons donc pu faire tourner des petites animations sur un réseau carré de quatre GLiP tout en constatant que les animations étaient bien affichées après mélange des blocs.

Cette étape m’a permis de me familiariser avec l’architecture du code de GliP et de m’imprégner de leurs algorithmes pour la réorganisation du réseau ainsi que pour l’affichage des images via les drivers de LED. La compréhension de ce code nous permettra de faire des premiers tests notamment pour les communications IRDA et nos algorithmes réparties en attendant d’avoir nos propres modules.

Ce soir je me suis consacré à la réorganisation de nos PSSC et à la création d’un diagramme de Gant pour une meilleur répartition des ressources dans notre équipe. Le temps passé sur le TP sur le STM32 nous a obligés de décaler les différentes deadlines pour nos PSSC.

====== Reprise du projet GLiP : ======
- A partir de GIF convertibles par gif2glip nous savons les charger via le bloc maître et les jouer sur un réseau de bloc en utilisant leur matériel ⇒ Fait

====== Conception de la carte et test : ======
- Choix des composants terminé : Fait

- Image PCB prête (on peut passer la commande du circuit imprimé) ⇒ 25 mars

Puis en supposant que nous recevons les PCB au plus tard le 4 avril :

- Soudage des composants sur les cartes => 6 avril

- Contrôle de la matrice de LED (affichage d’image) ⇒ 15 avril

====== IRDA ======
- Echange de messages entre deux blocs ⇒ 11 avril

- Ecriture via Irda sur la sdcard => 22 avril

====== Bluetooth: ======
- Communication Bluetooth avec un ordinateur ⇒ 16 avril
- Exécution de commandes reçu en Bluetooth ⇒ 21 avril
- Application de contrôle Android ⇒ 26 avril

====== Gestion de la mémoire : ======
- Lecture sur la SD Card. ⇒ 12 avril
- Ecriture sur la SD Card. ⇒ 17 avril
- Exécution d’un programme stocké en SD Card. ⇒ 22 avril
- Mise à jour du firmware depuis la SD Card. ⇒ 24 avril

====== Système réparti : ======
- Environnement de simulation en place ⇒ 3 avril
- Gestion dynamique du réseau de bloc⇒ 15 avril

====== Jeux sur l’ensemble : ======
- Jeu du morpion fonctionnel (sans Bluetooth) ⇒ 24 avril
- Jeu du morpion fonctionnel (avec Bluetooth) ⇒ 27 avril

 

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.

[CASPER] Architecture et liste de composants

Architecture globale

 

La beagleboard est l’élément central du système (www.beagleboard.org). Elle est chargée des algorithmes de haut niveau tel que le traitement de la vidéo et le traitement audio. C’est aussi elle qui se chargera de la connectivité internet et du pilotage des actionneurs.

Elle sera étendue par une carte embarquant un contrôleur STM32 chargé de piloter un écran LCD à partir de données stockées dans une mémoire flash.

Les informations sur les composants requis sont fournies dans les paragraphes suivants, les informations détaillées concernant les actionneurs/servomoteurs seront publiée dans un prochain post.

 

Ecran

Color LCD 128×128 Nokia Knock-Off

http://www.sparkfun.com/products/569

Avantage : bien documenté

Connexion au STM32 : un seul port SPI (pas de bus data)

Rq : sparkfun indique vendre un « loose connector » pour 2$ sur la même page, qui apparemment facilite le soudage…

Accessoires écran

1 transistor pour contrôle du rétroéclairage (http://fr.farnell.com/nxp/bc846/transistor-npn-boitier-sot-23/dp/1081227)

1 régulateur tension de 7V (pour le rétroéclairage).

Le modèle choisi sera finalement un LT1932 (http://fr.farnell.com/linear-technology/lt1932es6-pbf/ic-dc-dc-convert-led-dr-6sot2/dp/1651929). Il s’agit en réalité non pas d’un régulateur de tension mais d’une source de courant spécifiquement conçue pour alimenter une ou plusieurs leds.

Pour fonctionner, ce régulateur a besoin outre quelques résistances et condensateurs, d’une diode schottky (http://fr.farnell.com/rohm/rb050la-40tr/diode-schottky-40v-3a/dp/1680015) et d’une inductance de 6.8µH telle que celle-ci http://fr.farnell.com/panasonic/eljfa6r8jf/inductance-1210-6-8uh/dp/3838341 qui peut se commander à l’unité.

Carte STM32

1 STM32F103CBT6 (ou modèle équivalent, on a juste besoin d’un port SPI pour l’écran, un deuxieme pour une mémoire flash, un UART pour la liaison avec la beagle, et le reste des I/O serviront pour les extensions éventuelles)

1 régulateur 3.3V (L4931CD33)

1 prise jack pour l’alimentation

1 quartz 8MHz

1 prise JTag

1 switch (pour le reset…)

1 connecteur UART

1 transceiver UART (http://radiospares-fr.rs-online.com/web/search/searchBrowseAction.html?method=getProduct&R=6608802)

1 connecteur 6 broches (pour le SPI)

1 mémoire flash http://fr.farnell.com/spansion/s25fl032k0xmfi011/memory-flash-32m-3v-spi-8soic/dp/1861630 , qui servira à stocker les images pour le lcd

À noter : la fréquence de fonctionnement de cette flash (104MHz) laisse une marge suffisante pour récupérer des images 128*128 couleur à envoyer au LCD afin de l’animer. C’est en pratique le microcontrôleur qui limitera la vitesse de fonctionnement.

 

Son

Haut-parleur

2 Haut-parleurs MCKP2852SP1F-4752 (Ref Farnell 1801037, http://fr.farnell.com/multicomp/mckp2852sp1f-4752/dp/1801037)

Ce modèle est suffisamment petit pour pouvoir l’intégrer au visage de casper. Le deuxième pourra être placé dans le socle

 

Microphone

5 Micro pastille MCKPCM-40H15-40DB-4797 (Ref Farnell 1758416, http://fr.farnell.com/multicomp/mckpcm-40h15-40db-4797/microphone/dp/1758416)

Ce modèle a l’avantage d’être très plat (1.5mm) ce qui permettra de l’intégrer plus facilement. Plutôt que d’ajouter juste un micro à Casper, nous pourrions en ajouter 3 ou 4 autres à la base qui pourraient servir à la détection de la provenance du son. On peut alors imaginer toutes sortes de réactions du robot.

À noter : chaque microphone a besoin d’un petit circuit de polarisation, composé d’une résistance et d’une capacité de 5µF.

WiFi

Étant donné la présence de l’USB hôte sur la Beagleboard, nous pouvons pencher pour une solution de clef USB Wifi facilement trouvable dans la grande distribution (http://www.grosbill.com/4-bluestork_cle_wifi_nano_usb_wifi_n_150mbps-80561-reseaux-carte_reseau_sans_fil)

Une carte Wifi de facteur de forme SD pourrait toutefois être essayée (?).

Camera

Nous utiliserions là encore une Webcam très classique (http://www.grosbill.com/4-logitech_c120-100684-peripheriques-webcam) reconnue par linux.

Nous sortirions les différents composants de la coque de la caméra afin de pouvoir les intégrer dans un volume compact.