ELECINF344/381

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

Catégories

MB Led: Easter Saturday in A405

Today, we continued on our recent work : I worked on the algorithm and on the rotation of a block. The rotation works quite well now. The algorithm for this rotation is simple : When a communication between two blocks is stopped (due to the left of someone), the two blocks save their « interfaces » (aliases of the UARTs ). When there is a PING from a block, we check the saved interfaces in order to see if the block was a « friend » of this block. If it’s the case, we just calculate the rotation of the block.

The main problem is that a block can communicate with 4 others blocks at the same time. So, sometimes, we have to wait a little bit when we want to compare the interfaces.

Cédric noticed in the afternoon a bug in the IrDA functions and we fixed this. Now, the IrDA has more reliable and there are few problems in the network.

I still have problems when two networks meet with more than one block each involved in the « deal » but things are going better each day.

Benjamin worked on the launcher task. He thought of a remote block who can control the animation/game that will be played soon after.

Cédric continued the firmware transmission and the protocol is actually functional at good speed. But he is now facing problems with flash writing.

 

Here is a little video of the synchronization (running on the GLiPs but the MBLed are arriving soon):

 

Every block knows its i,j and minI, minJ, maxI, maxJ in the network. The block in the north-west shows a M; north-east a B; south-west LE: south-east D. If he is alone, he shows a M too.
That’s why sometimes in the video, there are 2 M : one of the block has encountered problems and reset himself.

For the synchronization, the leader gives the time every 20 PING (approximately every second), when a block receive that, it transmits it to his neighbor and so on.

 

 

MB Led: Synchronization, algorithm reliability and improving IrDA transmission

Since yesterday, Guillaume worked on algorithm reliability, improving its performance and solving some problems such as information sharing (number of blocks in network, position…). Some loop-back which were over-charging the network have been deleted. He worked with Benjamin to improve the algorithm but some problems remain unsolved… In late afternoon, the algorithm was working rather well : in a 9 blocks network, blocks detected the good number of blocks, their position, the leader ID, the positions of the others in many cases. But sometimes, one block loses his IrDA connection so he has to start again the algorithm. When dividing a network in 2 networks, the blocks graph (developped with Benjamin) gives the blocks good informations.

Benjamin worked on improving the snake game, now it has a tail and if you cut it (meaning you disconnect blocks before the tail leaves) you lose. Some apples have shown their faces on the screen, but we must handle turn detection before evolving furthermore. He also worked with Guillaume on the implementation of a blocks graph in order to react faster when a block leaves the network. In fact, if a member leaves, blocks are able to calculate that every members of the branch also left. At last he tested synchronisation implemented by Guillaume displaying an animation on MB Leds, it is pretty quick and all blocks flash at once.

I have first worked on improving some aspect of IrDA like variable waiting time before a resend and size of packets in order to improve the  payload . I have continued  to implement firmware transmission and have begun testing it. Transmission seems a bit slow and tomorrow I will look for a way to improve its speed.

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.

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

[CASPER] PSSC

After some over-the-internet discussions, we finally agreed on the following list of goals and milestones :

A interface task is placed between SVOX Pico and ALSA on the beagleboard  – 04/18  Thibault
The beagleboard and Casper PCB communicate over an UART link – 19/04  Alain
We store and read images to and from the flash memory on the Casper PCB – 20/04  Alain
We are capable of having the beagleboard read a text file out loud – 20/04 Thibault
The beagleboard is able to recognized predetermined vocal commands – 21/04  Thibault
The LCD display adapts itself according to the robot’s orientation – 22/04  Alain
We are capable of controlling the robot’s tilt angle  -  22/04  Thomas
We are capable of controlling the robot’s orientation (azimuth) – 22/04   Thomas
The robot as been assembled, and the devices (camera, PCB, …) are on board – 23/04  Thomas
We can make the robot track a face (the robot’s orientation follows slow mouvements) – 25/04   Alain
The API we previously defined is accessible from LUA scripts - 27/04   Thibault
The robot is capable of accessing a simple mail box (without encryption protocols) – 28/04   Alain
The robot has a simple remote http setup interface – 29/04   Thomas
We use a LUA script, using the API, to drive the robot for the demo – 29/04   Thomas
The servomotors are being driven by a linux device driver on the beagleboard – 29/04  Thibault

[CASPER] Demo de vendredi et API RS232

Voici dans ce post un bilan de la démonstration de Vendredi, ainsi qu’un bref état des lieux des avancées d’aujourd’hui concernant la programmation série en C sous linux.

 

Démonstration de vendredi

Nous avons Vendredi fait état de nos dernières avancées.

Nous avons débuté la démonstration par la présentation du PCB que nous avions réalisé et qu’Alexis nous avait remis il y a peu. Alain a, comme il l’a montré dans un post précédent, réussi à piloter l’écran LCD et afficher une animation simple comportant des rectangles de couleur et du texte.
Reste maintenant à réaliser l’interface série entre la carte et un ordinateur, puis programmer la mémoire flash embarquée.

Nous avons poursuivi par la démonstration de Thomas qui a piloté par l’intermédiaire de la carte de TP STM32 l’un des servomoteurs que nous allons utiliser. Grâce à son programme, nous sommes capables de piloter ces moteurs en leur fournissant une consigne angulaire.
Reste désormais à piloter le prototype en installant trois servomoteurs dans sa base.

Nous avons ensuite effectué une démonstration logicielle qui rassemblait les « helloworlds » que nous avions réalisés avec les différentes bibliothèques. Nous avons ainsi pu piloter à la voix l’ordinateur, lui demander de faire l’apprentissage de deux visages, puis de passer en mode reconnaissance. Une fois en mode reconnaissance, le moteur de synthèse vocale interfacé pour le moment avec pulseaudio a salué les visages connus en les nommant par leurs prénoms.

 

Comme Thomas l’a signalé dans son billet, nous avons pour le moment mis de côté le développement de drivers, pour nous concentrer essentiellement sur la mécanique, la programmation du PCB, et le port de nos applications sur la beagleboard.

Afin de préciser notre démarche, nous publierons bientôt sur ce site une liste actualisée de nos PSCC et des responsables associés.

 

Avancées de la journée : API RS232

De mon côté, je me suis penché sur la programmation du port série en C sous linux. J’ai trouvé à ce sujet une excellente source de documentation, qui m’a permis de comprendre rapidement l’interface posix permettant d’en effectuer la configuration. Vous retrouverez ce guide ici.

J’ai créé une interface de plus haut niveau permettant de lire et d’écrire sur un nombre indéfini de ports série, et de rentre transparente la gestion des lectures et écritures avec tampon.

Il suffit en effet pour utiliser un port série d’en demander l’ouverture en précisant le fichier /dev/tty* associé, et de donner en argument la fonction que l’on souhaite être appelée pour traiter les données.

L’API se charge ensuite d’appeler cette fonction lorsque de nouvelles données sont disponibles, ainsi que d’écrire les données stockées dans des tampons chainés lorsque le matériel est prêt.

L’utilisateur peut donc utiliser des fonctions non bloquantes pour écrire, et utiliser ses propres fonctions pour lire.

Pour finir, bien que cela ne soit pas encore implémenté, il est possible d’ajouter à cette API les sockets en plus des ports série. Cela permettrait de gérer par le biais d’une interface unique toutes les transmissions de la beagleboard, que ce soit par réseau ou avec le PCB.

TSV Safe Express: Résultats et précision des PSSCs

Après avoir fini l’écriture de mon Bootloader CAN je l’ai testé avec un programme que j’ai écrit  pour envoyer des messages en CAN suivant le protocole implémenté. Et là  j’avais un petit problème: si j’utilise mon fichier d’initialisation le CAN marche mais l’écriture en Flash ne marche plus et si j’utilise init.c de la bibliothèque c’est l’inverse. Après avoir comparé les deux nous sommes arrivés à booter en flash à partir du Bootloader CAN.

D’autre part, il me reste de tester mon programme qui prends des messages via UART et les envoie par CAN. Je ferai lorsque le serveur sera en marche.

Ce que nous faisons dès l’après midi est de lire chacun le code des autres pour être sur du respect de la norme NMRA, voire les éventuelles erreurs et en même temps comprendre ce que nous avons fait séparément. Nous  continuerons ensemble à finir la partie CAN: relier plusieurs cartes en même temps et commander les feux et capteurs.

Nous actualisons nos prochains PSSC et nous déclarons les responsabilités après une dispute sur qui prend celle de Ethernet:)

 

 

 

 

 

 

[Casper] Carte STM32

Nous avons aujourd’hui poursuivi la prise en main de notre carte, en commençant par l’écran. Mauvaise surprise, il se commande en SPI 9 bits, et le STM ne fait que du 8 ou du 16 bits. D’après certains forums, il est possible de contourner le problème en utilisant un USART, mais malheureusement aucun USART du STM n’est remappable sur les pins que nous avons choisis pour contrôler l’écran. Nous avons donc dû commander l’écran en bit-banging. Nous nous sommes appuyés sur le tutoriel de James P. Lynch, très clair, pour les protocoles d’initialisation de l’écran et d’écriture. Celui-ci fournit également trois fontes de caractères dans un format facilement utilisable. Notre écran est à base de contrôleur de type Epson (l’écran peut en effet être à base de deux types différents de contrôleurs), mais la plupart des pins de configuration ne sont pas accessibles depuis la sortie de l’écran (comme celles permettant de faire du SPI 8 bits…).

Heureusement, la flash se commande quant à elle en SPI 8 bits, et l’utilisation du DMA devrait permettre de soulager un peu plus le processeur lors du chargement d’images à afficher…

Prochaine étape : communication UART pour envoyer des images à afficher, et les stocker dans la flash.

 

MB Led: Firmware, Bluetooth, bibliothèque graphique.

Depuis dimanche j’ai eu l’occasion d’avancer sur différentes parties:

Firmware:

Comme je l’explique dans mon précédent article nous mettons en place un système de mise à jour de firmware via IrDA. Mon travail a été d’implémenter, en utilisant les bibliothèques ST, les fonctions de déplacement de secteur de la flash depuis un bootloader situé en début de flash. J’ai effectué mes tests sur la carte de TP et utilisé objdump et openocd, ainsi que deux versions du « firmware » pour mes tests (un qui éclaire la LED en bleu et l’autre en vert). Une phase de débugage assez longue: des pages qui sont effacées sans le vouloir, la raison étant que la ligne de commande openocd faisait un « reset halt »  qui relancé l’ancien bootloader pour un nombre indétrerminé d’instructions, effaçant ainsi des mauvaises pages. Désormais on peut manipuler la flash à notre guise depuis le bootloader et effectuer la phase de recopie du nouveau firmware avant de l’exécuter sans problème.

Bluetooth:

J’ai commencer à implémenter réception/émission de commandes/réponses coté MB Led. Dès que je récupère un module bluetooth F2M03GLA, je pourrais faire des premiers tests de communication avec un client bluetooth sur mon pc.

Bibliothèque graphique:

Ecriture de premières fonction de manipulation des images, inspirées du code GLiP et d’autres plus adaptées au mode jeu (affichage de sprites, de lettres …).

A faire:

Nous devrions bientôt récupérer quelques unes de nos cartes avec les composants soudés. Je pourrais alors tester mon code pour le driver LED. En attendant je continue d’avancer sur les trois points précédents.