Site ELEC344/ELEC381

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

Catégories

Carte logique et diagramme de GANTT

Depuis mardi soir, j’ai récupéré la carte logique, et je me suis donc attelée à adapter notre code pour elle. Après 4 heures de recherches pour découvrir que les interrupteurs de boot étaient juste un peu capricieux, j’ai pu commencer à mettre du code dessus. Résultat, hier soir j’avais déjà les leds et le buzzer qui fonctionnaient à merveille. En même temps, j’essaie de rendre le code le plus propre possible et de permettre qu’il soit facilement portable sur les cartes IMU, puisqu’on risque de travailler encore longtemps sur les deux cartes en parallèle.

Hier soir, avec Daniel, nous avons fait le diagramme de GANTT pour notre groupe. Nous avons décidé de ne pas mettre de dead-line pendant les vacances et le dimanche. Voila à quoi nous sommes arrivés :

Communication challenge 2010

Le but de ce challenge est de vous faire utiliser un protocole de communication conçu pour l’occasion, tout en vérifiant que vous savez utiliser les différents périphériques de votre carte de TP. Ce challenge est conçu en étapes successives : la carte annonce au serveur l’étape qu’elle souhaite vérifier. Les étapes doivent se faire dans l’ordre croissant et aucune ne peut être omise sous peine de causer la disqualification du participant.

Description du protocole

  • Le protocole est basé sur des chaînes de texte terminées au choix de l’envoyeur par l’un ou les deux de « \r » et « \n ».
  • Les différentes composantes de chaque échange sont formés à partir de chaînes de caractères (sans délimiteur) et d’entiers positifs ou nuls.
  • Toutes les entités sont séparées par des espaces.
  • Aucun espace n’est autorisé en début ou en fin de commande, et un double-espace est interdit.
  • À l’exception de la commande « STEP » qui est envoyée spontanément par le client (votre carte), toutes les opérations sont initiées par le serveur et sont suivies d’une réponse du client.
  • Toute commande non comprise par le client ou mal formée doit être ignorée et ne doit provoquer l’envoi d’aucune réponse.
  • Aussi bien le serveur que le client peuvent, à tout moment, envoyer une ligne vide qui sera ignorée.
  • Un message ne comprendra jamais plus de 256 caractères.

Étape 1 : configuration Zigbee

  • Configurer la carte Zigbee pour que son identité soit vos initiales (comme lors du TP), sauf pour François-Xavier qui choisira « FX ».
  • Les réponses seront envoyées à l’identité « CC » : il faut donc configurer dans DH et DL l’adresse idoine.
  • Bien que cela ne soit aucunement obligatoire, il est conseillé d’utiliser le mode API 1 du module Zigbee : ce mode permet de savoir si un paquet a bien été reçu par le destinataire ou s’il est nécessaire de le retransmettre.
  • Envoyer le message « STEP 1″ au serveur.

Cette configuration Zigbee devra être maintenue pour les étapes suivantes. De plus, chaque commande implémentée devra le rester, car elle sera utilisée dans la suite du challenge. Chaque étape peut constituer en plusieurs cycles commande/réponse.

Étape 2 : gestion d’une commande simple

  • Envoyer le message « STEP 2″ au serveur.
  • Accepter la commande « PING ».
  • Répondre en renvoyant « PONG ».

Étape 3 : gestion d’une commande avec arguments

  • Envoyer le message « STEP 3″ au serveur
  • Accepter la commande « ADD t n1 n2 n3 … nt » où « t » (un entier positif) est le nombre d’entiers positifs ou nuls qui suivront.
  • Répondre en renvoyant « ADD-R m » où « m » est l’addition des entiers « n1″ à « nt ».

Étape 4 : afficheur LCD

  • Envoyer le message « STEP 4″ au serveur.
  • Accepter la commande « LCD n [chaîne] » où « n » vaut 1 ou 2 et « chaîne » est une chaîne de caractères délimitée par les caractères « [" et "] » et pouvant contenir des espaces.
  • Répondre en renvoyant « LCD-R m » où « m » est le nombre de caractères de la chaîne contenue entre « [" et "]« 
  • Afficher la chaîne de caractères sur l’afficheur LCD en la faisant défiler si et seulement si la chaîne fait plus de 16 caractères. Attention, le défilement doit se faire en tâche de fond et continuer tant qu’autre chose n’a pas été spécifié.
  • L’affichage sur les deux lignes doit être indépendant.
  • Si une chaîne fait moins de 16 caractères, les caractères non affichés sur la ligne concernée doivent être effacés (remplacés par des espaces).

Étape 5 : boutons poussoirs

  • Envoyer le message « STEP 5″ au serveur.
  • Accepter la commande « SWITCH » et attendre, une fois que les deux boutons sont relâchés, qu’un bouton soit appuyé par l’utilisateur.
  • Répondre en renvoyant « SWITCH-R s » où « s » vaut soit « LEFT » si le bouton de gauche a été pressé, soit « RIGHT » si le bouton de droite a été pressé.
  • Pour valider cette étape, faire les tests proposés.

Étape 6 : leds

  • Envoyer le message « STEP 6″ au serveur.
  • Accepter la commande « LEDS r g b » où « r », « g » et « b » sont des valeurs entre 0 et 255 correspondant au rapport cyclique à positionner respectivement sur les leds rouge, verte et bleue. 0 correspond à un rapport cyclique de 0% (led éteinte), 255 correspond à un rapport cyclique de 100% (led allumée), et les valeurs intermédiaires sont à traiter linéairement.
  • Répondre en renvoyant « LEDS-R n » où « n » est la somme de « r », « g » et « b ».
  • Pour valider cette étape, faire les tests proposés.

Étape 7 : buzzer

  • Envoyer le message « STEP 7″ au serveur.
  • Accepter la commande « BUZZER n f1 d1 f2 d2 … fn dn » où « n » est le nombre de notes envoyées, et « fi » et « di » la fréquence et durée en millisecondes de la note « i ». Une fréquence de 0 signifie l’arrêt du buzzer pendant le temps indiqué. La dernière durée peut être nulle.
  • Répondre en renvoyant « BUZZER-R n » lorsque la mélodie a été jouée.
  • Pour valider cette étape, faire les tests proposés.

Étape 8 : consommation

  • Envoyer le message « STEP 8″ au serveur.
  • Accepter la commande « CURRENT ».
  • Répondre en renvoyant « CURRENT-R n » où « n » est la consommation moyenne de courant sur les trois dernières secondes en micro-ampères.

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

29/03

Matin: J’ai fini mon TP, je reçoit la musique. J’ai aussi essayé de laisser le code plus propre.

Après-midi: J’ai travaillé dans la rédaction de l’article.

TP prêt

Aujourd’hui j’ai fait marcher la transmission du zigbee. Là, ma carte reçoit les fréquences et le buzzer sonne (aparamment) bien les chanson reçus. J’ai profité aussi pour faire un cleanup de mon code et pour créer des fonctions d’une API qui pourront être utiles pour l’avenir.

J’ai également fini la rédaction de ma partie de l’article.

TP : Zigbee et Buzzer

Lundi 29 j’ai fini avec la communication  zigbee. La réception et la transmission marchent bien.  J’ai aussi crée une fonction pour faire travailler le buzzer à n’importe quelle fréquence et ça marche bien. Pour finir le TP, il me manque seulement filtrer les fréquences de réception et passer ces fréquences au buzzer pour jouer de  la musique.

TP et Gyromètre

TP: Le buzzer semble marcher. Le code du zigbee a été déjà fait en utilisant des queues de FreeRTOS et interruptions. Après, il faudra le tester.

Gyromètre: j’ai lu 3 articles:

  • Un capteur, du début du gyromètre MEMS, qui utilise piézorésistance, force de Coriolis et Lorentz (ici).
  • Pour mieux comprendre le principe physique des erreurs du gyromètre (ici).
  • Avec filtre de Kalman (ici)(malheureusement je n’ai pas bien compris, j’ai doit étudier le Kalman tout seul avant).

Zigbee fonctionnel et routage de carte

Bilan de la journée :

Pour ce qui est du TP j’ai réussi à faire fonctionner le zigbee avec l’écriture et le lien avec le buzzer.

Côté projet, j’aiplacé et routé la carte LED qui a priori est enfin correcte :) vive le placement routage sur 6cm par 6cm !

LCD, Led, Zigbee, IRQ, Buzzer : All good !

Bon, aujourd’hui est un jour plutôt cool puisque je suis arrivé au bout du TP, en ayant bien fignolé et modularisé les differentes parties, pour qu’il soit réutilisable facilement. Voici un petit bilan :

  • Les écritures sur le LCD se font simplement soit sur la ligne 1 soit sur la ligne 2, et sont thread safety. Si le message est plus long que 16 caractères, il défile sur l’écran, sans perturber l’affichage sur l’autre ligne. Le rétroéclairage est contrôlé par un timer en PWM et oscille entre differentes intensités.
  • Pour le buzzer, une fonction permet de jouer une note à une fréquence donnée.
  • Pour le Zigbee, l’initialisation se fait de façon à envoyer son prénom, recevoir des messages broadcastés, et jouer en streaming une musique diffusée sur les ondes. Le fichier zigbee.c présente deux fonctions génériques, une de lecture, et une d’écriture
  • Pour les interruptions, un bouton permet de figer l’intensité du rétroéclairage du LCD, l’autre de rendre muet le buzzer. Le fichier bouton.c met à disposition deux sémaphores réutilisables ailleurs pour exploiter les IRQ sur les boutons.

Maintenant, je vais essayer de jouer avec la carte inertielle pour apprendre à manipuler l’accéléromètre via bus SPI.

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.