ELECINF344/381

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

Catégories

MB Led: weld of MB Leds and implementation of a remote

During the week end, we welded the MB Leds with Alexis. It was quite long but eventually we have our own blocks.

Benjamin created the remote functionality; It works quite well. If a block turns of 180°, it will be the remote to change the program.

I fixed some problems in the algorithm with the MB Leds and I will continue until the presentation.

After firmware transmission Cédric tried the firmware upgrade already implemented on TP PCB by Benjamin but failed to implement it on MB Led blocks in due time and eventually stopped his work : In fact, we have few time left and we prefer to focus on the presentation. Now, he will work on an animations.

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.

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.