Site ELEC344/ELEC381

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

Catégories

J-22

Alors comme ça fait plusieurs jours que je n’ai pas mis à jour voici ce que j’ai fait durant les derniers jours :

Jeudi 15

J’ai amélioré mon code de benchmark, voici des résultats plus extensifs sur les opérations :

.

.

Math timings double Timing ( µs ) Cycles

.

offset add mul div cos sin abs sqrt abs

.

offset 14492 14.492 1043.424

.

add 28827 28.827 2075.544

.

mul 28823 28.823 2075.256

.

div 28826 28.826 2075.472

.

cos 14464 14.464 1041.408

.

sin 14487 14.487 1043.064

.

offset abs 14463 14.463 1041.336

.

sqrt(abs()) 41676 41.676 3000.672

.

Math timings floats

.

offset add mul div cos sin abs sqrt abs

.

offset 14501 14.501 1044.072

.

add 28826 28.826 2075.472

.

mul 28855 28.855 2077.56

.

div 28855 28.855 2077.56

.

cos 14473 14.473 1042.056

.

sin 14492 14.492 1043.424

.

offset abs 14501 14.501 1044.072

.

sqrt(abs()) 42032 42.032 3026.304

Je ne suis pas vraiment satisfait car les résultats ne me semblent pas vraiment cohérents, mais peut être est-ce à cause de l’influence de divers paramètres pas controlés : cache, optimisation, autre.

Explication de la méthode : le temps à gauche représente le temps d’exécution pour 1000 opérations en µs.
offset : temps d’exécution d’une fonction pour avoir une nombre alétatoire double ou float( mul, add, modulo, sauvegarde dans une variable double ou float static ), fonction appelée myrandd() ou myrandf()
add/mul/div : 2 appels à myrand, 2 cast int->float ou double, addition/mulitplication/division des deux nombres et sauvegarde dans une variable float/double.
cos/sin : 1 appel à myrand(), 1 cast, 1 sauvegarde
offset abs : 1 appel à abs( myrand( ) ) 1 cast et 1 sauvegarde
sqrt : 1 appel à sqrt(abs(myrand( ))) 1 cast et 1 sauvegarde

Le problème est que l’on ne peut pas vraiment soustraire l’offset des opérations … car le temps d’exécution n’est pas vraiment linéaire. Un autre point qui m’étonne est le nombre de cycles qu’il faut pour faire une simple addition …

Bref je vous donne les résultats as is, car j’ai du mal à les interpréter. On retiendra qu’une opération arithmétique sur un double ou un float est du même ordre de grandeur : quelques dizaines de µs.

Vendredi 16

J’ai écrit le code pour les télémètres, ce qui était assez rapide puisque j’ai juste eu à m’intégrer dans le code de FX pour les gyros. Mais comme les télémètres étaient bloqués au Royaume Uni à cause de l’arrêt du traffic aérien, une fois mon code fini, j’en ai profité pour me mettre à jour sur le code qu’avaient écrit les autres.

J’ai aussi commencé à nettoyer mon code et à agencé un peu l’architecture globale du code.

Samedi , Dimanche, Lundi 19

Vacances

Mardi 20

Retour en A405 par une magnifique journée de printemps. Aujourd’hui j’ai écrit le squelette de notre version propre alpha pour l’heliokter avec des prises de sémaphore bien claires, des delays là où il faut et une beau découpage en fichier pour la compilation séparée. Ca m’a pris un peu de temps dans le sens où j’ai du lire le code un peu de tout le monde et réfléchir à comment wrapper les fonctions de chacun pour ne pas avoir à réécrire trop de choses.

Ensuite comme les télémètres étaient arrivés, j’ai pu vérifier mon code, qui marchait du premier coup ! ( merci FX ) ensuite j’ai pu étalonner le télémètre et maintenant je récupère une distance en cm. Celle-ci est bonne pour une distance entre 8cm et 70 cm environ ( comme nous n’avions qu’une règle de 30 cm ( merci Flavia ) , les mesures au delà de 30 cm n’étaient pas très précises).

La méthode pour étalonner : regarder la valeur en « int12″ renvoyée par l’ADC à 8 cm, celle renvoyée à 30 cm, regarder la courbe sur la datasheet qui ressemble fortement à a/x+b, ensuite trouver a et b à partir de ces deux points. Ci dessous le résultat sous forme de courbe ( axes : distance en cm )

  • En rouge : y=x
  • En vert : y= f(x) où f est la fonction d’interpolation. Dans l’idéal elle devrait donner l’identité.

C’est assez satisfaisant !

Mercredi 21

Aujourd’hui on a réussi à avoir une version « sale » mais complète du code qui compile ( c’est à dire senseurs, filtrage, asservissement et moteurs ).

On a ensuite fait un vol d’essai pour faire une acquisition et un test du filtre de Kalman depuis notre propre carte. Ce qu’on a constaté dans ce premier vol et qui m’inquiète un peu c’est que les angles mis en jeu pour le roll et le pitch sont très faibles, je me demande aussi l’amplitude des valeurs utilisées par les moteurs ( +- 3 sur un unsigned char ou bien +- 100 ? ).

carte SD en grève

aujourd’hui je me suis joint à Thibaut pour travailler sur la carte SD. On était partis pour essayer de lire et d’écrire en mode polling, ce qui est une mauvaise solution car trop gourmande en CPU. Samuel nous a aidé à mettre en place la lecture en mode DMA. Après nous avons passé le reste de l’après midi à comprendre pourquoi la carte ne voulait pas écrire, alors que la procédure (du moins les fonctions de la bibliothèque ST) pour écrire est très proche de celle pour lire.
Cependant nous nous sommes heurtés à des erreurs de validité du CRC sur les données émises. Nous avons cherché à désactiver la vérification du CRC sur les cartes (au moins histoire de voir si on pouvait réellement écrire), et d’après les datasheets, ca n’est pas possible. Ca m’étonnerait que les polynomes utilisés pour le CRC soient différents, car ils fonctionnent en lecture. Ce n’est pas non plus un problème d’horloge (la datasheet demande une horloge AHB égale à FCLK/2, mais les commentaires de la bibliothèque ST disent le contraire (FCLK), nous avons essayé les deux).
Après quelques recherches sur internet, les seules réponses que nous avons vues sur des problèmes similaires sont du type « ta carte est foutue, jette la et prends en une autre ». Ca m’étonnerait aussi qu’il faille faire calculer nous mêmes le CRC, car le module est interne au controleur SDIO, et on n’a pas du tout la main dessus.

A noter que sur une autre carte nous avons eu un problème de délai dépassé pour l’écriture des données, qui du coup a du masquer le problème d’erreur de CRC.

Au final, on s’est cassé les dents. A la rentrée, il faudra qu’on règle ce problème rapidement, ou bien on devra envisager d’autre moyens de faire passer des données vers la carte par ethernet (en streaming par exemple, ce qui avait été écarté jusqu’à présent)

Bonnes vacances à tous !

Heliokter: Wahba

Aujourd’hui:

Première version d’une bibliothèque de quaternions (samble marcher).

Première version du FQA (semble marcher).

Hier:

Lecture du protocole i2c (partie théorique et le datasheet).

Première version d’une bibliothèque i2c.

Avancé projet et présentation

Aujourd’hui j’ai continué dans la recherche autour de GLiP, notamment on a mis au point la structure des paquets que nous allons utiliser pour les communications.

Puis j’ai développé les fonctions permettant d’appliquer l’algorithme de Dijkstra à une map donnée afin de trouver le plus court chemin menant au destinataire d’un message.

Ce soir j’ai complété ma partie de la soutenance de demain matin et continué à travailler notamment sur la datasheet de l’IrDA sur laquelle je vais travailler ces prochains jours.

tp + projet (longtemps depuis le dernier post...)

30/03 jusqu’au 01/04 – projet et tp

30/03 matin : lecture du datasheet pour l’écriture de la configuration du CAN + écriture de la configuration du CAN. Problème pour compiler/linker le code écrit en utilisant la bibliothèque ST.

31/03 matin et après midi : j’ai travaillé pour trouver la solution du problème avec la bibliothèque ST. Pas beaucoup avancé ce jour là. J’ai aussi revu le code du tp.

01/04 après midi : lecture du datasheet pour l’écriture de la configuration de l’ADC + écriture de la configuration de l’ADC.

02/04 – communication challenge

06/04 – projet

J’ai travaillé sur le CAN et sur l’ADC. Apparemment l’ADC marche, mais les valeurs n’ont aucun rapport avec la position du potentiomètre. Pour le CAN, si j’active les interruptions, la carte se bloque.

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. Avance entre mercredi et jeudi

Je détaille mes activités pendant les trois dernières jours concernant le TP.

Mercredi 24 mars:

Routine d’interruption, buttons:

L’activation de résistances PULL UP pour les portes d’entré et l’activation de l’horloge de fonctionnalité alterne dans le registre RCC->APB2ENR résoudre le problème. -> BUTTON FINI

Zigbee:

J’ai créé la routine de réception USART de la manière comme le datasheet l’indique. Par contre, au début je n’arrive pas à recevoir rien. Après d’un révision complète du code (et du datasheet aussi) j’ai réussi à recevoir de caractères bizarres. Sam est arrivé à la salle et redémarré son dispositif mais je continue sans recevoir de choses cohérentes. Finalement, je trouve que le UART3 travaille à 36MHz et un petit modification au registre BRR règle le problème.

Il m’a pris un bon moment pour arriver aussi à me communiquer avec mon propre Zigbee et recoit les messages ‘OK’. Alors, à la fin du jeudi, j’arrive a recevoir le message TP STM32 Zigbee, mon prénom et les fréquences de ma chanson. Par contre je n’arrive pas à faire une routine qui identifié le messages composés avec que de caractères pour le buzzer. J’arrête là.

Jeudi 25 mars:

J’ai réorganise le comportement des tâches de mon programme principal (sans varier des grandes choses dans mes routines) et maintenant j’arrive à identifier les messages composés exclusivement de caractères et finalement le buzzer joue la chanson! ->ZigBEE +BUZZER FINI

Vendredi 26:

Je suis dédié maintenant à créer de librairies et nettoyer un peu plus mon code pour le faire réutilisable.

Avancement TP et PuLSE

Concernant le TP : Le lcd, le bouton poussoir et le buzzer fonctionnent : il ne me manque plus « que » le ZigBee.

Coté projet, je me suis lancé à la recherche d’une pile TCP/IP qui pourrait nous convenir (notamment uIP et lwIP recommandées par FreeRTOS) et dans la lecture de la datasheet du contrôleur Ethernet.

TP

Hier j’ai travaille sur TP et j’ai réussi  faire clignoter le led de la carte  et après avoir lu la datasheet du LCD et son contrôleur j’ai pu afficher « Hello world » sur l’écran. J’ai aussi commence à implémenter les sémaphores qui me serviront pour afficher des messages à fréquences différents sur la ligne 1 et la ligne 2 du LCD.

Heliokter, Jour 23 : Fall simulator

Résumé de notre avancée depuis le dernier post

Jour 21 (mardi) : Nous avons passé la journée avec Efix à coder pour interfacer le simulateur et l’asservissement que j’ai écrit en C. L’opération fût un succès, cependant il nous faut encore régler les coefficients des différents asservissement PID que nous faisons pour l’instant : roulis, tangage, lacet. Il reste également à implémenter l’asservissement en altitude et à régler les problèmes de modulo sur les angles. Après avoir bien joué avec le simulateur et regardé notre heliokter s’emballer de toutes les façons possibles nous avons décidé de nous concentrer uniquement sur la carte.  Les schémas sont à rendre vendredi !

Le soir j’ai aussi fini le placement routage de ma carte de TP.

Jour 22 : Petite soutenance improvisée avec un projecteur qui « tombe en panne ». L’exercice fut intéressant sans être trop pénible puisque la présentation était encore fraîche dans notre tête. A l’issue de cette soutenance, comme nous l’ont montré Alexis et Sam, nous avons décidé d’améliorer la communication interne et de bien définir la répartition des tâches afin que chacun soit à la fois responsabilisé et recoive le crédit qui lui est du pour son travail.

Nous nous sommes donc ensuite répartis les rôles pour le dessin de la carte :

Fernando : ZigBee et RS232

Miguel : Gyroscopes et controleurs brushless

Efix : Magnétomètre et accéléromètre

Moi même : Télémètre et LEDs

Le rôle de chacun est de lire à fond la datasheet du composant qui lui est attribué et de faire un schéma de connexion au processeur.