• Routines TI de com avec la carte DSK StarterKit
• Routines TI de conversion de floats format DSP vers format IEEE(PC)

Aperçu global

L'usine a gaz a été continuée après la coupe (le prog PC lm629_dsp.exe ET le prog sur le dsp asser_dsp). Ces nouvelles versions sont dans Asservissement-balisees\asser_dsp_new

Il y'a en plus

• les trajectoires courbes
• la com PC<->DSP(debug) en utilisant le port parallèle en mode bidirectionnel et en utilisant un très long cable
• la possibilité d'envoyer des ordre par le debug
• un utilitaire pour déplacer le robot à partir du clavier (powered by flemme power)

Lorsque l'on démarre le fichier Asservissement-balisees\asser_dsp_new\Asser_DSP\lcc\lm629_dsp.exe, on doit voir apparaitre quelquechose qui ressemble à ça. Le programme peut aussi planter ... ce qui est le mauvais cas. La cause du plantage est TRES difficile à déterminer sans examiner les sources.

Aperçu global de l'usine à gaz

A partir de ce point, il ne faut plus chercher à trouver des explications rationelles au pourquoi du comment. Il s'agit d'un amoncelage de fenêtre et de code qui a été utilisé pour différents essais, recherches,etc.

Cette barre contrôle l'apparition des différentes fenêtres :

A partir d'ici plusieurs commande sont disponibles :

• Reload, va effectuer le chargement du code dans le DSP. En fonction de l'état précédent (debug, pas debug, etc), il est censé changer d'état. Ce Reload va suivre la procédure décrite ici. Il va donc commencer par charger le Kernel, qui est situé dans le fichier C3X.DSK. Ce fichier doit donc être présent dans le même répertoire que lm629_dsp.exe. Il va ensuite charger le code situé dans le fichier ..\\..\\asser_dsp\\lcc\\asser_dsp.out
  Ce chemin est codé 'en dur' dans l'application. (NDLR : rappel à partir de ce point, il ne faut plus chercher pour qui pourquoi,etc). Il faut donc que le fichier à charger soit situé à cet endroit par rapport à lm629_dsp.exe.
  Soit le chargement va bien se passer, auquel cas, le titre de la fenetre se change de "DSP Util" en "Bootloading ..." puis revient à son titrre initial (pas de message)
  Soit le chargement va mal se passer et on va avoir une erreur qui peut être entre autre :
  • Erreur Initialisation du DSP
    Vérifier les cables, la présence du loader C3x.dsk dans le rep de l'appli
    Verifier que le DSP n'est pas en mode autonome (le jumper doit être ENLEVE sur la carte d'extension)
    Ce message indique que le kernel n'a pas réussi à se bootloader. Ce qui en soi indique un problème assez 'bas niveau'. La communication de base ne requiert pas beaucoup d'informations.On pourra donc vérifier que :
    • Les cables sont bien branchés (et en état de marche).
    • Le jumper est bien enlevé, ce qui permet de booter en mode non autonome.
    • Le fichier C3x.dsk est bien dans le même rep que lm629_dsp.exe.
    • La carte est bien alimentée.
    • Le sandwich est correctement mis,etc
  • Erreur chargement du programme d'application
    Vérifier sa présence dans le rep de l'appli
    L'erreur s'est produite au moment du chargement du programme d'application. CONTRAIREMENT à ce qui est dit, le prog n'est pas dans le rep de l'utilisateur, mais dans ..\\..\\asser_dsp\\lcc\\asser_dsp.out
    Lorsque cette erreur se produit de façon répétée, il peut y avoir comme problème :
    • Un problème sur la liaison, mais qui ne devrait pas se reproduire trop de fois.
    • Le DSP planté ou le Kernel planté, ou dans un état aléatoire, qui fait que le chargement plante. Dans ce cas, il faut faire un reset manuel de la carte (ce qui ne change normallement rien).
    • Essayer d'éteindre et de rallumer la carte. I
    • Essayer de redémarrer lm629_dsp.exe car cette erreur peut aussi venir du fait qu'il n'a pas réussi à ouvrir le fichier, car il a été mal refermé ou il y'a eu un problème dessus.
    • Le programme téléchargé contient un problème (pas un bug dans le code, mais une taille trop grande, qui fait qu'il ne loge pas dans la mémoire, ou un mapping mémoire incorrect qui fait qu'il déborde de la mémoire,etc)
  • Impossible de communiquer avec le DSP ou Communication erronée. Ces 2 actions sont effectuées après avoir bootloadé le programme, pour vérifier que la communication avec le Kernel est toujours possible (le programme n'est pas encore lancé, il est juste chargé). Une erreur de ce type peut indiquer :
    • Un problème dans le programme téléchargé (mapping mémoire, écrasement du Kernel, taille trop grande, etc)
    • Un problème de com' (cable, parasite, etc)
  • "Erreur SSTEP","Impossible de lancer le programme". Il y'a eu une erreur lors de l'exécution du Single Step NECESSAIRE (mais on ne sait pas exactement pourquoi -- sans doute une des spécificités du DSK, qui est troublé par le fait qu'on utilise pas son compilo) avant l'exécution du programme. Cette erreur peut survenir pour diverses raisons. Elle peut venir d'un problème dans le programme utilisateur.
  • Getmem après lancement du prog
    Erreur de communication ? Programme planté ?
    Cette erreur de loin la plus fréquente indique qu'il n'y a plus de communication possible avec le Kernel. Dans ce cas, le programme a planté la carte. Ce peut être dû à une erreur dans le programme ou sur le hard de la carte, ou etc, ....

  Il est à noter que l'assemblage du sandwich est assez suceptible et il peut être nécessaire de désasembler et réassembler l'ensemble des cartes.

  Attention ! Une fois le 'reload' effectué correctement, celà veut dire que :

  • Le Kernel est correctement chargé.
  • Le programme s'est chargé sans venir écraser le Kernel
  • Le programme a été lancé
  • Le Kernel était toujours fonctionnel après.
  • Mais ça ne VEUT PAS DIRE que le programme tourne, il peut très bien s'être planté sans endommager, ni géner le Kernel qui fonctionne sur IT.

• Mem/Flash ouvre une fenêtre contenant des outils pour les tests de la mémoire et le flashage.(détaillé après)
• Dbg // démarre le debug parallèle, c'est à dire que le soft va aller régulièrement demander au DSP un certain nombre de variables et va afficher les résultats dans la boite Position Management Unit Interface, et sur le terrain notamment (il peut y avoir quelques autres trucs aussi en fonction du mode)
• Dbg I2C démarre le debug I2c, qui va aller lire via interface sur le port // les données de la carte (via l'i2C). Même chose en fait en plus lent, plus aléatoire,etc,etc
• getmem, qui va permettre de lire de façon bien plus indistrielle (gros paquets) dans la RAM de la carte. A servi notemment pour le debug de l'I2C, le debug du recalage de ligne, le debug de l'asservissement, le debug des trajectoires courbes.
• Chef, qui ouvre une autre fenêtre permettant de contrôler la carte principale, via le port série du PC (qui une fois relié à la carte principale) permet de contrôler celle-ci.
• Goto Home qui ouvre une fenetre, qui permet de contrôler le robot au clavier. Cette fenêtre ne contient rien, mais lorsqu'elle est sélectionnée, il est possible de faire avancer, reculer, tourner le robot avec le flèches de direction. La touche espace stoppe le robot et réinitialise la position à son aire de départ.'A' permet de stopper sans réinitialiser la position.

Détail des fenêtres

Plusieurs fenêtres vont être détaillées :

• La fenêtre principale "Position Management Unit Interface"
• Le séquenceur qui apparait en haut à droite
• Le terrain
• La fenêtre "Mem/Flash" (accessible depuis la barre du haut)
• La fenêtre "getmem" (accessible depuis la barre du haut)
• La fenêtre "Chef" (accessible depuis la barre du haut)

Fenêtre principale "Position Management Unit Interface"

Fenêtre principale - Debug principal

Cette fenêtre a été la première de ce programme. Elle a été remaniée dans tous les sens. Elle indique dans l'état actuel, un certain nombre d'infos issues du code de positionnement-asservissement.
Cette fenêtre est remplie :

• Lorsque la communication "debug //" (cf au dessus) est activée. Dans ce cas, les infos sont retournées directement par la communication PC<->DSP. Les variables correspondantes sont lues en mémoire et affichées.
• Lorsque la communication "debug I2C" est activée. Dans ce cas, les infos sont demandées sur le bus I2C (via interface I2C // à base de PIC sur le port //)

Dans les 2 cas, la communication a lieu sur le port // mais est TOTALEMENT différente. En fonction du debug choisi, les infos affichées diffèrent. Certaines cases ne sont pas remplies, d'autres sont remplies mais avec des données différentes,etc.

Le debug // est le plus complet, il remplit les boites :

• Current X,Current Y, Current THETA qui correspond à la position actuelle du robot (unité ? mm ? mm/10 ?)
• Mean LM629s, Diff LM629, données de debug pour le positionnement.
  ATTENTION ! Dans le cas d'une communication I2C, la case DiffLM629s n'est pas affichée mais LUE. Sa valeur correspond à la durée (en nombre de tour de boucle for) du délai d'attente entre l'envoi de plusieurs infos au PIC qui fait la conversion // <-> I2C.
• DesX, DesY, Goto Theta, étaient censés afficher la position à atteindre (dans le cas d'un ordre de déplacement GOTOXY). Maintenant ils doivent afficher quelquechose, il faudrait vérifier quoi.
• DSP RXTX, les 2 cases en dessous de ces labels, sont des variables de debug utilisées sur le DSP. La première correspond à pas grand chose (elle est positionnée à certaines valeurs à certains endroit du code -- c'est tout dire). La 2ème est incrémentée à chaque interruption Timer du DSP. Cet affichage permet de déterminer TRES RAPIDEMENT si le DSP tourne ou pas. Le timer étant cadencé à 1KHz, cette valeur augmente de 1000 par s.
• Les boutons situés dans le groupe "Commandes" euhhh .... résidus des anciennes interfaces. Là que font-ils réellement là ????
• Position LM Gauche, Position LM Droite. Affiché, pas affiché ??? correct ?
• Status DSP. Ce groupe contient plusieurs variables. Status contient le status(état) de la carte, c'est à dire celui qui est retourné par l'I2C lorsque l'on demande à la carte son état. La liste des status est au moins indiquée dans "robot.h". Adv euh ?? . Gen1 et Gen2, ce sont 2 valeurs (variables du dsp), qui ont été utilisées quand on voulait visualiser une variable pour savoir ce qu'elle devenait, dans un bout de code. Ce qu'il y'a dedans n'est pas défini, mais celà permet de debugguer assez rapidement un truc simple.
• Error Com doit être censé donner le nombre d'erreurs de communication mais là ???
• La boite au dessus a un rôle assez indéfini aussi.
• Position Balise indique la position de la balise (x, y, theta)

En résumé :

Cette boîte est une des plus torturée. Son code a été changé x fois. Les seules infos restant sûres sont :
La position (x,y,theta) du robot, la position de la balise (x,y), theta ne servant pas est utilisée en variable de debug. Le status du DSP et la 2ème case RXTX (incrémentation du Timer == DSP pas planté, programme en train de tourner).

Terrain

Cette fenêtre est une fenêtre graphique. Elle reste une des plus présentable de la chose. Elle a été créée pour essayer de voir ce qui se passe. Elle peut paraître accessoire, mais il est toujours plus aisé de se représenter les choses graphiquement. Elle aussi a subi une considérable évolution.
Il est à noter que cette fenêtre a aussi été + ou - utilisée pour les différentes présentations, étant celle qui a le plus de facilité à attirer l'oeuil du passant ....

Représentation graphique du terrain

Fait extraordinaire, cette fenêtre est redimensionnable. En fait celà n'est pas très compliqué étant donné qu'on dessine tout dedans et ceci permet d'en faire ce qu'on veut.
Elle se redessine à chaque fois que win lui demande, mais ne redessine que le terrain, les 2 robots. Tous les autres éléments (trajectoires parcourue, recalage de ligne, etc ne sont pas réaffichés)

• Cette fenêtre présente donc la position de notre robot et la position de l'adversaire, les 5 balises de chaque côté et les paniers. Les positions sont mises à jour, en général en même temps que les positions sont affichées dans la boite principale de debug.
• Les trajectoires de notre robot, sont matérialisées par des points rouges.
• En cliquant sur la fenêtre, on envoie un ordre au robot lui indiquant d'aller à cette position. Cet ordre était envoyé via l'I2C. Il a été par la suite envoyé via le com PC<->DSP. Ce truc avait été fait à l'origine pendant les journées portes ouvertes, juste histoire d'amuser la galerie .... Il avait été rajouté aussi un bricolage pour qu'il n'y ait pas d'ordre d'envoyé lorsque l'on active la fenêtre (ce qui se révélait TRES dangereux)
• Cette fenêtre sert aussi à l'affichage des données du recalage de ligne.(qui est activé via une autre boite) Dans ce mode les touches haut et bas (ou droite et gauche ?) servent à passer à l'info suivante de recalage de ligne.
• Elle a aussi servi à l'affichage de la position des boules (pour afficher graphiquement les boules repérées par la camera). Cette fonction est activée en appuyant sur 'u' ou 'U' (les 2 marchent). A ce moment, les positions des boules et la position actuelle du robot est affichée à partir des infos trouvées dans terrain.txt. Dans ce cas aussi, cette boite ne servait qu'à faire un 'debug' graphique.
• Elle a enfin servi pour imprimer des feuilles ayant servies aux stratégies de match.

Sous l'apparence de gadjet, cette fenêtre s'est révéle bien utile, et ce genre d'élément de debug permet de 'voir' un certain nombre de choses. Là encore le code a été remanié très souvant pour coller aux 'besoins du moment'.

Séquenceur

Cette fenêtre est une de celle qui a reçue le plus d'insultes ...

Séquenceur

Le but était simplement à l'origine d'envoyer un certain nombre d'ordres de trajectoires au robot, les uns à la suite des autres (en séquence quoi). A la fois pour vérifier que les ordres font à peu près ce qu'on attend d'eux, mais aussi pour voir les problèmes d'asservissement, de positionnement, les décalages. Bref cette boite est aussi un des utilitaires assez utile(sic). Elle n'a pas subit de grosses modifications mais énormément d'ajouts.

L'idée de base est d'avoir une liste d'ordres à effectuer (Ordres). Ces ordres contiennent 5 éléments : x (position x),y (position y),Spé (code Spécial),V (Vitesse), A(Accélération).La siginification de ces éléments dépend de l'ordre effectué ...
On peut :

• rentrer ces éléments pour un ordre dans la case destination.
• En faisant ajouter, on peut ajouter un ordre (dans la liste ordre).
• Avec les "flèches" haut et bas, on peut le déplacer dans la liste.
• On peut éditer un ordre dans la liste en cliquant dessus (ses valeurs sont affichées dans les cases de 'Destination' et peuvent être modifiées (et ensuite mises à jour par 'modifier')
• Supprimer, supprime le ou les ordres sélectionnés
• Enregistrer et charger en haut permettent d'enregistrer et de charger une liste d'ordre (dans un fichier au format sm6 ... propre à l'appli bien sûr)
• La liste déroulante en bas et le bouton charger permettent de charger 'rapidement' un fichier.
• Les case P,I,D permettent de spécifier les paramètres du filtre d'asservissement.
• Start démarre la trajectoire
• Stop l'arrête. (n'importe quand normallement) surtout dans les cas d'urgence quoi ...

Les ordres étaient envoyés via l'I2C à l'origine, il le sont maintenant via la com PC<->DSP

Le 'type' d'ordre à envoyer est choisi par le contenu de la boite Spé (les valeurs possibles sont sommairement décrites à côté). On a donc comme code dans 'Spé' :

• 0, qui execute un GOTOXY (va à une position en ligne droite).
  x, y : position de destination
  v : vitesse
  a : accélération
• 1, effectue une rotation, d'un certain nombre d'unités (permet de calibrer la constante utile à la rotation dans le positionnement notamment). L'angle est indiqué dans x (unité ? degrés ?)
• 2, effectue une translation directement (va tout droit quoi) d'une distance spécifiée en x(en mm ?). Permet de calibrer la constante utile aux translations dans le positionnement notamment.
• 3, effectue une marche arrière. La distance est indiqué en mm dans x. Par l'I2C cette distance était limitée à 25.5 cm.Cet ordre, servait à se dégager d'un panier ou éviter le robot adverse.
• 4, va vers un panier (le choix du panier doit être indiqué dans x ? Il s'agit d'un chiffre qui indique la direction Nord-Ouest, Nord-Est ,etc .. mais par rapport à quelle référence ??? . Cette ordre positionne le robot dans la direction du panier et avance jusqu'à rencontrer un panier -- capteur mécaniques.
• 5, test ??? euhh ?
• 6, Trajectoire courbe, le reste des infos doivent être dispo dans le source. Les trajectoires courbes nécessitent aussi de réaliser un enchainement des ordres. Il ne devait cependant rien y avoir de spécial dans ce code là, mais plutôt dans celui du DSP.

Pourquoi cette boite s'est fait insulter ? Tout simplement parce que la partie du principale du séquenceur (ajouter-enlever-modifier) des ordres a été faite ... assez vite ... et elle est totalement anti-ergonomique. Et on se fait souvant avoir ce p*** de b*** de truc de m*** qui bouffe la moitié des ordres, ne le modifie pas ou modifie le mauvais ou le rajoute à côté ... (ok, je prend ma pilule, vais allumer la lumière et me calme ... b*** de m***).

Cette boite garde quand même toute son utilité de debug. On pourrait faire le rapprochement côté debug entre cette boite qui permet de rentrer des ordres et la boite principale qui permet de voir l'état du système.

Mem/Flash

Boite Mem/Flash

Cette boîte a été réalisée au moment de la mise en marche de la carte d'extension. Pour faire marcher cette carte d'extension, il y'a eu besoin de tester la RAM. Il est à noter ici une subtilitée. Pour tester la RAM externe,il est impératif que le code tourne en RAM interne (sinon on ne sait pas si il marche, et on risque de l'écraser). Cette remarque est triviale au moment du premier test de la carte, beaucoup moins après.

L'ensemble de la communication avec la carte est faite via la com PC<->DSP. La communication permettant d'aller lire/écrire à n'importe quelle adresse sur le bus du DSP, elle convient pour tester assez facilement la RAM (sans avoir besoin de pondre un code spécifique sur le DSP, juste en chargeant le kernel)

Les adresses utilisées sont celles présentées dans le mapping mémoire de la carte. Elle sont codées en dur dans le programme.

Les fonctions disponibles pour la RAM sont :

• Txt Dump qui permet d'effectuer un dump des x premiers octets de la RAM et de l'enregistrer dans un fichier texte(affiché sous forme Hexa). Il est ainsi possible de remplir la mémoire avec quelquechose de connu (1 ,2 ,3 ,4 ,5 ,etc par ex, ou un fichier texte, ou une chaine). En relisant on voit si il y'a un problème (données non identiques). En regardant de plus près le problème, on peut savoir quelle est la ligne d'adresses ou de données qui a un problème, ou quel est le paté de RAM,etc,etc.
• Raw Dump permet de récupérer le contenu entier de la RAM et de l'écrire directement dans un fichier. Pratique pour la même chose qu'au dessus. (vérifier que toute la RAM marche)
• Test permet de tester la RAM. Cette fonction est la dernière des 3. Elle commence par essayer de trouver la taille de la RAM (en écrivant et relisant à des adresses par multiples de 2). Elle teste ensuite l'intégralité de la RAM en écrivant des valeurs dedans (des valeurs qui s'incrémentent) et en relisant ensuite le contenu. Dès qu'une différence est détectée, l'@ de la différence est affiché (l'affichage n'est pas spéciallement explicite). Il doit y avoir un compteur qui doit s'incrémenter (juste au dessus de la zone de texte)

Pour la Flash, la même méthode est utilisée (communication PC<->DSP). La flash nécessite pour être pilotée en écriture, d'accéder à une adresse spéciale (cf doc électronique). Il faut ensuite suivre le protocole propre à la flash. A ce sujet, attention à la référence EXACTE de la flash, le protocole différe très légèrement entre une AM29F010 et une AM29F010A. Mais celà permet tout de même d'y perdre un certain nombre d'heures !!.

Les commandes dispo sont :

• Identification-Test, qui permet de voir si on arrive bien à causer avec la flash (y'a en plus un moyen de l'identifer et de savoir si elle est protégée). Ces infos sont retournées dans un message.
• Effacement Complet. envoie une commande d'effacement complet à la flash, attend ensuite qu'elle ait fini d'effacer.
• Raw Flashage permet de flasher directement le contenu d'un fichier dedans (et la boite en dessous doit servir à indiquer le nom du fichier ?). Là encore permet de tester la chose.
• Txt Dump et Raw Dump, même utilité qu'au dessus, cette fois ci pour la flash.
• Flashage Appli. Ce bouton est le plus important de la boite. Il permet de flasher le code dans la flash (sic). Il est ensuite possible de démarrer la carte en mode autonome (en mettant le jumper). Le code qui est flashé doit suivre le format utilisé pour le bootload (exactement comme quand il bootloade son kernel au début). Il doit exister un utilitaire de chez TI permettant de convertir le code "qu 'on peut charger" donc 'brut' en code "à 'bootloader' au démarrage". Cependant il n'a pas été trouvé. La solution envisagée a été d'utiliser les routines de bootload, détournées de leur utilisation pour créer le fichier à flasher. Cette méthode marche d'ailleurs assez bien.
• La boite de texte en dessous, avec ses 2 flèches permet de se balader dans le contenu de la flash. L'interêt de la chose n'apparait pas spécialement flagrant. Il a servi lors du debug de la flash, pour visualiser son contenu (et savoir si le flashage s'était bien passé, sans avoir à faire de dump, àouvrir un fichier texte,etc powerd by flemme power)

Le flashage de l'appli pourrait être avec avantage sorti de l'application, ou du moins son "code éparpillé", isolé dans un seul utilitaire.

Getmem

Get Mem

Cette boite est une des principales boite de debug de l'application en fonctionnement. Notamment des 'gros' systèmes, c'est à dire les données de l'asservissement, du recalage de ligne, des trajectoires courbes, de l'I2C.

Cette boite utilise la communication PC<->DSP pour aller lire des morceaux de mémoire du DSP. La partie gauche de la boite contient :

• Adresse : adresse de la variable/plage de mémoire/structure à récupérer. Cette adresse n'est pas indiquée directement(elle l'était au debut) mais récupérée du fichier '.map' généré par le linker.
• L'adresse est donc déterminée à partir du nom de variable/struture,etc mis dans la boite 'nom'. Cette boite lit le '.map' (son chemin est harcodé dedans, il doit se trouver dans ..\\..\\asser_dsp\\lcc\\asser.map, ce chemin est relatif par rapport au fichier exécutable lm629_dsp.exe) et recherche dedans le symbole qui a ce nom et lit son adresse.
• La case à droite d'adresse indique le nombre de Mots (de 32 bits) à lire.(on peut mettre autant qu'on veut pas de pb)
• 'Get' rapatrie ces données et les affiche dans la boite du dessous, elles doivent être affichées en hexa ??
• Part défaut il est affiché comme nom de variable 'message I2C'. Ce tableau dans le code du DSP contient la liste des commandes arrivées sur le bus I2C, ce qui peut être très utile pour démontrer par A+B, que le problème ne vient pas de cette carte mais d'une autre (c'est pas moi, c'est le chef qui s'est craqué !)(ou pour finir de s'enfoncer dans son trou, moyennant un bon marteau piqueur ...)
• Il est possible de visualiser n'importe quelle variable ayant une adresse dans le .map.(donc toutes les variables statiques, ou du moins définies en dehors de toute fonction == variables globales). Les variables locales sont créées à l'appel de la fonction et n'ont par conséquent pas d'adresse fixe, il n'est donc pas possible de les visualiser.
• 'Get Traj C.' est un cas particulier, les données récupérées sont celles d'une structure, où le code DSP stocke des infos relatives aux trajectoires courbes. Les infos sont affichées dans la liste aussi (décodées de la structure)
• 'Get Ligne' effectue la même chose pour le recalage de ligne. Ici il y'a un paquet d'infos à chaque recalage de ligne. Le nombre de ces paquets est affiché dans nb struct info. Les diverses infos du recalage de ligne sont affichées à droite de la boite. On peut changer de paquets d'info via les touches '+' et '-'. Il est à noter que ces infos s'affichent aussi graphiquement dans le terrain.
• 'Get LM' récupère les infos venant de données stockées par l'asservissement pour pouvoir les visualiser. La visu est faite par un programme Matlab (permettant de faire du traitement dessus aussi), bien plus simplement qu'en C. A l'origine, les données étaient écrites dans un fichier texte qui était ensuite transféré via liaison série sur un autre PC, les données étaient ensuite affichées via le prog Matlab sur l'autre PC. Par la suite la communication série a été écrite directement dans ce prog. (et un autre petit prog de l'autre côté recevait les infos). (Seul truc, il n'y a plus de contrôle d'erreurs, les données peuvent alors arriver corrompues (mais bon ce n'est que de l'affichage et Matlab s'en rend assez vite compte surtout si le grabuge est important.)
• Ces différents rapatriments de données, font que invariablement, il apparait à un moment ou un autre qu'il serait pratique de récupérer des floats depuis le DSP. Le hic, c'est que sur le DSP, le format est différent de celui du PC (IEEE). Il est donc nécessaire d'utiliser une routine de conversion (elle est fournie par TI) ces appels sont en général réalisés juste avant l'affichage des données. La boite simple n'affiche pas les données sous forme de float.

Chef

Controle de la carte principale

Cette carte n'a rien à voir avec la carte asservissement et permet de contrôler la carte principale. Il n'a pas spéciallement un interêt quelconque à être dans cette usine à gaz (sinon le fait de la grossir).

Cette boite permet donc de commander la carte principale via une liaison série(donc aucune connexion avec la carte d'asservissement). Il existait déjà un soft de commande pour la carte principale, mais il était fait sous Linux, et n'ayant qu'un ordi sous Linux -- qui n'était pas forcément toujours dispo, il a été refait pour permettre d'utiliser la carte principale directement à partir de ce soft.

L'ensemble des commandes n'a pas du être implémenté. Les principales sont :

• >RAM. qui permet de passer en mode ramassage (envoi cet ordre à la méca)
• >PAN. qui permet de passer en mode panier (envoi cet ordre à la méca)
• GOBER qui permet de gober une boule (envoi cet ordre à la méca)
• Status (case Méca), indique le satus de la carte mécanique (envoi cet ordre à la méca)
• BR : nomlbre de balles rouges
• BN : nombre de balles boires (infos retournées par la méca)

Les cases strat(égie) et Seq(enceur) ... ??? implémentées ???

La case Asser(vissement) qui représente donc la communication à la carte d'asservissement via la carte principale qui lui envoi des ordres sur le bus I2C (et reçoit les données par le même moyen). Implémenté ???

Conclusion

Ce soft nommé usine à gaz ne l'est pas spéciallement par la quantité de fonctions fournies (surtout si on ne compte que celles qui fonctionnent réellement)., mais bien plus par la façon de coder, et son évolution. Il s'agit d'un soft de debuggage. Pour faire fonctionner l'ensemble, ce soft est quasiment indispensable . Ici il se mêle des fonctions de debug et des fonctions plus 'indispensables' (chargement sur la carte, flashage,etc). Le regroupement de tout en un seul programme est juste une question de gain de temps et aussi parce que toutes les fonctions ont été crées ici et debuggée. Ce code est donc en perpétuel chantier, il y'a toujours un élément d'ajouté, retiré, modifié, pour palier au problème du moment.

Certains outils pourraient être 'extraits'. Le code peut soit être continué pour palier aux nouveaux besoins (mais en augmentant encore le côté 'foutoir'). Soit être repris, en se servant de morceaux de celui existant. Soit être épuré et continué. Il constitue en tout cas une certaine librairie d'exemples et de code pour utiliser avec la carte.