Site ELEC344/ELEC381

Partie interactive du site pédagogique ELEC344/ELEC381 de Télécom ParisTech (occurrence 2010).

Catégories

GLiP : Problème d'affichage

Lundi matin, j’ai commencé à réviser la routine d’affichage car de différents problèmes sont apparues quand on a testé la communication par IRDAs avec l’affichage. Cela est dû au fait que les 4 UARTS qui gèrent les IRDAs interrompent la tâche qui gère l’affichage. Comme résultat des petits points se voient dans les LEDS.

L’après midi, SAM à recommandé de refaire la routine de d’affichage en utilisant que l’interruption par le TIMER.

Hier soir, j’ai réussi à faire marcher le SPI en utilisant le module DMA.

Aujourd’hui (Mardi) je me suis dédié à continuer l’implémentation d’une nouvelle routine d’affichage. Par contre je suis seulement arrivé à montrer une ligne, mais pas une image complète correcte. Après d’avoir parlé avec SAM, une modification plus profonde dans ma façon de générer le PWM pour les LEDS semble d’être le problème.

Finalement un bootloader qui marche!

Aujourd’hui, Flavia et moi, on est resté très longtemps pour essayer de faire marcher le bootloader de l’année dernière. En fait, depuis vendredi dernier j’essaie de l’utiliser.

On a vu qu’il y a avait plusieurs erreurs dans notre code, surtout dans la partie de communication serial-can. Tout d’abord, on n’arrivait pas à recevoir les ACKs de la carte-vertèbre (problème de la communication can). Ensuite, ce que notre carte du tp recevait de la petite carte n’était pas envoyé vers le PC (problème de communication série).

Tout corrigé, notre carte se bloquait après quelques instants d’exécution. Le problème : l’impression sur le lcd apparament mettait très longtemps. On les a viré.

À la fin, le bootloader a marché. J’ai écrit un programme qui n’a pas marché (celui qui fait le test d’un seul moteur), et ensuite j’ai flashé le main de l’année dernière et tout a été exécuté normalement.

Réseau Wheely

Hier, j’ai passé trois heures à essayer en vain de recevoir des informations par UART en les entrant dans minicom pour m’apercevoir que le câble qui connecte la carte à l’odrinateur était en train de se désouder.

J’ai aussi fait un programme permettant de commander la vitesse des roues en l’écrivant dans minicom, puis en passant par la carte logique par UART et enfin à la carte de puissance par CAN.

J’ai ensuite adapté le code de commande des servos-moteurs fait par le club robotique (merci!) pour pouvoir faire des tests d’angle et de vitesse avec notre carte logique. Ce code fonctionne bien, donc nous allons pouvoir commencer les tests.

J’ai commencé à relire ce que nous avions décidé pour le LQR et les fichiers Matlab. Nous devons nous synchroniser avec Fabien pour avoir un code bien cohérent entre ce qui sera fait sur la carte logique et ce qui sera fait sur la carte propulsion.

Ce matin, j’ai ajouté le code de l’UART au code de la carte propulsion et j’en ai profité pour harmoniser tout le code avec le code de la carte logique.

12/04

Aujourd’hui j’ai été surtout sur le code du bootloader. Comme il n’y a ni jtag ni boot mode ram sur les cartes des vertèbres, on doit les flasher afin de faire tous nos tests.

J’ai mis un moment pour comprendre comment utiliser le bootloader de l’année dernière : on doit exécuter un scrip python, qui va lire le programme (binaire) et l’envoyer vers les cartes. Notre carte du tp fait l’interface entre l’ordinateur et les petites cartes à travers le port serial (elle reçoit les données par le serial et les envoie par le CAN).

Cette après-midi, Jon nous a aidé à utiliser ce script python. On a vu qu’il manquait encore quelque traitement de message et c’est sur ce code qu’on travaille. La carte du Tp reçoit bien les données, mais il manque les headers des messages can et le traitement des acks.

Premier test du usart GLip

Hier soir (Dimanche 11) j’ai fait un petit test sur les périphériques de communication de la carte de LEDS.

J’ai ajouté à mon programme d’affichage une routine d’interruption par uart 3 (et après pour le uart 1 et 4 aussi), pour qu’il change l’image montré à chaque fois que le module recevait quelque chose dans le porte serial: J’envoyais un caractère depuis une porte et le recevait par une autre (en utilisant une feuille blanche), et après j’envoyai et recevait dans le même porte en utilisant un miroir. Dans le deux cas, il à commencé à interrompe correctement.

Par contre quand j’ai voulu ajouter une condition et voir si effectivement je recevait  ce que j’envoyais, je trouvé qu’il y avait un problème.

En utilisant un multimètre je constaté que le PIN de réception du STM32 était toujours à zéro. Je n’ai pas continué avec le test parce que j’ai pensé qu’il serait mieux de voir qu’est-ce qui se passait avec un oscilloscope.

Mes routines d’affichage d’une image, et ceux du test ont était ajoutés au dépôt du groupe.

Communication et harmonie...

Hier, j’ai harmonisé le code qui avait été codé par chacun d’entre nous et donc avec différentes conventions… ça a ainsi permis au groupe d’arriver à un concensus sur la structure du code.

Aujourd’hui, j’ai enfin réussi à faire marcher la communication par l’UART1, et j’ai donc pu afficher les données filtrés de l’accéléromêtre et du gyroscope, ayant ainsi la confirmation que le code global fonctionne bien.

Ensuite, j’ai fait une fonction qui teste l’identifiant de la carte, pour qu’on ne puisse pas faire fonctionner le code prévu pour la carte logique sur une carte IMU et inversement. Cette fonction focntionne bien.

A l’arrivée de Daniel, nous avons pu tester mon code sur une carte IMU, nous avons bien réussi à allumer les LEDs simplement en changeant le #define dans le fichier de configuration global.

Nous avons eu pas mal de problèmes avec le bluetooth qui ne fonctionnait même plus avec la carte IMU. Nous avons finalement réussi à le faire fonctionner sur la carte logique! Il nous a semblé que les coordonnées que l’on additionne n’étaient plus les bonnes (on additionne le x de l’accéléromêtre avec le y du gyroscope). Daniel fera plus de tests et corrigera les calculs demain.

Et moi, je vais pouvoir me lancer dans le codage du LQR!

Carte logique wheely

Hier, j’ai fait fcontionné le bus CAN sur la carte logique de Wheely, ce qui m’a permis de communiquer avec ma carte de TP et donc de pouvoir faire du débuggage plus parlant sur l’écran LCD. J’ai donc pu m’atteler au fonctionnement du gyroscope qui a fonctionné ce matin.

Ensuite, je me suis occupée des interrupteurs qui m’ont posé pas n=mal de problèmes en particulier parce qu’ils sont sur le même handler d’interruption.

Le gyroscope fonctionne aussi, et l’accéléromêtre étant exactement sur les mêmes pins sur notre carte que sur la carte IMU, il n’y a pas de modifications à faire sur la partie du code le concernant.

J’ai ensuite essayé de faire fonctionner l’UART1, mais pour l’instant mes essais ne sont pas concluants…

J’ai aussi fait un fichier utils.h avec les fonctions de base, qui contient pour l’instant atoi et itoa.

J’ai fais quelques recherches sur la récupération de l’ID des cartes, dans le but de faire une fonction qui vérifie qu’on a bien fait les #define qui conviennent à la carte connectée.

Retour sur à nos moutons !

Aujourd’hui, après de trop nombreux jours en dehors de la A405 ( formation humaine intensive … ), je retourne enfin à des occupations normales.

Cet après-midi, j’ai rendu mon code plus modulable : fonctions de lecture et écriture sur le Zigbee, fonctions d’écriture par ligne sur le LCD, petit retour sur les queues pour avoir quelque chose de vraiment propre ( queue de message rx/tx pour le Zigbee, par ligne pour le LCD et de notes pour le buzzer ).

Alexis m’a aussi installé un potentiomètre, j’ai donc écrit du code pour le ADC qui nous servira plus tard sur l’Heliokter, je peux maintenant utiliser mon slider comme instrument de musique.

Préparation psychologique pour le challenge de demain (aux aurores -_- )

Carte IMU : état des lieux

J’ai commencé à travailler sur la carte IMU ce week-end mais je me suis vite retrouvé bloquer par une erreur. Lundi matin, la lumière a été faite, il s’agissait d’une erreur des routines de startup de ST qui a été patchée par Samuel.

Je me suis attelé ce soir à essayer de faire marcher le Bluetooth pour pouvoir établir une communication avec un PC, ce qui me semble nécessaire avant toute chose, pour éviter de travailler dans le vide (la carte IMU ne comporte pas d’écran).

Après avoir essayé « au bluff »  (en faisant confiance à la configuration par défaut, pourtant alléchante) de connecter ma carte à l’ordinateur, je me suis résolu à essayer de la configurer. Et ça ne fait pas de mal, ne serait-ce que pour s’assurer que l’UART est bien branchée … (attention, l’UART3 est remappée !).

La datasheet du module Bluetooth et notamment du mode « Wireless UART »  est très documentée et contient plusieurs exemples de configurations. Pour une configuration donnée, elle donne même la séquence des requêtes à faire et la séquence de réponses que l’on reçoit, ce qui me permet d’avoir une référence solide et sûre.

Quand j’essaie d’éxecuter ces requêtes de commande, les deux premières renvoient des réponses positives (« entrée en mode commande » puis « endpoint mode ») mais la suivante, chargée de configurer les paramètre d’authentification et de jumelage est mal acquittée : le numéro de commande renvoyé  ne correspond pas !

Ca me semble assez étrange puisque ce n’est pas vraiment l’erreur de l’execution de la commande (qui aurait renvoyé le bon numéro de commande avec un statut d’échec) mais l’execution d’une commande erronée (je reçois le mauvais numéro de commande mais le statut de réussite).

Je n’ai  pour le moment pas trouvé de solution à ce problème, je laisse la nuit me porter conseil …

TP vendredi

Aujourd’hui j’ai finalement pu corriger le problème de réception de mon zigbee. En fait, le problème n’était pas lié à la configuration de l’uart3 ou à l’algorithme que j’utilisais pour la réception d’un caracter, mais à une manque de configuration du prescaler du clock (configuration du hardware – premier tp). Merci, Sam, pour l’indication de l’erreur!

Ensuite je me suis lancé à la transmission de caracter et à la synchronisation avec la carte de Sam. Je n’ai pas eu beaucoup de temps pour rechercher dans la doc et pour écrire mon code. Je continue là à partir de la semaine prochaine.