ELECINF344/381

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

Catégories

TSV Safe Express:the day of SPI and Led Driver

We had some hardware problems with our Led Driver today, but finally (thanks Alexi) we could test our programs for SPI and initialization of our Led Driver. Now we can control lights from the Led Driver. We are mapping light commands(from the Led Driver) to corresponding CAN messages.

We have progressed on the work on the CAN bootloader. We have been able to send data from the PC to the final card passing through a dummy card which transforms UART messages to CAN messages.

We have been able to simulate the sensors card on our TP card. Now we are able to send an event (pressing the botton) to central card.

 

 

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:)

 

 

 

 

 

 

TSV Safe Express: Le débogage avec bus CAN

Hier, nous avons eu problèmes avec multiple nœuds. Alors, aujourdhui, nous essayions de stabiliser le protocol NMRA pour le bus CAN. Un problème intéressant a été les paquets du bus CAN ne sont pas dans le bon ordre. Qu’est-ce qui se passait?
Notre théorie est la suivante. Nous avons « transmit mailbox » dans le contrôleur CAN avec la capacité de 3. La fonction de transmission de la bibliothèque CAN tente de trouver « transmit mailbox  » vide et envoyer le paquet. Supposons qu’il écrit le premier paquet en deuxième mailbox , puis premier mailbox (car il a trouvé les mailboxes vide dans cet ordre). Mais la transmission de messages CAN commence de 0 mailbox. Ainsi, les paquets ne sont pas envoyés dans l’ordre correct.

Une solution possible peut être de s’assurer d’utiliser une seule mailbox pour envoyer des messages CAN. Cela peut être réaliser en commençant par transmettre CAN gestionnaire d’interruption qui se synchronise avec le CAN transmettre fonction à l’aide de sémaphores. Mais, avec ça nous ne pouvons pas prendre l’avantage de trois mailbox. D’autres solutions sont les bienvenus.

Avec, le bootloader, nous avons réussi en faire le lecture et écriture sur le flash. Maintenant, nous sommes en train de faire le l’autre choses de bootloader comme le usart.

Nous avons reçu noter carte feux. Demain, nous allons faire le SPI pour cette carte.

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.

TSV Safe Express: NMRAnet CAN bus.

Après les tests que nous avons fait sur le mode loopback du bus CAN, aujourd’hui nous avons relie nos cartes de TP afin de teste les modules que nous avons développé jusque a maintenant. Nous avons commence avec deux cartes. Nous avons utilise une carte comme un « central station » et l’autre comme une « carte feux ».

En développant le code nous avons essayé de suivre aussi strictement que possible  la norme CAN bus de NMRAnet, concernant le format des messages CAN, la gestion du réseau et les mécanismes de configuration des évènements producer/consumer. Nous avons utilise le mode « extended identifier » des 29 bits du bus CAN, et nous l’avons forme respectant la norme NMRA. La gestion du réseaux est responsable pour l’assénement des adresses des nœuds et pour détecter l’état du circuit. Les adresses qui sont assignes par le « network manager »  sont utilisées soit pour identifier l’état d’un nœud avec une adresse x, soit par le « configuration tool » pour configure le table d’événements du node avec une adresse x. Ca veut dire que a la suite, si le station central veux allume un feu, il n’envoie pas un message du type <adresse x><événement>  mais il envoi seulement l’événement.

Pendant la journée nous avons vérifie le fonctionnement du système en utilisant un station central et une carte feux. Nous avons réussi de allume les leds de la carte feux. A la suite nous avons essaye d’ajouter une carte feux en plus, mais les résultats n’étaient pas satisfaisants.. Au même temps nous avons réussi a configure les filtres CAN et nous avons commencé a écrive du code pour le bootloader CAN.