ELECINF344/381

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

Catégories

MB Led: Depuis la soutenance intermédiaire…

Notre dernier article datant de mardi dernier. Je vais faire un résumé de mes avancées des derniers jours:

Mercredi et jeudi:

J’ai terminé de coder les fonctions de communications avec le driver de LED. J’ai désormais un exécutable censé afficher une image décrite pour l’instant en dur (pixels écrit un par un à la main dans un tableau). Je ne peux pas avancer plus de ce côté sans nos blocs, une fois ceux-là soudés,  je pourrais passer au debugage

Voici comment fonctionne cet affichage dans les grandes lignes:

Initialisation:

  1. On initialise la communication SPI: messages de 16 bit, fréquence d’envoi de 18MHz, LSB transmis en premier.
  2. On initialise le DMA.
  3. On initialise l’horloge qui servira de référence pour le PWM du driver.
  4. On configure les différentes luminosités pour les trois groupes de couleur (rouge, vert et  bleu)
  5. On configure la fréquence de l’interruption qui rafraichira l’affichage de l’image. Cette fréquence n’est pas définitive, elle dépendra de la puissance des LED qui influe sur la persistance rétinienne. Plus cette puissance sera grande plus on pourra réduire la fréquence de rafraîchissement. Cette fréquence ne peut donc être réglée qu’empiriquement. Pour l’instant 80KHz en se basant sur le code des GLiP.

Routine d’affichage:

Les 8 lignes sont affichées les unes après les autres. Une seule ligne est allumée à un instant donné.

L’affichage d’une ligne se fait de la façon suivante:

  1. On récupère la ligne dans l’image courante.
  2. On extrait, des pixels de cette ligne, les valeurs des 24 LED.
  3. Ces valeurs sont pour l’instant sur 4 bit, une fonction est chargée « d’étirer » ces valeurs sur 12 bits pour correspondre aux attentes du driver. C’est cette fonction qu’il faudra modifier lorsque nous déciderons d’élargir le champ de couleur disponible (pour l’instant on garde le format GLiP).
  4. On construit finalement, sous forme de 18 messages de 16 bit, le vecteur de 288 bit attendu par le driver pour piloter ses 24 sorties (24*12bit).
  5. Ces 18 messages sont envoyés en SPI par accès direct à la mémoire au driver de LED qui va afficher la ligne courante.

Vendredi et samedi:

Depuis vendredi je réfléchi à une façon de faire des mises à jour de firmware via l’IrDA. En effet si nous avons 36 blocs, dès qu’il s’agira de flasher une nouvelle version de notre code, cela s’avérera être une opération fastidieuse. Petit calcul: 30 secondes (au moins) pour flasher un bloc et 36 blocs. Soit un peu moins de 20 minutes à chaque fois!

Une organisation possible de la mémoire flash, pour la mise en place d’un système de mise à jour que je détaille plus bas, serait la suivante:



Les premières instructions du bloc Flash programmer font « sauter » en _firmware_begin.

Puis, le firmware pourrait être mis à jour de la façon suivante:

  1. Notre firmware courant s’exécute normalement sur un bloc B : affichage d’animations, jeux, etc…
  2. Nous souhaitons faire une mise à jour du firmware depuis la carte microSD d’un bloc A par exemple.
  3. En se reposant sur notre système de transmission de donné par IrDA que je ne détaille pas ici, le bloc A va d’abord envoyer une commande indiquant l’arrivé d’une mise à jour (broadcastée ou non)
  4. Un des blocs, B, recevant cette commande décide de l’accepter ou non.
  5. Si il accepte il va placer les différentes parties du firmware  envoyé par le bloc A (là encore en se reposant sur notre système de transmission IrDA gérant les problèmes de communication, les paquets corrompus, perdus etc.) en flash à partir de l’adresse _new_firmware_begin à la bonne position: _new_firmware_begin + (taille d’un paquet * position du paquet).
  6. Lorsque tous les paquets ont été reçu correctement (on peut redemander une confirmation à ce moment-là), le programme saute à l’adresse  dans le bloc Flash programmer de début de traitement de la copie.
  7. Le nouveau firmware est alors entièrement copié à la place de l’ancien.
  8. Une fois la copie terminée on retourne à l’adresse _firmware_beginn.

La mise à jour est terminée!

Je m’intéresse maintenant à l’implémentation de ce système de mise à jour ainsi qu’au fonctionnement du debugage via le port série prévu pour ça.

Référence :

Pour le flashage « in-application » : AN2557

 

RoseWheel : avancées post-soutenance

Depuis la soutenance de mercredi matin, nous avons essayé d’avancer sur trois aspects de notre projet :
- Simulateur : nous avons commencé à écrire un nouveau module pour tester seulement la modélisation des moteurs, étant donné que nous avons toujours des résultats inacceptables au niveau de la tension requise pour l’équilibre. En parallèle, nous vérifions les équations du modèle physique général, pour essayer de trouver les erreurs « cachées » ;
- Banc de test : après avoir mis une référence plus visible pour lire le rapporteur, nous avons calibré à nouveau le moteur. Désormais, il reste intégrer ce nouveau calibrage au potentiomètre pour pouvoir savoir exactement la position où se trouve le moteur, et ainsi reprendre nos tests avec une meilleure précision. Voici l’état actuel de notre dispositif :
- Cartes : nous avons commencé à réflechir à la l’implémentation des drivers pour les divers périphériques. Nous voudrions utiliser une architecture plus générique que celle que nous utilisions pour le TP STM32. Suite à quelques essais il semble difficile de faire des fonctions génériques de configuration de périphériques sans faire trop compliqué (fonctions longues, bricolage sur les masques et les offsets…) ; peut-être que des macros préprocesseur seraient plus adaptées… nous explorerons d’autres pistes demain. Nous allons tout de même essayer de faire simple et ne pas implémenter plus de généricité que nécéssaire pour nos deux cartes.

[CASPER] Soutenance intermédiaire

Voilà nos slides de la présentation intermédiaire !

CASPER soutenance intermediaire

TSV Safe Express: Soutenances Intermédiaires

Aujourdhui, nous avons eu notre soutenances intermédiaires. Voici le TSV Safe Express presIntermédiaire.

Apres le soutenance, nous avons vérifié que nous pouvons utiliser le Ethernet et le CAN aux même temps dans STM32F107XX. Nous avons vu que il n y a pas le conflit entre les deux dans le zone mémoire. (ST Reference Manual RM0008, page 50 et page 52)

Nous avons finis avec le CAN bus en mode « LoopBack » avec « Interrupts ». Apres cela, nous avons essayé de faire le communication entre deux carte de TP sur le bus CAN. Mais, il y a quelque problèmes avec ça.

MB Led : Soutenance intermédiaire

Bonsoir,

Vous trouverez ici les slides de notre soutenance intermédiaire de ce matin.

IRL : soutenances intermédiaires

Vous trouverez ici les slides que nous avons (ou pas ;-) ) présentées à la soutenance intermédiaire.

RoseWheel : présentation d’avancement de projet

Vous pourrez récupérer notre présentation d’avancement de projet en cliquant ici.

Acroread est apparemment le seul logiciel qui permet de lire les les images animées.