ELECINF344/381

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

Catégories

IRL : Settings !

In our last article we described some ways to enhance the display of a text scrolling smoothly.
We actually tried several possibilities of settings for the scrolling text and finally found a convenient one (as shown on the video above).

We did some major improvements concerning the speed of the code on the card succeeding in speeding it by a factor of 5. We deemed that a major issue of that program lays on the access time of the memory. Indeed it takes more than 20 seconds to write an ILDA file of a tweet from the ram to the flash. Samuel suggested that we could use a socket to directly send the ILDA file from the python script to the C program in charge of the FPGA communication. In fact, with such a strategy we would avoid the slow speed flash access and be able to send a tweet to the laser around 30 seconds after its validation.

In addition we’re going to add some bit stuffing to make the frames equally populated in terms of points so as to assure a constant frame rate. You can easily notice that disturbing effect on the video above.

In parallel, we’re getting familiar with the DMX protocol and are working on the DMX board.
We haven’t forgotten the software fifo between the C program and the FPGA. We deemed that a zeromq socket would be a interesting solution and we are currently working on it.

IRL : Good news !

As you see, yesterday we were having fun with the laser trying to enhance the performances of our smooth text scrolling show. We now have embedded the whole program and it generates directly the ILDA file on board. We still have some speed issues, namely the program which generates the ILDA files is still pretty slow (it takes more than a minute for a tweet), but our imagination is thriving regarding optimization tricks and yet we gained a significant factor on the computing time.

We are also concerned about the beauty of the text. In fact we noticed a few effects in which we’re focusing on :

- When the laser goes more quickly, the line between 2 given points tends to look like a curve Solution : we are going to fix the derangement by adding several intermediate points between our points, this will be done in C at the end of the display chain.

- When the points are too faraway one from another, the galvanometers tend to be more noisy and we tend to be more worried about the survival of our system. Solution : we reduce the size of the text (so as to narrow the space between points) and insert intermediate points between the characters and at the end of the frame to make the shifts of position smoother.

- When the laser isn’t quick enough, we recognized that the flickering effect is more important.
Solution : we need to speed the laser up.

We did some major improvements on those different points not to mention the complexity issues. Step the text is getting more and more beautiful !

I’m sure you want to know a little more about our FPGA. We have enhanced our previous design by adding a RAM FIFO which will allow us to reduce the load of the CPU. We’re working on the CPU’s side of that program. Anyway, our security module seems to be a bit too sensible and it is triggering more often than expected.

In the next few days we will stress on the development of the DMX card.

[Casper] Flash, Screen and Pictures…

We’ve been working these last few days on the PCB, to display pictures and to save and load them from flash.

First, we developped a set of functions to erase, write and read the flash memory, using a SPI protocol. After testing it with text strings we displayed on the screen, we tried with pictures. However, the STM32 RAM is not big enough to handle a whole picture : we have at most 20kbytes RAM, and one picture takes 25kbytes (132*132 pixels of 12 bits, 4 for each RGB channel). So we read the flash per 256 bytes blocks that we send to the LCD screen, until transfer completion. Similarly, we write flash per 256 bytes blocks when receiving a picture from the UART connection.

In order to have a simple protocol for writing pictures, we do not allow two pictures to share a same memory sector (smallest erasable area). Since each sector is 4 kbytes wide, we use 7 sectors for each picture : that’s about 3 kbytes too large. However, this allows to store 146 pictures in the flash, which should be enough for our project. We did not work yet on the possibility of storing smaller pictures which could be used to refresh a small screen area. It may be useful for animations.

Finally, we use the screen configuration options to rotate pictures by 90, 180 or 270 degrees, changing the way the screen controller reads the RAM.

Moreover, we wrote a small program which uses OpenCV library (which is already used on the beagleboard for face detection and recognition) and converts a picture (jpeg, png, bmp,…) in a 132*132 12 bits picture and saves it in a file that can be sent to the PCB by UART.

IRL : Une journée fructueuse

Aujourd’hui nous nous sommes principalement concentrés sur le fpga.

Ram Spi
Nous sommes désormais capable de faire communiquer le fpga avec la ram spi : nous pouvons lire et écrire des valeurs dans la ram depuis le fpga (valeurs à écrire codées en dur dans le fpga, vérification des lectures à l’oscilloscope).

Le développement de la communication processeur-ram/spi à travers le fpga est bien avancé. Il est déjà possible de consulter sur l’armadeus la dernière valeur lue sur la ram/spi par le fpga. En revanche l’écriture n’est pas encore possible. Le contrôleur qui permettra au processeur d’indiquer les opérations (lecture / écriture/ adresse) qu’il souhaite réaliser est en cours d’écriture.

FPGA
Nous parvenons à afficher un point en codant ses deux coordonnées en dur dans le fpga. La prochaine étape consistera à piloter les coordonnées du point depuis le processeur.
Par ailleurs un module permet d’afficher une diagonale. Nous pourrons ainsi régler les potentiomètres des amplificateurs dès que nous aurons mis la main sur un tournevis !

Serveur Web
Nous avons peu travaillé sur ce sujet aujourd’hui. Nous avons recompilé les bibliothèques de buildroot avec les symboles de debug pour pouvoir comprendre pourquoi mongrel fait une erreur de segmentation au démarrage.

IRL : dure journée …

Nous avons eu beaucoup de doutes ces derniers temps concernant les choix à faire pour avancer. Voici ce que nous avons fait durant les deux derniers jours.


Serveur web

Comme pouvait le laisser penser notre dernier post, nous avons exploré les possibilités offertes par mongrel2.
Il s’agit d’une application qui multiplexe des requêtes http et les recopie sur des sockets 0mq (pour plus de détail : http://mongrel2.org/home).
Nous avons testé mongrel sur nos machines avec succès et il nous semble tout à fait adapté pour résoudre nos problèmes.
Nous avons essayé de le crosscompiler mais sommes confontés pour l’heure à des problèmes.
À terme, nous voulons l’intégrer dans notre buildroot.

ILDA

Nous avons l’ensemble des caractères ISO8859-15 sous la forme de fichiers ILDA. Et nous avons trouvé une nouvelle police qui donne des meilleurs résultats. Nous avons fait un script qui nous donne le numéro du caractère ISO8859-15 entré sur stdin.

Twitter

Nous nous sommes familiarisés avec Twitter et nous réussissons à récupérer les tweets portant le htag #rose2011 directement sur la carte.

FPGA

Nous avons synthétisé et testé sur le FPGA un code utilisant une des rams internes du FPGA et permettant d’y écrire et lire depuis le processeur. Nous sommes en train de parler à la ram SPI qui nous reste (en effet, nous avons mal routé une des deux rams SPI dont nous allons peut-être devoir nous passer).

Authentification

Nous avons clarifié nos idées concernant la manière dont l’authentification sera mise en oeuvre sur la carte. Nous nous repencherons sur la question quand mongrel2 marchera.

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

IRL : Journée PCB 1/2

Aujourd’hui nous avons travaillé sur les schémas des cartes Laser et DMX. Ils sont normalement terminés, il ne manque plus qu’à vérifier que nous n’avons pas fait d’erreurs. Nous avons commencé le placement routage que nous poursuivrons demain.

Il a été décidé que nous utiliserons non pas une mais deux blocs de RAM pour le stockage des images sur le FPGA. Laurent a commencé à développer un module Verilog pour les lectures/ecritures dans ces mémoires.

IRL : Avancées de la journée

Aujourd’hui nous avons eu l’occasion de rencontrer un étudiant qui a travaillé il y a deux ans sur le projet Laser.
Nous lui avons expliqué l’architecture de notre projet et avons récupéré une partie des sources de son projet.

Nous avons mené des essais avec les cartes de TP concernant la transmission par zigbee des masques pour le flux DMX. Ces essais ont été concluants : nous arrivons à transmettre et recevoir sans erreurs différents masques DMX et à les stocker en RAM.

Nous cherchons une police adaptée au laser et sous forme de fichiers au format ILDA pour pouvoir afficher du texte sur l’écran. Nous avons constaté que l’équipe de l’année dernière a réalisé des caractères au format ILDA qui ont un bon rendu avec notre afficheur ILDA.

Nous avons par ailleurs décidé en suivant les conseils d’Alexis d’utiliser une RAM externe pour notre FPGA (ram SPI 256Kbits code radiospare : 666-8148).

Nous sommes en train de réaliser les PCB, de faire des simulation en Verilog et de réfléchir au format de stockage des informations à afficher par le laser dans le FPGA. Nous attendons l’Armadeus dont nous disposerons peut-être demain.

IRL : choix des composants

Après une semaine bien occupée par le TP STM32, nous nous sommes penchés sérieusement sur le choix des composants pour le laser.

DAC : il nous faut 2 DACs pour contrôler les valeurs X et Y du laser, nous avons opté pour un DAC parallèle 12 bits 2 voies (AD5342). l’interface parallèle le rendra plus pratique à piloter à l’aide d’un FPGA qu’une interface SPI, 12 bits offrent une précision d’environ 1mm sur une surface de projection de 3m x 3m, ce qui nous paraît suffisant.

Amplificateurs : Le DAC choisi offre une sortie 0 – 3,3V, or nous avons besoin de 0 – 10V pour piloter le laser (si on branche les pins négatives à la masse), il nous faut donc un amplificateur x3, ce qui se fera à l’aide d’un AO et de deux résistances, l’une double de l’autre. L’AO présent dans Mentor nous laisse perplexe (le nom fait référence à un AO double, l’empreinte en montre un simple).

FPGA de l’Armadeus : un grand nombre d’IO, ce qui rend possible l’utilisation d’un DAC parallèle. Les IO peuvent sortir du 3,3V, ce qui permettra de piloter directement l’allumage/extinction du laser sans intermédiaire. Le modèle de FPGA dont nous disposons (Xilinx Spartran XC3S200A sauf erreur) possède 288 kbits de RAM block, ce qui permet de stocker environ 6000 points ILDA standards (1 point ILDA = 16 bits X, 16 bits Y, 8 bits couleur, 8 bit on/off), à savoir un peu moins d’une demi seconde d’image au débit max de 15000 points par seconde. Un chip de RAM externe semble donc inutile, d’autant plus que la représentation interne au FPGA pourrait se passer des 8 bits de couleur).

Zigbee : l’armadeus possède deux UARTs, dont une est reliée à deux pins métalliques sur lesquels on pourra simplement brancher des fils allant jusqu’à la carte additionnelle sur lequel sera soudé un module Zigbee identique à celui de la carte de TP (et identique à celui de la carte DMX).

Voici comme les schémas bloc de nos cartes (en PNG désolé, wordpress me refuse l’upload d’un SVG) :

Schéma de la carte Armadeus, carte additionnelle laser

 

 

Schéma de la carte DMX

en train de déterminer les composants

Pour la carte centrale du projet train, nous aurons besoin d’utiliser un port Ethernet pour recevoir les commandes de Rocrail et un port du bus CAN pour recevoir les comptes rendus.  Nous avons trouvé le microcontrolleur STM32F107RA qui contient les deux.D’après nos estimations, RAM et ROM seront largement suffisants pour notre application.

Pour obtenir le signal DCC concernant les Leds, on aurait besoin d’un optocopleur branché sur les rails. L’alimentation sera faite aussi à partir des rails à travers un circuit régulateur de tension. Pour allumer des feux , on aura besoin d’un « Led Driver ».  Pour choisir son type, nous devons nous décider combien de feux pilote une seule carte.