Site ELEC344/ELEC381

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

Catégories

Bootloader GLiP

Ces derniers jours, je me suis attelé à programmer un bootloader pour GLiP. En effet, lorsqu’on devra flasher les 16 blocs, ça serait beaucoup plus pratique de le faire via IrDA plutôt que par JTAG.

Dans un premier temps (vendredi, samedi après-midi, lundi après-midi), je me suis donc basé sur le bootloader du projet serpent de l’année dernière (qui flashait via le bus CAN) et j’ai adapté le système de paquets pour le bootloader. En effet, le checksum est indispensable (on ne va pas flasher n’importe quoi) mais on peut se passer de certains champs (TTL, émetteur, …).

J’ai repris la bibliothèque pour l’écriture dans la Flash de l’année dernière (mardi).

Aujourd’hui (jeudi), j’ai enfin réussi à jumper à une adresse mémoire donnée au bout d’un Timeout (lorsqu’aucune commande bootloader n’a été reçue), ce qui est une fonction assez intéressante pour un bootloader !

Programme de demain : débugger la communication IrDA qui ne semble pas fonctionner (le bootloader jump même si une commande a été envoyée !…).

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.

PuLSE, travail effectué aujourd’hui

J’ai passé la soirée à essayer de faire un placement correct. Il ne reprend pas beaucoup le placement de l’an dernier, même si j’ai repris quelques idées notemment sur le coup de la carte SD et du JTAG :) . On arrive aux mêmes dimensions à peu près. Le placement est disponible ici : placement_PuLSE

Pour terminer la soirée, un peu de paint :)

demain, routage puis TP.

Heliokter : Carte Mère et gyros

On a déjà commencé à faire les schèmes de la carte mère et du gyroscope. J’ai fait les connexions basiques pour la carte mère : JTAG, oscillateur, boot,  reset, alimentation et connexions pour les communication de façon générale.

Par rapport au carte du gyroscope, dès lorsque la position des deux gyroscopes doivent être en plans perpendiculaires donc on a besoin de deux cartes indépendants physiquement de la carte mère, mais le design de la carte est la même pour les deux gyroscopes. La carte du gyro aura 6 pins qui serviront pour se communiquer avec la carte mère :

  • AVCC : Voltage de alimentation de gyro (3V)
  • AGND : Terra analogique
  • PTAT : Pour lire la température
  • VREF : Voltage de référence qui est le voltage quand il n’y a pas de rotation (3.5V)
  • 2 pins pour les sorties analogies des axes de rotation

AVCC sera généré dans la carte mère, pour faire ça on utilisera le MIC5222-3 de MICREL qui est un régulateur de 3V pour applications de bas bruit. Le MIC5255-3  se trouve chez Digi-key à 0.365 euro .

PuLSE, entrée DMX / pilotage de la carte K12N

Avancée actuelle sur le projet PuLSE :
on commence à réaliser les schémas électriques de la carte mère. Le travail a été réparti en 4 tâches :

  • Brochage du processeur STM32F103RET6 : Thibaut
  • Schéma du contrôleur ethernet : Etienne
  • Schéma du contrôleur SD : Romain
  • Schéma de l’entrée DMX et sortie vers la carte K12N : xavier

Donc bilan sur ma partie :
l’entrée DMX est cablée. On aura un connecteur XLR male et un femelle qui seront connectés via un micromatch vers le processeur. On a utilisé un contrôleur d’entrée différentielle (SN75176A) pour faire l’interface avec une UART. Actuellement la carte fait relai pour le flux DMX (elle ne peut que le lire, et les deux connecteurs DMX sont directement reliés)

La sortie vers la carte K12N va nécessiter 2 amplificateurs. Il faut qu’ils aient une bande passante de plus de 20KHz et un gain minimal de 10 (en gros il faut pouvoir passer d’un signal entre 0 et 3.3V à un signal entre 0 et 10V). L’an dernier ils ont utilisé un PGA203KP vendu par Texas Instruments, qui a l’air assez cher (environ 16€), alors que d’autres amplis ont l’air de faire l’affaire et sont moins chers. Actuellement je n’ai pas eu le temps d’aller chercher plus loin. Ca sera pour demain.

Sinon TP STM32, rattrapper du retard. Au total ca a pris la matinée plus 3-4 h réparties entre l’après midi et la soirée.

Le but est en fin de semaine d’avoir routé notre carte mère. Une fois les 4 tâches finies on pourra commencer s’occuper de l’alimentation et des composants moins importants, qui se cableront plus vite (port USB, JTAG, etc…). L’idéal serait d’avoir fini ca d’ici mercredi soir, pour faire le placement jeudi et vendredi.

Wheely : Carte logique

On a fait un brainstorming bilan des peripheriques avec l’équipe.

J’ai récapitulé la liste ci-dessous :

  • Le gyroscope : IDG500
  • L’acceleromètre : LIS3LV02DL
  • Le STM32
  • 4 leds (+ ou – suivant dispo de pattes)
  • JTAG
  • 1 port série
  • 6 connections pour la carte de propulsion (dont 2 PWM)
  • Le bluetooth : F2M03GLA
  • Des boutons (nombre à voir suivant pattes dispos)
  • Un bus SPI (pour l’accéléromètre)
  • Un ADC du STM pour le gyro
  • Un buzzer (si place dispo)
  • Un zigbee : XB24-ACI-001

Une erreur ou un oubli à signaler ?

Ou bien un truc à ajouter qui nous simplifierais la vie ?

Merci,
Arnaud.