Association Québécoise de Robotique Amateur

Compétition Machine des Jeux de Génie 2010 - Robot Sherbrooke

Jean-François Duval — 2010-06-02T13:53:41Z

Les Jeux de Génie est la plus grande compétition d'ingénierie du Québec. Chaque année, la compétition de la machine en est l'épreuve maîtresse. Elle consiste en un défi commun lancé trois mois avant la compétition. Le défi : fabriquer une machine autonome et intelligente qui utilisera un bon nombre de capteurs et de senseurs afin de surmonter les diverses épreuves du parcours donné. La fabrication de cette machine nécessite la formation d'équipes multidisciplinaires qui devront investir beaucoup de temps afin d'en arriver à un produit des plus compétitifs. Cette année, la tâche était double. Il fallait concevoir et construire un groupe turbine et générateur hydraulique en plus d'un robot mobile. Le présent article présente le développement du robot.

Description générale

Pour commencer, voici la description de la portion robotique du défi Machine des Jeux de Génie 2010. Les informations viennent directement du manuel de règlements, tel que disponible sur le site officiel des Jeux de Génie (http://www.jeuxdegenie.qc.ca/).

"On vous demande de concevoir un robot capable de se déplacer dans un parcours fait en tuyau de PVC de 100mm (4'') de diamètre interne. Le robot doit être entièrement autonome. Les tuyaux seront obstrués par 4 objets

2 écrous de métal
2 embouts de patte de chaise en caoutchouc

Lorsqu'un objet est trouvé dans un conduit, vous devrez aller le disposer en dehors des canalisations dans l'une des deux zones désignées à cette fin. Le choix de la zone pour disposer un objet n'a pas d'importance avec le type d'objet. Les zones ont cependant une capacité limitée à deux objets. Dès qu'un objet est disposé dans une zone, une valve du bassin est fermée, augmentant ainsi le niveau d'eau mis à la disposition de votre générateur. La zone de dépôt est visible sur le plan du parcours. Une fois les canalisations désobstruées de tout objet, votre robot devra retourner au point de départ afin d'arrêter le chronomètre. Votre engin sera jugé sur sa rapidité d'exécution de la tâche, son design et sa capacité à accomplir correctement la tâche."

Présentation de l'équipe

Ce projet a été développé par 7 personnes qui se sont donné cœur et âme pendant 4 mois afin de se surpasser et de rehausser les standards de compétition. Tous sont étudiants en Génie à l'Université de Sherbrooke. En ordre alphabétique :

Julien Boisvert, Génie Mécanique : Conception et fabrication mécanique
Arthur Carré, Génie Informatique : Programmation
Jérôme Demers, Génie Électrique : Prototypage et fabrication robotique
Jean-François Duval, Génie Électrique : Responsable de l'équipe, conception et fabrication électronique et mécanique
Philippe Lavoie, Génie Informatique : Programmation
Pierre-Luc-St-Yves, Génie Mécanique : Conception et fabrication mécanique
Matthieu Tanguay, Maîtrise Robotique : Aide, conseils et fabrication mécanique

Résumé de notre cheminement

Le robot doit pouvoir se déplacer dans un parcours composé de tuyaux de 10cm qui comporte des virages à 90 degrés, des T, des ouvertures en hauteur, etc. Le principal défi a donc été de concevoir une machine autonome capable de se déplacer dans cet environnement, ce qui est plus difficile qu'il ne le semble. Pour pouvoir passer dans les T, le robot doit être de taille très réduite. Malgré cela, il doit être capable de manipuler des objets très lourds et volumineux. Réussir à garder le robot au fond des tuyaux fut un bon défi pour la majorité des équipes car les prototypes avaient tendance à s'agripper sur les parois et à perdre leur positionnement.

Après plusieurs essais de mécanismes de locomotions, l'équipe s'est fixée sur l'usage de chenilles, ce qui s'est avéré le mécanisme répondant le mieux à nos besoins. La bonne adhérence nous a permis de pousser plusieurs objets. De plus, en ayant une surface de contact étendue, nous avons évité de rester coincé dans les jonctions et les formes particulières des T. Bien que l'idée des chenilles était acceptée, il nous restait encore à concrétiser nos idées. Nous avons donc travaillé avec plusieurs prototypes.

Le tank en « métal lourd »

Notre premier prototype a été basé sur un jouet téléguidé. La douteuse traduction française du texte de l'emballage nous l'annonçait comme étant fait de métaux lourds... Heureusement, il n'y avait que du plastique ! Ce robot, bien qu'incapable d'entrer dans les tuyaux, nous a permis de tester la première version de l'électronique de contrôle ainsi que de commencer la programmation des déplacements et des détections d'obstacles.

Cette version de l'électronique a été conçue très rapidement et prototypée à l'Université, ce qui explique la mauvaise qualité du design et de la réalisation. Malgré tout, elle aura permis de tester le dsPIC33FJ128MC202, l'accéléromètre ADXL335 et le double driver de moteur TB6552, en plus de permettre aux programmeurs de se familiariser avec C30 et l'environnement de développement de Microchip.

Le mini tank télécommandé

Encore une fois, le robot a été construit à partir d'un jouet. Cette fois, nous avons pris un minuscule véhicule dont les dimensions correspondaient à notre objectif final. Avec ce petit tank, autant en mode télécommandé qu'en mode semi-autonome et autonome, nous avons pu confirmer que les chenilles étaient une solution gagnante pour se déplacer dans les tuyaux. Par contre, le jouet présentait quelques problèmes : manque d'adhérence, manque de puissance (incapable de déplacer les objets) et manque de fiabilité (les chenilles se détachaient très souvent). C'est sur ce robot qu'a été testée la deuxième version de notre électronique, une version de taille similaire mais beaucoup plus fonctionnelle et de qualité : PCB 4 couches, correction de bogues, amélioration de la distribution électrique et thermique, meilleure connectique, dsPIC33FJ128MC204 pour avoir plus d'entrées/sorties, etc.

Prototype maison, fabrication traditionnelle

Ce prototype a été fabriqué à base de plastique et de quelques pièces usinées par un membre de l'équipe. Sa géométrie ne lui permettait pas de bien se déplacer dans les tuyaux : il fallait réduire sa longueur. Il a toutefois été utile pour confirmer le choix et le positionnement des capteurs infrarouges.

Concept final : StableBot

Afin d'optimiser l'usage du faible volume disponible, nous avons modélisé les composantes de notre robot sous SolidWorks. Nous avions donc maintenant la possibilité d'essayer rapidement des agencements et des configurations. Plusieurs dessins ont été faits, critiqués et modifiés.

Pour réaliser nos prototypes de StableBot, nous avons utilisé une imprimante 3D Stratasys, gracieuseté de l'IntRoLab de l'Université de Sherbrooke. Cette technologie nous a permis de concevoir un châssis très complexe, mais pour autant très léger et rapide à obtenir. Avec une solution d'usinage classique, nous aurions eu besoin de beaucoup plus de temps pour la conception et la fabrication.

Nous avons développé une 3e et dernière version de notre électronique pour ce robot. La connectique a été optimisée, le volume de la carte a été réduit par une modification du positionnement de certaines pièces, nous avons ajouté des boutons pour l'utilisateur et retravaillé la forme pour faciliter l'intégration et le câblage sur le robot.

Commanditaires

Un grand merci aux commanditaires de la Machine, sans qui ce projet aurait été impossible à réaliser !

Microchip
IntRoLab, Université de Sherbrooke
Labo Circuits
Solarbotics
Les Industries Rilec Inc.
Poly Alto
Atelier Pedro
Département GEGI de l'Université de Sherbrooke

Vidéo

Voici un vidéo du robot tourné au Capitole de Québec, lors de notre dernier essai avant la compétition. Le robot est autonome (aucun contrôle à distance).

Porter U-Boot sur un Blackfin BF532 sous Ubuntu

Jean-François Duval — 2009-08-18T20:53:09Z

Sommaire

Version 1.1 de l'article et du document, en date du 21 août 2009.

Introduction

Le présent document explique comment j'ai porté U-Boot sur un Blackfin BF532 en utilisant un JTAG ICEBear et une machine virtuelle sous Ubuntu 9.04. Les informations contenues dans ce texte ne sont en aucun cas exclusives ou totalement nouvelles, tout comme je ne suis pas un guru Linux et un maître Blackfin. Le but est plutôt de simplifier la tâche à quelqu'un qui aurait à suivre un parcours similaire au mien et à regrouper les informations et les techniques que j'ai apprises en consultant divers sites, en expérimentant et en posant beaucoup de questions.

Initialement, mon développement s'est fait sous une machine Debian Etch 4.0 (sous VMWare Player) afin d'être le plus semblable possible au système de développement de Section5. Afin de rendre le tout plus accessible, j'ai reproduit ma démarche sous Ubuntu 9.04 et VirtualBox et j'ai consigné toutes mes étapes dans ce document. Les utilisateurs expérimentés de Linux me trouveront probablement redondant, mais je préfère fournir trop d'informations plutôt que pas assez. Vous y verrez d'ailleurs mes erreurs et la manière dont je m'en suis sorti. Je préfère expliquer le cheminement complet plutôt que simplement la solution finale afin d'aider un maximum de personnes à progresser plus rapidement.

Définition de quelques termes

Section5 : Petite compagnie Suisse qui produit et vend certains outils de développement pour Blackfin. Site web : http://section5.ch/ (plus précisément : http://section5.ch/embedded). Le responsable est Martin Strubel et peut être contacté par leur forum ou par email : strubel-@-section5-.-ch.

ICEBear : Adaptateur JTAG de Section5.

BFLoader : Utilitaire permettant de programmer la Flash d'une carte Blackfin (fourni par Section5, sources disponibles).

GDBProxy+Insight : Outils de débogage du Blackfin. Utilisés avec le ICEBear, ils permettent la programmation et le débogage (step-by-step, break point, register dump, etc.) Note : il est important d'utiliser la version disponible sur le site de Section5 et non celle de µCLinux si on veut une compatibilité avec le ICEBear !

Gigamodule : Carte électronique développée par l'équipe [Robot22], un groupe de finissants de Génie Électrique et Informatique de l'Université de Sherbrooke et moi. Le Gigamodule v0.1 est simplement composé d'un Blackfin BF532, d'une RAM parallèle (MT48LC32M16A2, 512Mb), d'une Flash SPI (AT45DB321, 32Mb), d'un convertisseur série USB (FT232) et de quelques périphériques et connecteurs. Elle sert de prototype à un système plus complexe de bus de communication haute-vitesse.

Informations sur le système

PC utilisé pour mon développement :

Intel Core2Duo T5850 @ 2.16GHz
4.00GB RAM
Windows Vista 64bits

Version des outils :

U-Boot : 1.1.6-2008R1.5
BFLoader : 1.3beta
VirtualBox 3.0.4
Ubuntu 9.04 32bits

Une machine virtuelle a été créée avec VirtualBox 3.0.4 et Ubuntu 9.04 32bits y a été installé. Toutes les informations présentes dans ce document se basent sur ce système.

Il est préférable de travailler comme root pour éviter les problèmes de permissions. Vous pouvez remarquer par le prompt quand je suis root ou pas ($ = user, # = root). Si vous travaillez comme user, il suffit de mettre sudo devant les commandes importantes.

Note : Pour les utilisateurs de VirtualBox et d'Ubuntu, si la résolution de votre écran ne vous satisfait pas vous pouvez consulter ce site afin de régler le problème : http://www.linuxformat.co.uk/forums/viewtopic.php ?t=6438.

Nos outils : JTAG ICEBear et logiciels de Section5

C'est avec le JTAG ICEBear que nous allons pouvoir transférer notre code compilé dans la mémoire du Blackfin. La présente section explique l'installation des outils, le test et la modification de ces outils.

Installation des logiciels

Source principale d'informations : le ICEBear Manual (PDF) contient beaucoup d'informations utiles. Une bonne partie des commandes utilisées dans cette section en sont tirées.

Afin de pouvoir utiliser apt-get install pour télécharger et installer les paquets fournis par Section5, il faut modifier /etc/apt/sources.list :

On lui ajoute en bas du fichier la ligne suivante :

On sauvegarde et ferme. On met à jour la liste des sources disponibles :

On peut maintenant installer la suite ICEBear :

Certaines dépendances ne sont pas résolues, on tente de corriger ça :

jfduval@jfduval-desktop:~$ sudo apt-get install libbfemu Reading package lists... Done Building dependency tree Reading state information... Done Some packages could not be installed. This may mean that you have requested an impossible situation or if you are using the unstable distribution that some required packages have not yet been created or been moved out of Incoming. The following information may help resolve the situation: The following packages have unmet dependencies: libbfemu: Depends: libftdi0 (>= 0.7) but it is not installable E: Broken packages jfduval@jfduval-desktop:~$ sudo apt-get install libftdi0 Reading package lists... Done Building dependency tree Reading state information... Done Package libftdi0 is not available, but is referred to by another package. This may mean that the package is missing, has been obsoleted, or is only available from another source E: Package libftdi0 has no installation candidate

Alors, la solution est d'aller télécharger directement le package libftdi0 sur un serveur Debian. On va à l'adresse suivante : http://packages.debian.org/etch/i386/libftdi0/download On double clique ensuite sur le .deb et on installe (tout se fait en GUI).

Ensuite, libbfemu s'installe correctement :

jfduval@jfduval-desktop:~/Desktop/libftdi-0.16$ sudo apt-get install libbfemu Reading package lists... Done Building dependency tree Reading state information... Done The following packages were automatically installed and are no longer required: linux-headers-2.6.28-11 linux-headers-2.6.28-11-generic Use 'apt-get autoremove' to remove them. The following NEW packages will be installed: libbfemu 0 upgraded, 1 newly installed, 0 to remove and 0 not upgraded. Need to get 62.2kB of archives. After this operation, 225kB of additional disk space will be used. WARNING: The following packages cannot be authenticated! libbfemu Install these packages without verification [y/N]? y Get:1 http://www.section5.ch etch/non-free libbfemu 1.3-2 [62.2kB] Fetched 62.2kB in 1s (41.2kB/s) Selecting previously deselected package libbfemu. (Reading database ... 121361 files and directories currently installed.) Unpacking libbfemu (from .../libbfemu_1.3-2_i386.deb) ... Setting up libbfemu (1.3-2) ... * Stopping kernel event manager... [ OK ] * Starting kernel event manager... [ OK ] Processing triggers for libc6 ... ldconfig deferred processing now taking place jfduval@jfduval-desktop:~/Desktop/libftdi-0.16$

Deuxième tentative d'installation de la suite ICEBear :

jfduval@jfduval-desktop:~/Desktop/libftdi-0.16$ sudo apt-get install icebear-gdbproxy Reading package lists... Done Building dependency tree Reading state information... Done The following packages were automatically installed and are no longer required: linux-headers-2.6.28-11 linux-headers-2.6.28-11-generic Use 'apt-get autoremove' to remove them. The following NEW packages will be installed: icebear-gdbproxy 0 upgraded, 1 newly installed, 0 to remove and 0 not upgraded. Need to get 38.4kB of archives. After this operation, 143kB of additional disk space will be used. WARNING: The following packages cannot be authenticated! icebear-gdbproxy Install these packages without verification [y/N]? y Get:1 http://www.section5.ch etch/non-free icebear-gdbproxy 0.8-5 [38.4kB] Fetched 38.4kB in 0s (41.1kB/s) Selecting previously deselected package icebear-gdbproxy. (Reading database ... 121368 files and directories currently installed.) Unpacking icebear-gdbproxy (from .../icebear-gdbproxy_0.8-5_i386.deb) ... Processing triggers for man-db ... Setting up icebear-gdbproxy (0.8-5) ... jfduval@jfduval-desktop:~/Desktop/libftdi-0.16$

On peut maintenant installer les autres packages : bfinsight, bfloader, bfin-elf-toolchain, libbfemu-dev. On utilise toujours la même commande sudo apt-get install nom_du_paquet.

Note : pour éliminer le message d'erreur d'authentification des sources, se référer à la section B.1 du ICEBear Manual afin de savoir comment installer la clé.

Une fois ces opérations effectuées, nous avons une chaîne complète pour utiliser le JTAG.

Test de la chaîne JTAG

Pour utiliser BFLoader, il suffit de taper la commande flashload. Pour avoir des informations sur la chaîne, il suffit de faire

Si vous obtenez :

C'est causé par le système udev présent dans les dernières versions de Debian et d'Ubuntu. En se basant sur les informations du ICEBear Manual, on va modifier les accès. Premièrement, on peut télécharger le package ICEBear distribution 1.2 sur http://www.section5.ch/software. Ouvrir l'archive, naviguer jusqu'à /ICEbear-linux-1.21beta/udev/ et extraire le fichier 45-icebear.rules ou aller sur http://www.section5.ch/forum/viewtopic.php ?f=1&t=58&p=169&hilit=ubuntu#p169 et télécharger http://www.section5.ch/dsp/icebear/45-icebear.rules.

On copie ensuite ce fichier dans le bon répertoire :

et on redémarre le tout :

Personnellement j'ai encore des messages d'erreur, mais faire sudo avant flashload (ou travailler en root) me permet de bien détecter ma carte, alors tout est fonctionnel ! Une chaîne fonctionnelle devrait vous donner au minimum :

Le reste des informations n'est peut-être pas pertinent, tout dépendant de votre hardware. Il faut en effet utiliser le bon backend pour que les données affichées soient cohérentes.

Atmel SPI Flash

Normalement, le programme BFLoader permet de charger le fichier .ldr obtenu par la compilation de U-Boot directement dans la Flash, qu'elle soit parallèle (sur le bus mémoire) ou SPI. Par contre, il s'avère que le driver SPI ne supporte que les Flash ST et compatibles, qui utilisent un protocole standard et des pages de 512 octets. Évidemment, afin d'augmenter le défi, la carte Gigamodule dispose d'une Flash Atmel qui utilise le protocole Dataflash (commandes plus évoluées et pages de 528 octets), ce qui rend impossible l'utilisation telle quelle de BFLoader. Le code de BFLoader a été modifié légèrement pour détecter les Flash Atmel. Par contre, refaire complètement le driver n'était pas assez nécessaire pour être fait, il existe d'autres possibilités pour programmer U-Boot dans la Flash que nous explorerons dans les prochaines sections.

Modification de BFLoader

Tel que mentionné dans le précédent paragraphe, il est possible de modifier BFLoader pour lui ajouter certaines fonctionnalités. Dans mon cas, la modification aura été d'ajouter un certain support pour les SPI Flash Atmel. Maintenant, plutôt que de mettre un simple message d'erreur, une AT45DB321D (ou toute autre Flash de la famille AT45DBxxxD) peut être détectée et ses caractéristiques sont affichées. Les informations qui suivent expliquent comment changer le backend spi_flash.dxe pour lui ajouter des fonctions.

Obtenir les sources

La première étape est d'obtenir les sources de BFLoader. On peut les télécharger ici : http://www.section5.ch/dsp/icebear/bfloader-1.3beta.tgz. Il suffit ensuite de faire Extract Here et on obtient un dossier BFLoader. Dans mon cas, son chemin d'accès est /home/jfduval/Desktop/bfloader/.

Compiler les sources

Avant de modifier quoi que ce soit, on va compiler pour s'assurer que tous nos outils soient corrects. Une fois placé dans le répertoire /home/jfduval/Desktop/bfloader/, on nettoie :

Puis on compile :

En cas d'erreur de compilation avec un message comme de quoi libelf ne peut pas être trouvé, il faut faire (référence : /home/jfduval/Desktop/bfloader/README) :

Ensuite, il est possible de compiler sans problèmes.

Modifier les sources

Je vais vous expliquer ici comment j'ai modifié quelques fichiers afin de changer facilement le backend spi_flash.dxe. Premièrement, afin de m'assurer que je modifiais bien ma version de BFLoader, j'ai ajouté mon nom dans le string s_version de /home/jfduval/Desktop/bfloader/main.c. Ainsi, je peux confirmer que j'exécute bien les sources que je modifie :

Notez l'usage de l'opérateur ./ qui me permet de lancer la version locale de flashload et nom celle placée dans /apt/.

Ensuite, on peut modifier le champ AFP_Title de /home/jfduval/Desktop/bfloader/boards/spi_flash/main.c ainsi : *AFP_Title = "SPI flash programmer with limited Atmel support" ; Pour compiler un backend, il suffit de se placer dans son répertoire et de faire make. Il est toujours préférable de faire un make clean préalablement.

On teste :

On comprend que la modification n'a pas été prise en compte, le Driver Title n'est pas celui qu'on vient de modifier. L'explication se trouve dans le fichier /home/jfduval/Desktop/bfloader/main.c, vers la ligne 189. Le chemin de recherche des backends pointe vers la « version APT » de BFLoader et non vers notre version modifiée. Il faut donc changer cela par : char prefix[FILESTR_SIZE] = "/home/jfduval/Desktop/bfloader/boards/spi_flash/" ;

Avant de tester, on nettoie (make clean) le répertoire /spi_flash/ et on supprime les exécutables .dxe. Après la compilation (make), on observe que seul bfloader.dxe sera créé dans le dossier. Si vous testez, vous obtiendrez :

Il existe deux manières de régler ce problème. La première est, après chaque nouvelle compilation, de renommer bfloader.exe par spi_flash.dxe. La seconde manière, plus élégante à mon avis, est d'éditer le fichier /home/jfduval/Desktop/bfloader/bfloader.mk. On remplace :

Par :

Les détails de l'ajout de la détection des Flash Atmel ne seront pas expliqués ici. Si cet ajout vous intéresse, vous pouvez consulter directement ma version de main.c. Voici un exemple fonctionnel :

Première application : faire clignoter une DEL !

Source principale d'informations : le ICEBear Manual (PDF)

L'exemple qui suit se base sur le code Blinky fourni par Section5. Bien que de faire clignoter une DEL puisse sembler très simple, c'est une étape importante à accomplir. En effet, c'est ce qui nous permettra de tester notre hardware et nos outils.

Sources de Blinky et montage électronique

La première étape est évidemment de se procurer les sources de Blinky. Pour cela, il suffit de les télécharger ici : http://www.section5.ch/dsp/blackfin/blinky.tgz. On extraie ensuite le dossier blinky/.

Le montage électronique est très simple. Il suffit de mettre une DEL, avec une résistance de 300 à 500Ω en série, entre la pin PF2 et la masse. Le boot mode est 00 (sur le Gigamodule, les 2 jumpers sont mis en place).

Compiler Blinky

Pour cet exemple, on va compiler Blinky pour une carte Stamp BF533. On commence par se placer dans le bon répertoire :

On nettoie et on compile pour le Stamp :

La compilation a échoué, il manque un fichier ccblkfn.h. En effectuant une recherche de fichiers, on peut localiser le fichier /home/jfduval/Desktop/bfloader/include/ccblkfn.h. On en fait une copie dans le répertoire Include de la suite d'outils :

On réessaie la compilation :

Et ça fonctionne ! Vous avez maintenant une version compilée de Blinky. Par contre, dépendant du hardware sur lequel vous travaillez, il est possible que cette version ne soit pas compatible.

Modifier Blinky

Outil intéressant : Pour calculer les paramètres de la RAM, vous pouvez utiliser cette feuille de calcul.

Originalement, les exemples sont faits pour les cartes Stamp, EZKIT et autres. Pour tester Blinky sur le Gigamodule, j'ai effectué quelques modifications aux sources. Mon projet modifié se trouve dans le répertoire /home/jfduval/Desktop/blinky_mod/. Je ne justifierai pas tous les changements, car ces informations sont intrinsèquement liées au matériel que vous utilisez. Le but est plutôt de vous montrer en gros ce qui peut et doit être changé. Je n'ai pas pris le temps d'ajouter une nouvelle carte. J'ai plutôt trafiqué le EZKIT pour l'adapter au Gigamodule. Les principales modifications visent à changer le projet pour inclure le BF532, ajuster les fréquences et ajuster les adresses mémoires. Dans ma version, la DEL clignote à l'infini, plutôt qu'un certain nombre de cycles.

auxiliaries.asm
Original	Modifié
#include <defBF533.h>	#include <defBF532.h>
p0.l = LO(0xffa00000); p0.h = HI(0xffa00000);	p0.l = LO(0xffa08000); p0.h = HI(0xffa08000);

config.h
Original	Modifié
#if defined(BOARD_EZKIT_BF533) #define MASTER_CLOCK 27000000 #define SCLK_DIVIDER 4 #define VCO_MULTIPLIER 16 #define CCLK_DIVIDER 1	#if defined(BOARD_EZKIT_BF533) //Adapted for Gigamodule BF532 #define MASTER_CLOCK 25000000 #define SCLK_DIVIDER 5 #define VCO_MULTIPLIER 12 #define CCLK_DIVIDER 1
#define L1_DATA_SRAM_A 0xff800000	#define L1_DATA_SRAM_A 0xff804000

crt0.asm
Original	Modifié
#include <defBF533.h>	#include <defBF532.h>

main.c
Original	Modifié
#include <defBF533.h>	#include <defBF532.h>
#if defined(BOARD_EZKIT_BF533) #define pFlashA_PortB_Dir (volatile unsigned char ) 0x20270007 #define pFlashA_PortB_Data (volatile unsigned char ) 0x20270005 void do_blink(void) { int i; // Initialize EBIU async memory banks pEBIU_AMBCTL0 = 0x7bb07bb0; pEBIU_AMBCTL1 = 0x7bb07bb0; pEBIU_AMGCTL = 0x000f; // init flash a port b direction pFlashA_PortB_Dir = 0x3f; i = 0; int leds = 0x15; while (i < 40) { *pFlashA_PortB_Data = leds; delay(); leds ^= 0xff; i++; } }	#if defined(BOARD_EZKIT_BF533) //#define pFlashA_PortB_Dir (volatile unsigned char ) 0x20270007 //#define pFlashA_PortB_Data (volatile unsigned char ) 0x20270005 void do_blink(void) { /* int i; // Initialize EBIU async memory banks pEBIU_AMBCTL0 = 0x7bb07bb0; pEBIU_AMBCTL1 = 0x7bb07bb0; pEBIU_AMGCTL = 0x000f; // init flash a port b direction pFlashA_PortB_Dir = 0x3f; i = 0; int leds = 0x15; while (i < 40) { pFlashA_PortB_Data = leds; delay(); leds ^= 0xff; i++; } / int i; pFIO_DIR = 0x001c; pFIO_FLAG_D = 0x0008; pFIO_INEN = 0x0160; // enable input for buttons i = 0; while(1){ //while (i < 20) { pFIO_FLAG_T = 0x001c; delay(); //i++; } }

Vous disposez maintenant d'une version adaptée de Blinky.

Faire fonctionner Blinky sur le Blackfin

Sur une machine Ubuntu récente, il est fort probable que de faire :

ne produise aucun résultat. Il existe un petit problème avec Insight, qu'on contournera en effectuant (source : http://www.section5.ch/forum/viewtopic.php ?f=1&t=70) cette commande :

On a maintenant une fenêtre Insight qui s'ouvre. Maintenant que ce problème est réglé, on peut fermer Insight et suivre la bonne procédure. Il faudra refaire cette exportation à chaque fois qu'une nouvelle console est ouverte.

Dans le répertoire blinky_mod/, j'ai créé un fichier texte intitulé cfg.gdbinit qui contient les informations suivantes :

Ce fichier a été conçu en m'inspirant des exemples du ICEBear Manual et des différentes documentations existant sur le ICEBear, BFLoader et Blinky. Ce script permet d'automatiser certaines tâches répétitives.

ICEBear sur un second PC

Il existe plusieurs manières de procéder. À l'origine, j'ai éprouvé certains problèmes de stabilité avec les pilotes USB de ma machine virtuelle Debian Etch sous VMWare Player. J'ai donc décidé de connecter le ICEBear sur un PC Windows XP, qui est relié au mien par le réseau local. Ainsi, GDBProxy se connecte sur le second PC et tout fonctionne. Sur le PC XP, il suffit de télécharger la suite à l'adresse http://www.section5.ch/dsp/icebear/ICEbear-1.21-setup.exe et d'installer le tout. On peut ensuite lancer GDBProxy, qui devrait nous afficher la détection d'un Device et préciser qu'il attend sur le port 2000. Notez que vous pouvez aussi utiliser les Demos pour tester votre hardware.

On commence par se placer dans le bon répertoire puis on lance Insight (on a déjà GDBProxy qui attend sur l'autre machine) :

Portez attention au fait que pour lancer Insight je marque explicitement son chemin. Si on oublie ce « détail » il est possible que ce soit la version µCLinux/U-Boot de Insight qui ouvre et, même si en apparence c'est le même logiciel, elle n'est pas compatible avec le ICEBear.

On a maintenant une fenêtre Insight ouverte. On clique sur Run > Connect to target. On configure ensuite le tout ainsi :

Target : Remote/TCP
Hostname : 192.168.1.205
Port : 2000

La ligne de code surlignée devrait maintenant être verte. On fait ensuite Run > Download. Maintenant, si on appuie sur le bouton Continue, le programme devrait rouler et la DEL clignoter ! Pour explorer les possibilités d'Insight/GDB, je vous conseille d'expérimenter, tout en vous référant au ICEBear Manual.

Tout sur la même machine

Source principale d'informations : le ICEBear Manual (PDF), section Application Notes

Voici une deuxième manière de procéder, beaucoup plus simple et élégante, à condition de ne pas avoir de problème de connexion avec les périphériques USB sur la machine virtuelle. La combinaison Ubuntu 9.04 et VirtualBox semble beaucoup plus stable sur ce point que Debian et VMWare. La première chose à faire est d'ouvrir un second terminal et d'y lancer GDBProxy :

Dans notre terminal principal, on lance Insight :

On a maintenant une fenêtre Insight ouverte. On clique sur Run > Connect to target. On configure ensuite le tout ainsi :

Target : Remote/TCP
Hostname :
Port : 2000

La ligne de code surlignée devrait maintenant être verte. On fait ensuite Run > Download. Maintenant, si on appuie sur le bouton Continue, le programme devrait rouler et la DEL clignoter !

U-Boot et outils associés

Installation de la toolchain

Source principale d'informations : le Wiki Blackfin Koop

Il faut commencer par ajouter le répertoire des sources de µCLinux et de la toolchain Blackfin à notre chemin de recherche de apt-get :

N'ayant pas eu de succès, j'ai créé le fichier blackfin.sources.list (simple fichier texte créé avec gedit) sur mon bureau et y ai mis la ligne deb http://download.analog.com/27516/distros/debian stable main, puis je l'ai envoyé à la bonne place :

On fait un sudo apt-get update pour tenir compte des dernières modifications puis, toujours en suivant les informations du wiki (http://docs.blackfin.uclinux.org/doku.php ?id=toolchain :installing) on installe le tout :

Vous possédez maintenant tous les outils nécessaires pour compiler U-Boot. Avant de les utiliser, il ne reste qu'une seule étape : ajuster la variable d'environnement PATH. En se basant sur http://docs.blackfin.uclinux.org/doku.php ?id=toolchain :installing on fait :

Sources de U-Boot

Télécharger les sources de U-Boot ici : http://blackfin.uclinux.org/gf/project/u-boot/frs On fait clic droit et Extract Here, puis on a un dossier U-Boot avec tous les fichiers nécessaires. Pour ma part, j'ai utilisé la dernière version stable, soit la 1.1.6-2008R1.5.

Compiler U-Boot

Pour compiler U-Boot, il est conseillé de travailler en root pour éviter les problèmes de permissions. Pour commencer, il faut se placer dans le bon répertoire (U-Boot) :

Il faut maintenant configurer le projet. Pour fin d'exemple, nous allons compiler pour un BF533 Stamp :

On peut maintenant nettoyer et compiler :

Si vous obtenez une erreur disant gawk not found, il suffit d'installer gawk :

Si la compilation est un succès, un fichier u-boot.ldr sera créé dans le répertoire principal. C'est ce fichier que nous utiliserons pour programmer le Blackfin.

Modifier U-Boot

Source principale d'informations : la section Porting U-Boot du Wiki Blackfin Koop

Cette section ne décrira pas en détail la modification des fichiers de U-Boot, la documentation existante étant assez complète. Je vais plutôt vous pointer vers les bonnes références et vous montrer où trouver les fichiers à modifier.

Pour savoir comment modifier le makefile, le fichier de configuration et le répertoire de projet, se référer à la section Porting U-Boot du wiki. Bien que les informations sur le wiki soient assez claires, je considère que ce qu'il manque le plus c'est une liste des modifications possibles. Pour connaître ces commandes, il suffit de regarder le fichier README du répertoire U-Boot. On y trouve beaucoup d'informations utiles.

Outil intéressant : Pour calculer les paramètres de la RAM, vous pouvez utiliser cette feuille de calcul.

Répertoires importants

La version stable actuelle de U-Boot est 1.1.6-2008R1.5. Tout le développement a été effectué avec cette version. Plusieurs essais ont été faits afin de porter U-Boot correctement, j'ai donc créé quelques dossiers de projet. Le projet que j'utilise actuellement est le bf532-giga2. La liste des chemins ci-dessous est donc adaptée à ma version. Le plus simple est de partir d'un projet similaire et de modifier ses sources. Dans mon cas, je me suis basé sur le Stamp BF533, le Blackfin One, le Minotaur BF537 et le SRV-1.

U-Boot : /home/jfduval/Desktop/u-boot-1.1.6-2008R1.5_Giga/ : Répertoire principal de U-Boot. C'est une copie du répertoire originale où se trouvent mes fichiers modifiés.

board : /home/jfduval/Desktop/u-boot-1.1.6-2008R1.5_Giga/board/ (dans notre cas, on utilise /home/jfduval/Desktop/u-boot-1.1.6-2008R1.5_Giga/board/bf532-giga2/) : Fichiers propres à notre projet.

configs : /home/jfduval/Desktop/u-boot-1.1.6-2008R1.5_Giga/include/configs/ : Fichier de configuration de notre projet (bf532-giga2.h)

gdbscripts : /usr/share/gdbscripts : Scripts pour GDBProxy

Atmel Dataflash : outil de conversion

Pour que le Blackfin puisse booter depuis une Flash SPI, il faut qu'elle respecte certains critères : adresses de 8, 16 ou 24bits et pages de taille « puissance de 2 ». Ce dernier point est important dans notre cas, car par défaut les Dataflash utilisent des pages de 528bytes (et non de 512). La datasheet du AT45DB321D explique qu'il est possible de changer la Flash en mode 512bytes en suivant une procédure somme toute assez simple. Devant l'absence d'outil dans BFLoader et dans U-Boot pour effectuer ce changement, j'ai écrit la fonction nécessaire.

Le fichier que j'ai modifié est /home/jfduval/Desktop/u-boot-1.1.6-2008R1.5_Giga/board/bf532-giga2/spi_flash.c. Dans la fonction eeprom_info(void), tout juste avant SPI_DEINIT() ; il faut ajouter la ligne suivante :

Ensuite, après la fonction eeprom_info(void) on ajoute cette fonction :

//ATMEL Spi Flash Power-of-Two Tool (JFDuval, IntRoLab, 2009) int atmel_po2(int size) { char InData; if(size == 528) { //It's in Dataflash, we can change it printf("Your FLASH uses 528 bytes pages. It can be converted to 512 bytes\n" "pages. Important: conversion is PERMANENT (no come back). Want to\n" "change it to 512? [y/n]"); InData = getc(); if((InData == 'y')||(InData == 'Y')) { printf("\nRunning conversion tool...\n"); //Open SPI SPI_ON(); //Send the 4 configuration bytes printf("Byte: 0x3D\n"); spi_write_read_byte(0x3D); printf("Byte: 0x2A\n"); spi_write_read_byte(0x2A); printf("Byte: 0x80\n"); spi_write_read_byte(0x80); printf("Byte: 0xA6\n"); spi_write_read_byte(0xA6); printf("Wait a moment than cycle power.\n"); //Close SPI SPI_OFF(); } else printf("\nNo modifications will be done.\n"); } else if(size == 512) { printf("This FLASH is in Power-of-Two mode.\n"); } }

Pour l'utiliser, il suffit de faire rouler U-Boot et de faire la commande eeprom info (voir Utiliser U-Boot : quelques commandes). Les instructions seront alors fournies pour modifier correctement votre Flash. Attention : le changement est permanent !

Exemple de fonctionnement (mon prototype est déjà en mode puissance de 2) :

Cet outil n'est seulement disponible que si vous modifiez votre U-Boot avec les changements décrits dans cette section ou que vous travaillez avec mes sources. Il est possible que cet outil soit ajouté aux prochaines versions de U-Boot, mais ce n'est pas encore le cas.

Utiliser U-Boot sur votre Blackfin

Maintenant que vous disposez d'une version compilée de U-Boot, il est temps de programmer un Blackfin avec ce code et de tester en conditions réelles si le tout est fonctionnel.

Charger U-Boot en mémoire

Normalement, le programme BFLoader permet de charger le .ldr directement dans la Flash, qu'elle soit parallèle (sur le bus mémoire) ou SPI. Par contre, il s'avère que le driver SPI ne supporte que les Flash ST et compatibles, qui utilisent un protocole standard et des pages de 512 bytes. La carte Gigamodule disposant d'une Flash Atmel qui utilise le protocole Dataflash (commandes plus évoluées et pages de 528 bytes). On va donc agir comme pour Blinky, on va charger U-Boot dans la RAM, en utilisant le ICEBear et GDBProxy/Insight, et l'exécuter. U-Boot étant capable de s'inscrire en mémoire, nous pourrons atteindre notre but malgré cet obstacle.

Note : plutôt que de répéter des informations, je vous réfère aux sections Atmel SPI Flash et Faire fonctionner Blinky sur le Blackfin. La démarche pour U-Boot étant très semblable à celle pour Blinky, je ne noterai ici que les différences.

Premièrement, il faut faire tourner GDBProxy avec le JTAG connecté sur la carte. Ensuite, il faut connecter la carte au PC par son interface série. Sur le Gigamodule, on utilise le connecteur USB car un circuit de conversion Série<>USB (FT232) est présent sur la carte. On ouvre un terminal RS-232 (voir la section Console RS-232 pour détails).

Comme pour Blinky, un fichier de scripts GDB est utilisé afin d'automatiser certaines tâches. Mon fichier /home/jfduval/Desktop/u-boot-1.1.6-2008R1.5_Giga/cfg.gdbinit contient :

On se place dans le bon dossier et on lance Insight :

Je rappelle qu'il est important de spécifier le chemin de l'exécutable Insight afin que ce soit la version Section5 et non celle µCLinux qui charge !

Maintenant qu'Insight est lancé, on peut faire File > Source... > cfg.gdbinit > Open. Quand les icônes du débogueur deviendront colorées, c'est prêt à être utilisé. Notez que si vous utilisez une connexion réseau avec un autre PC, le transfert peut prendre quelques minutes. On appuie ensuite sur Continue. Dans la fenêtre de terminal, on devrait lire quelque chose du genre :

Early:start.S: Init Registers Early:start.S: Relocate Early:start.S: Lower to 15 Early: NOP Slide Early: Board init flash Early: Init CPLB tables Early: Exceptions setup Early: Turn on ICACHE Early: Turn on DCACHE Early: Init global data Early: IRQ init Early: Environment init Early: Baudrate init Early: Serial init Early: Console init flash Early: End of early debugging U-Boot 1.1.6 (ADI-2008R1.5) (Jul 10 2009 - 17:23:34) CPU: ADSP bf532-0.5 (Detected Rev: 0.5) Board: IntRoLab BF532 GigaModule v2 Clock: VCO: 300 MHz, Core: 300 MHz, System: 60 MHz RAM: Serial Port initialized with Baud rate = 115200 SDRAM attributes: tRCD 3 SCLK Cycles,tRP 3 SCLK Cycles,tRAS 6 SCLK CyclestWR 2 SCLK Cycles,CAS Latency 3 SCLK cycles SDRAM Begin: 0x0 Bank size = 64 MB 64 MB *** Warning - bad CRC, using default environment In: serial Out: serial Err: serial gd: 3f9c000 |-flags: 3 |-board_type: 0 |-baudrate: 115200 |-have_console: 1 |-ram_size: 0 |-reloc_off: 0 |-env_addr: 3fa000c |-env_valid: 1 |-jt(3fb0168): 3fc5d50 \-bd: 3f9c028 |-bi_baudrate: 1c200 |-bi_ip_addr: 0 |-bi_enetaddr: 0 0 0 0 0 0 |-bi_boot_params: 0 |-bi_memstart: 0 |-bi_memsize: 4000000 |-bi_flashstart: 0 |-bi_flashsize: 0 \-bi_flashoffset: 0 bfin-giga>#

Et voilà ! On a maintenant U-Boot qui tourne en RAM sur notre propre carte. Dans les prochaines sections, on verra comment utiliser U-Boot et comment l'écrire dans une Flash SPI.

Console RS-232

Source principale d'informations : la section Loading Files With U-Boot via The Serial Port du Wiki U-Boot

La carte Blackfin Gigamodule étant munie d'un convertisseur Série<>USB FT232, il faut connecter le câble USB à un PC. Les drivers du FT232 sont disponibles sur le site de FTDI. Notez que dans les versions récentes de Linux, les drivers sont déjà inclus. Il faut ensuite configurer le port série. Pour le Gigamodule, les valeurs ont été changées dans les sources et sont : 115200 bits/s, 8 bits, No parity, 1 Stop Bit, No Flow Control. Par défaut, c'est : 57600 bits/s, 8 bits, No parity, 1 Stop Bit, No Flow Control.

Lors du choix d'un programme de terminal, il est important de s'assurer qu'il permette le transfert de fichiers avec le protocole Y-Modem. Il y a deux manières de travailler. Vous pouvez ouvrir le terminal sous votre machine hôte, typiquement sous Windows, ou vous pouvez l'ouvrir dans la machine virtuelle, Ubuntu dans notre cas.

Windows

Dans mon cas, Hyperterminal a été utilisé. Notez qu'il suffit de copier l'exécutable et le .dll d'un PC sous XP pour l'avoir sous Vista.

Théoriquement, U-Boot permet le transfert de fichier par 2 protocoles : Kermit et Y-Modem. Même si Hyperterminal supporte les 2, il y a un problème avec Kermit, les données transférées ne sont pas bonnes. Utiliser Y-Modem permet un bon transfert de l'image. Pour transférer une image, il suffit de faire Transfer > Send file... > Filename = u-boot.ldr Protocole = Ymodem > Send.

Ubuntu 9.04

Source principale d'informations : les sections Loading Files With U-Boot via The Serial Port et Terminal Programs du Wiki

Pour utiliser Ymodem, le Wiki U-Boot recommande l'usage de Minicom. Les informations de la section Terminal Programs décrivent bien comment l'installer et le configurer. J'ai reproduit ce qui est expliqué là, à la différence près que mon port série, obtenu par le FT232, est ttyUSB0. Je vous préviens, pour quelqu'un habitué aux programmes modernes et aux GUI, Minicom est un cauchemar !

Une fois le programme installé et configuré, on le lance ainsi :

Si on fait tourner U-Boot en RAM, on obtient bien notre sortie terminale. On doit ensuite appeler loady. Pour envoyer un fichier avec Minicom, il faut faire 'Ctrl+A', puis appuyer sur 'S' et choisir ymodem. Ensuite, avec les flèches on place le curseur sur Goto et on copie le chemin de notre fichier (/home/jfduval/Desktop/u-boot-1.1.6-2008R1.5_Giga/ dans mon cas) puis on met le curseur sur Okay et on appui sur Enter.

Bien que la « fenêtre » de transfert Ymodem apparaissait bien, je n'avais aucun signe de fonctionnement, outre la DEL de réception du FT232 qui clignotait une fois aux quelques secondes. Arrêter la commande m'a donné plus d'informations, Minicom avait échoué une vingtaine de tentatives de connexion. Après une courte recherche sur Google, j'ai trouvé un site qui expliquait mon problème. J'ai suivi leurs instructions et j'ai installé lrzsz. Une fois ce programme installé, mon port série est devenu fou, il y avait un transfert incessant de données plus ou moins lisibles... Après avoir redémarré mon système, le problème était réglé et Minicom permet le transfert d'une image.

Voici à quoi ressemble la « fenêtre » d'un transfert réussi :

Après avoir appuyé sur une touche, on peut lire :

Bref, le transfert semble avoir bien fonctionné. Dans la section Écrire l'image U-Boot en Flash je décris quelques essais qui permettent de confirmer le bon transfert des fichiers.

Utiliser U-Boot : quelques commandes

Voici quelques commandes très utiles :

bfin-giga> help : Affiche toutes les commandes incluses dans votre version de U-Boot. Pour en ajouter/enlever, il suffit de modifier bf532-giga2.h en se basant sur le Readme.

bfin-giga> bdinfo : Affiche les propriétés du système (fréquences, versions, baudrate, etc.)

bfin-giga> eeprom info : Informations sur la Flash. C'est dans ce mode qu'on peut transformer une Flash Atmel en mode Puissance de 2. Note : dans votre version uniquement, mon code n'est pas encore inclus dans le release U-Boot.

bfin-giga> md.b : Memory Display. Exemple : md.b 0x1000 0x1000 affiche la RAM de l'adresse 0x1000 et 0x1000 de long. md.b StartAdress Length

bfin-giga> mw.b : Memory Write. Exemple : mw.b 0x1000000 0xFF 0x10000 écrit des 0xFF à l'adresse 0x1000000 pendant 0x10000. mw.b StartAdress Value Length.

bfin-giga> eeprom write : Eeprom Write. Exemple : eeprom write 0x1000000 0x0 0xD5B0 écrit l'adresse 0x1000000 de la RAM dans la Flash à l'adresse 0 pendant 0xD5B0 bytes. eeprom write RamStartAddress FlashStartAddress Length

bfin-giga> eeprom read : Eeprom Read. Exemple : eeprom read 0x1000000 0x0 0xD5B0 écrit à l'adresse 0x1000000 de la RAM le contenu de la Flash à l'adresse 0 pendant 0xD5B0 bytes. eeprom read RamStartAddress FlashStartAddress Length

bfin-giga> loady : Load file with Y-Modem Protocol. Exemple : envoyer la commande loady, puis, dans Hyperterminal Transfert > Send File... > Filename : u-boot.ldr Protocol : Ymodem > OK. Par défaut, le fichier sera chargé en RAM à l'adresse 0x1000000. Il ne reste ensuite qu'à écrire cette image à l'adresse 0 de la Flash pour booter dessus.

Booter sur une Flash SPI

Source principale d'informations : les section Serial NOR Flash and U-Boot et Loading Files With U-Boot via The Serial Port du Wiki U-Boot

La mémoire Flash de la carte Gigamodule est une Atmel Dataflash AT45DB321D de 32Mbit. On veut pouvoir booter depuis celle-ci. La première étape, en se référant à la datasheet du BF532, est de configurer le bon boot-mode. Pour booter sur un esclave SPI, il faut se placer en mode 11 (sur le Gigamodule, cela équivaut à enlever les deux jumpers).

On charge ensuite U-Boot en RAM et on le fait tourner (voir Charger U-Boot en mémoire). On peut confirmer que notre mémoire est bien détectée avec la commande eeprom info. On va donc charger une image de U-Boot dans la RAM.

Charger l'image U-Boot en RAM

Tel qu'expliqué ailleurs dans ce document, j'ai eu certains problèmes avec le transfert de fichiers avec le protocole Kermit et Hyperterminal. Je n'ai pas cherché à trouver si c'était U-Boot ou Hyperterminal qui causait le problème car utiliser Ymodem m'a permis de transmettre correctement mon image, réglant ainsi mon problème. Dans le terminal, on appelle la commande loady :

Dans notre programme de terminal, on envoie notre fichier u-boot.ldr par le protocole Ymodem :

Le transfert est un succès. La taille est 0xE334 : nous utiliserons cette valeur bientôt. L'image de U-Boot est donc présente en RAM, à l'adresse 0x01000000. Il est possible de vérifier facilement la réussite de cette étape en affichant le contenu de la RAM :

bfin-giga>md.b 0x1000000 0x100 01000000: 00 80 a0 ff 2c 03 00 00 08 00 66 01 c0 05 50 01 ....,.....f...P. 01000010: 51 01 52 01 53 01 58 01 59 01 5a 01 5b 01 5c 01 Q.R.S.X.Y.Z.[.\. 01000020: 5d 01 5e 01 5f 01 54 01 55 01 56 01 57 01 60 01 ].^._.T.U.V.W.`. 01000030: 61 01 4a e1 c0 ff 62 01 63 01 0a e1 24 04 50 95 a.J...b.c...$.P. 01000040: 21 e1 e1 00 00 48 49 4f 00 60 08 07 49 e1 c0 ff !....HIO.`..I... 01000050: 08 60 10 97 09 e1 0c 04 18 60 08 97 30 00 00 00 .`.......`..0... 01000060: 00 00 24 00 40 00 01 0c 1c 14 48 95 38 4a 08 97 ..$.@.....H.8J.. 01000070: 30 00 00 00 00 00 24 00 40 00 08 61 e2 6e 10 97 0.....$.@..a.n.. 01000080: 00 60 22 6c 10 97 30 00 00 00 00 00 24 00 40 00 .`"l..0.....$.@. 01000090: 48 95 38 4c 08 97 30 00 00 00 00 00 24 00 40 00 H.8L..0.....$.@. 010000a0: 4a e1 c0 ff 20 e1 53 00 0a e1 00 04 10 97 4a e1 J... .S.......J. 010000b0: c0 ff 0a e1 14 04 50 95 30 48 fa 1f 4a e1 c0 ff ......P.0H..J... 010000c0: 0a e1 14 05 20 60 10 97 4a e1 c0 ff 20 e1 42 00 .... `..J... .B. 010000d0: 0a e1 00 04 10 97 4a e1 c0 ff 0a e1 14 04 50 95 ......J.......P. 010000e0: 30 48 fa 1f 4a e1 c0 ff 0a e1 24 01 08 60 10 93 0H..J.....$..`.. 010000f0: 4a e1 c0 ff 20 e1 4c 00 0a e1 00 04 10 97 4a e1 J... .L.......J.

Que signifient ces informations ? Ce qu'on vient de lire est l'en-tête de l'image U-Boot, un header de 10 octets, ainsi que les données de l'image. Ce sont les premières données que va lire le Blackfin quand il va booter sur la Flash SPI. Selon les informations de l'Application Note EE-240 ADSP-BF533 Blackfin® Booting Process on peut découper le paquet des 10 premiers octets ainsi : [00 80 a0 ff] [2c 03 00 00] [08 00]. Cela représente en fait [Adress (4bytes)][Count (4bytes)][Flag (2bytes)]. Si vous allez voir dans le datasheet l'organisation mémoire du BF532 vous constaterez que 0xFFA08000 correspond au début de la mémoire instructions : on va donc transférer les données à la bonne place pour que le code s'exécute.

Si vous disposez d'un appareil capable d'analyser un bus SPI, comme un oscilloscope Agilent MSO6034A avec les bonnes options, vous pourrez lire ce header de 10 bytes quand le Blackfin démarre, confirmant ainsi le bon fonctionnement de votre système.

Écrire l'image U-Boot en Flash

On va maintenant écrire dans la Flash SPI l'image de U-Boot que l'on vient de charger en RAM. Pour ce faire, utilise la fonction eeprom write :

Et voilà, l'image est transférée dans la mémoire Flash. À condition que notre boot-mode soit bien 11, le Blackfin devrait maintenant booter de sa Flash sans problème.

Vous voulez confirmer que le transfert s'est bien déroulé, que l'image est bien écrite dans la Flash ? On commence par effacer (bref, à remplacer par une valeur connue) une portion de la RAM, puis on l'affiche pour s'assurer que c'est correct :

bfin-giga>mw.b 0x1000000 0xFD 0x1000 bfin-giga>md.b 0x1000000 0x100 01000000: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd ................ 01000010: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd ................ 01000020: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd ................ 01000030: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd ................ 01000040: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd ................ 01000050: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd ................ 01000060: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd ................ 01000070: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd ................ 01000080: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd ................ 01000090: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd ................ 010000a0: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd ................ 010000b0: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd ................ 010000c0: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd ................ 010000d0: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd ................ 010000e0: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd ................ 010000f0: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd ................ bfin-giga>

On constate bien que toutes les données valent 0xFD. On va maintenant lire la Flash et écrire ce qu'on lit par-dessus tous ces 0xFD :

bfin-giga>eeprom read 0x1000000 0x0 0x100 EEPROM @0x0 read: addr 01000000 off 0000 count 256 ... done bfin-giga>md.b 0x1000000 0x100 01000000: 00 80 a0 ff 2c 03 00 00 08 00 66 01 c0 05 50 01 ....,.....f...P. 01000010: 51 01 52 01 53 01 58 01 59 01 5a 01 5b 01 5c 01 Q.R.S.X.Y.Z.[.\. 01000020: 5d 01 5e 01 5f 01 54 01 55 01 56 01 57 01 60 01 ].^._.T.U.V.W.`. 01000030: 61 01 4a e1 c0 ff 62 01 63 01 0a e1 24 04 50 95 a.J...b.c...$.P. 01000040: 21 e1 e1 00 00 48 49 4f 00 60 08 07 49 e1 c0 ff !....HIO.`..I... 01000050: 08 60 10 97 09 e1 0c 04 18 60 08 97 30 00 00 00 .`.......`..0... 01000060: 00 00 24 00 40 00 01 0c 1c 14 48 95 38 4a 08 97 ..$.@.....H.8J.. 01000070: 30 00 00 00 00 00 24 00 40 00 08 61 e2 6e 10 97 0.....$.@..a.n.. 01000080: 00 60 22 6c 10 97 30 00 00 00 00 00 24 00 40 00 .`"l..0.....$.@. 01000090: 48 95 38 4c 08 97 30 00 00 00 00 00 24 00 40 00 H.8L..0.....$.@. 010000a0: 4a e1 c0 ff 20 e1 53 00 0a e1 00 04 10 97 4a e1 J... .S.......J. 010000b0: c0 ff 0a e1 14 04 50 95 30 48 fa 1f 4a e1 c0 ff ......P.0H..J... 010000c0: 0a e1 14 05 20 60 10 97 4a e1 c0 ff 20 e1 42 00 .... `..J... .B. 010000d0: 0a e1 00 04 10 97 4a e1 c0 ff 0a e1 14 04 50 95 ......J.......P. 010000e0: 30 48 fa 1f 4a e1 c0 ff 0a e1 24 01 08 60 10 93 0H..J.....$..`.. 010000f0: 4a e1 c0 ff 20 e1 4c 00 0a e1 00 04 10 97 4a e1 J... .L.......J. bfin-giga>

On constate que ce sont les même valeurs que l'image, donc l'écriture et la lecture sont un succès.

Déboguer avec le JTAG

Source principale d'informations : le ICEBear Manual (PDF), section Insight Debugger

Jusqu'à date nous avons utilisé notre ICEBear et Insight dans l'unique but de charger nos programmes en RAM. Une autre utilisation, tout aussi importante, est le débogage. J'utilise un script GDB que j'ai nommé cfg2.gdbscript :

Si vous le comparez à cfg.gdbinit, vous constaterez que la version 2 ne charge pas le programme. Pour déboguer ma version de U-Boot qui s'exécute depuis la Flash SPI, j'ai lancé Insight dans le bon dossier :

root@jfduval-desktop:/home/jfduval/Desktop# cd u-boot-1.1.6-2008R1.5_Giga/ root@jfduval-desktop:/home/jfduval/Desktop/u-boot-1.1.6-2008R1.5_Giga# /usr/bin/bfin-elf-insight u-boot.ldr <cadre> Maintenant qu'Insight est lancé, on peut faire File > Source... > cfg2.gdbinit > Open. Quand les icônes du débogueur deviendront colorés, c'est prêt à être utilisé. On fait Open > u-boot > Ok. On peut maintenant faire fonctionner le programme en pas-à-pas, le faire exécuter jusqu'à la fin, le mettre en pause, etc. Il est possible d'utiliser la console d'Insight et d'appeler des fonctions de débogage sous forme de scripts. Ainsi, appeler {dump_ebiu} vous affichera les données de configuration de la RAM, {dump_pll} vous informera de vos diviseurs et multiplicateurs de fréquence. Pour connaître toutes les possibilités de débogage, je vous conseil de consulter le ICEBear Manual et de lire le code des scripts du dossier {/gdbscripts/}. Vous pourrez alors savoir où votre programme bloque, quelle est la valeur de vos registres, etc. {{{Résultats}}} Le travail présenté dans ce document a été réalisé lors de mon stage à l'[IntRoLab->http://introlab.gel.usherbrooke.ca/], le laboratoire de recherche en robotique mobile et intelligence artificielle de l'Université de Sherbrooke. Mon but était d'aider l'équipe [Robot22] à réaliser leur projet en les avançant sur la portion Blackfin. J'ai donc commencé par analyser et modifier les schémas de la carte Gigamodule. J'ai ensuite conçu le circuit imprimé de cette carte, l'ai assemblé et testé. La suite de mon mandat était de charger U-Boot dans la flash et ensuite d'y mettre µCLinux. Ma recherche d'outils m'a conduit chez Section5 car la combinaison ICEBear et BFLoader répondait à mon besoin de trouver un outil simple, complet et économique pour programmer la carte. Tel qu'expliqué au fil de ce texte, mon parcours n'a pas été toujours simple et linéaire. J'ai vite constaté que la carte Gigamodule était subtilement différente de la majorité des autres cartes Blackfin et que mes outils n'étaient pas tous compatibles entre eux. Ainsi, j'ai passé un temps considérable à modifier mes outils, les exemples de codes et les programmes à utiliser pour les faire fonctionner sur un BF532 et le Gigamodule. Au final, je n'ai pas atteint le point d'avoir U-Boot parfaitement fonctionnel sur le Blackfin, même si je suis très près du but. Comme vous avez pu le constater plus haut dans ce document, j'ai réussi à faire tourner U-Boot en RAM avec succès. Ce fut une grande satisfaction pour moi après tous les efforts déployés! Par contre, même si je peux écrire avec succès la Flash et que je sais que le Blackfin la lit au départ (confirmé à l'analyseur logique), je n'obtiens pas de fonctionnement. Au démarrage, j'obtiens cela sur le terminal: <cadre> Ö ƒ])äFIN>

Ce qui ressemble à du garbage et à un prompt. Il me semble évident que la solution est tout prêt et que j'ai probablement une erreur stupide dans mon travail qui conduit à ce résultat. Par contre, j'ai du travailler sur d'autres tâches plus importantes et mon travail est donc resté à ce point.

Observations et pistes de solution possibles

Bien que je n'ai pas trouvé la solution exacte à mon problème, j'ai plusieurs pistes de solution en tête.

Observation 1 : Lorsque je débogue avec le JTAG le programme démarré depuis la Flash, il se rend jusqu'à la ligne 204 de serial.h, où il reste éternellement. J'ai mon output bidon entre l'initialisation et cette fameuse ligne 204.

Observation 2 : Autant dans mon script GDB que dans U-Boot, j'ai SDGCTL = 0x809110CD. Par contre, un dump_ebiu me retourne 0x80111OCD. Est-ce que ma configuration serait mauvaise ?

Soupçon 1 : Je soupçonne le ICEBear d'initialiser certains registres différemment de U-Boot, ce qui expliquerait que si je charge le programme en RAM il s'exécute correctement.

Soupçon 2 : Après avoir consulté la documentation du BlackStamp, il semble qu'un problème de mauvaise initialisation de la SDRAM cause exactement ce problème. Leur procédure n'est pas adaptée à notre version de U-Boot, il faudra enquêter. http://blackfin.uclinux.org/gf/project/blackstamp/frs/

Piste de solution 1 : Corriger l'erreur de SDGCTL (confirmer les valeurs, s'assurer qu'elles soient programmées correctement).

Piste de solution 2 : Tester à plus basse fréquence pour diminuer de potentiels problèmes liés au PCB.

Piste de solution 3 : Travailler avec la dernière version de U-Boot, qui incorpore un nouveau système de gestion des Flash SPI.

Pour le moment, l'équipe [Robot22] a le projet entre les mains et devrait surpasser cette erreur. Quand la solution sera trouvée, elle sera ajoutée à ce document. Si vous croyez détenir la solution ou une explication à ces problèmes, je vous serais très reconnaissant de me contacter.

Sommaire de mon expérience

Mon parcours aura été semé d'embûches tout au long de mon développement. Premièrement, ma connaissance limitée de l'environnement Linux et de l'usage de la console m'a fortement ralenti, surtout lorsque j'étais incapable de suivre les exemples trouvés en ligne pour cause de problèmes de dépendances ou d'incompatibilités entre les différentes saveurs et versions de Linux. Mon environnement de développement initial, composé de 2 PC et de trois systèmes d'exploitation n'était en aucun point optimal, mais il m'a permis de progresser. Ce n'est que quand j'ai commencé cette documentation que j'ai réalisé plusieurs de mes erreurs et que j'ai appris à les surmonter. Je ne vous cacherai pas que de tout faire fonctionner sur Ubuntu est plus compliqué que sur Debian Etch mais les avantages compensent : un seul système, plus rapide, plus stable et moderne, moins de problèmes d'échanges de périphériques et simplicité accrue. Il existe une grande quantité de documentation en ligne qui couvre la majorité des sujets traités dans ce document. Par contre, dès que l'on utilise du matériel non standard, les informations sont rares ou inexistantes. J'espère qu'avec cette documentation je pourrai aider quelques personnes, qui seraient dans une situation similaire à la mienne, à progresser plus rapidement. Cette expérience aura été très formatrice pour moi. Bien que je n'ai pas atteint tout à fais mon but, j'ai appris beaucoup sur le développement sous Linux, sur l'environnement Blackfin et sur les projets open-source U-Boot et µCLinux.

Annexe A : Sources

Afin de pouvoir d'analyser les modifications que j'ai effectuées aux sources des différents programmes modifiés, il vous est possible des les télécharger aux adresses suivantes :

Répertoire principal

Sources modifiés BFLoader

Sources modifiés Blinky

Sources modifiés U-Boot

Outil de conversion Atmel

Pour comparer mes sources modifiés aux originaux, vous pouvez installer l'excellent logiciel Diffuse qui vous permet de voir deux fichiers et de comparer les différences facilement :

Annexe B : Documentation et liens

IntRoLab

Documentation JFDuval – IntRoLab :

Cet article complet sur le web

Cet article complet en PDF

Sources

Outils Section5 :

Site principal Section5

Forum Section5

Manuel ICEBear

U-Boot et µCLinux :

Readme U-Boot :. .../u-boot-1.1.6-2008R1.5/README

µCLinux

Getting started with µCLinux

Divers :

Blackfin

Datasheet BF532

Manuel BF532

Projets et produits :

Annexe C : Remerciements

Je tiens à remercier en particulier trois personnes qui m'ont aidé dans mon développement et qui m'ont permis de progresser vers mon but.

Dominic Létourneau d'IntRoLab, pour son aide et ses conseils
Martin Strubel de Section5 pour son support par forum et courriel
Mike Frysinger pour ses réponses sur les forums de U-Boot

Étude comparative des algorithmes de connexité appliqués à la détection de régions dans une image

Pierre-Luc Bacon — 2009-03-15T00:45:32Z

Ce projet a été réalisé en 2008 alors que développant l'algo de vision pour le robot, je réalisais également un travail d'analyse pour tenter de déterminer la meilleure approche à adopter pour ce problème. Les résultats de mes recherches ont été rassemblés dans ce document qui a été proposé en "travail de fin d'études" au CÉGEP.

Ce document présente les résultats d'une étude comparative visant à déterminer l'efficacité d'une implantation réelle d'algorithmes servant à l'extraction des régions d'intérêt d'après les composants connectés d'une image. Nous nous intéressons plus en détails aux techniques développées par Bruce et al. (2000) ainsi que (Wu et al., 2005) qui sont toutes deux caractérisées par une complexité en temps linéaire O(n). Une approche théorique permettra d'abord de préciser les caractéristiques théoriques de quelques techniques développées pour solutionner ce problème alors que des essais pratiques metteront ensuite en lumière leur temps d'exécution.

L'article en question est téléchargeable au bas de cette page.

Étiquetage des composants connectés et segmentation des couleurs avec CMVision 1.2

Pierre-Luc Bacon — 2009-03-15T00:18:20Z

Toute équipe qui doit embarquer une caméra sur son robot doit le faire à tout coup. Implanter un algorithme effiace d'étiquetage des régions de couleurs (aka "connected component labeling") est souvent une étape complexe qui, si mal réalisée peu entraîner des délais de traitement beaucoup trop important. Un choix s'impose alors : tenter une solution "maison" ou utiliser une solution libre déjà disponible.

OpenCV est souvent choisi dans ce cas. Bien que très perfectionnée, OpenCV a peut-être trop à offrir quand vient le temps d'implanter une solution simple pour un système aux ressources limitées.

CMVision (c++) s'avère être un choix tout indiqué pour répondre au besoin précis d'étiquetage des régions de couleurs. Réalisé par des étudiants du MIT dans le cadre de Robocup, cette librairie utilise plusieurs algorithmes performants pour réaliser cette opération. Les couleurs sont d'abord détectées par un algorithme de seuillage ordinaire à la différence près qu'une astuce permet de déterminer si un pixel appartient à une classe de couleur (jusqu'à 32) en une seule opération binaire plutôt qu'en procédant à 6 comparaisons logiques requises par l'approche "naïve". L'image seuillée est ensuite encodée en séries de pixels adjacents et analysée dans un algorithme de type Union- Find implanté sous forme de listes chaînées.

Utilisation

Un seul constructeur est fourni dans la version 1.2 pour un objet de type "CMVision".

L'utilisateur devra ensuite fournir d'autres paramètres d'initialisation manuellement :

Ces méthodes sont celles qui devront le plus souvent être appelées. loadOptions() prend en argument le nom d'un fichier qui contient une liste de seuils pour chacune des couleurs à détecter. Il est formaté comme suit :

La section "colors" contient le triplet RGB associé à la couleur (utile pour le debugging ou pour la partie GUI), la valeur "merge" (non utilisée ici), et un identifiant texte. La section threshold contient quand à elle les seuils min et max pour chacun des 3 canaux de couleur.

Une fois ces quelques méthodes executées, nous sommes déjà en mesure d'effectuer le traitement sur l'image :

Cette méthode est surchargée pour supporter plusieurs arrangement en mémoire possibles de l'image :

où image_pixel est un format pré-défini dans cmvision.h qui, selon le "define" utilisé au moment de la compilation, sera défini comme une de ces structures :

Dans la plupart des applications, il sera plus simple de fournir une image de type "unsigned" où chaque pixel est défini un après l'autre par 3 valeurs de canaux consécutives.

Si l'image contient un certains nombre de régions de couleurs tel que précisé dans le fichier de configuration, getRegions() permettra de les acquérir via un pointeur de type "region".

où color_id et le numéro associé à la couleur définie dans le fichier de configuration (la numération est automatique par ordre de définition).

indiquera le nombre de régions détectées.

Le type région est défini ainsi :

Connaissant le nombre de couleurs ainsi que le nombre de régions d'après numRegions(). nous pourrions alors exécuter une boucle pour afficher les informations de la structure "region" pour chaque composant détecté.

Finalement,

peut s'avérer utile pour visualiser les pixels détectés dans la phase de seuillage. Un fichier ppm sera alors créé où chaque pixel prendra la valeur de son identifiant de couleur.

Il n'existe pas de documentation officielle pour la librairie CMVision-1.2. Ainsi, les méthodes présentées ici ne représentent pas réellement toutes celles disponibles. La lecture de cmvision.h suffira bien souvent pour comprendre le fonctionnement de ces autres méthodes.

Exemple

L'exemple suivant utilise les méthodes décrites plus haut de CMVision-1.2, la classe VideoInput, ainsi que les librairies SDL et SDL-gfx (sudo apt-get install libsdl-gfx1.2-dev).

Une fenêtre SDL affichera en temps réel les images capturées par la caméra, les pixels seuillés, et les régions d'intérêts détectées.

Le code de ce programme est disponible au bas de cette page. Pour le compiler, il suffira d'exécuter "make" dans le dossier créé après décompression de l'archive.

Capture d'images avec Video For Linux 2

Pierre-Luc Bacon — 2009-03-14T19:19:21Z

Bien qu'encore populaire, Video For Linux 1 a fait place à V4L2 il y a bien longtemps alors que le développement de Linux en était à la version 2.5. S'il existe un obstacle à l'adoption de la nouvelle API chez les développeurs, c'est peut-être en raison de sa complexité. Certes il existe une documentation officielle qui détaile le fonctionnement de chacune des fonctions mais celle-ci aide peu à saisir l'idée générale d'interaction entre elles.

Heureusement, il nous est fourni le fichier capture.c qui fait office d'exemple d'implantation. Le code est bien organisé et peut être utilisé presque sur-le-champs dans n'importe quelle application. Toutefois, un peu de travail reste à faire pour mieux l'intégrer dans une application plus complexe.

Le code suivant a été réalisé lors de notre participation à Eurobot 2008 et visait à obtenir un code simple qui permettrait d'expérimenter et de déployer rapidement des solutions de traitement d'image.

Prenez note que, bien que fonctionnel, ce code n'a pas la flexibilité requise pour fonctionner avec n'importe quel type de matériel. Nous utilisions la caméra Quickcam pro 4000 de Logitech à cette occasion et vous retrouverez quelques valeurs codées "en dur" parmis les lignes.

Survol des fonctions

La classe VideoInput peut être initialisée de deux manières. Par exemple :

Crée un objeet VideoInput nommé "vdo" qui tentera d'accéder au périphérique V4L2 situé en "/dev/video0" avec comme valeurs par défaut : largeur = 320, hauteur = 240 et format de couleur YU12 (fourcc).

Ce premier constructeur est équivalent au second appelé de cette manière :

Pour saisir une image, il suffit seulement d'appeler la fonction "grab" :

Aucune valeur n'est retournée par cette fonction, mais une image est placée dans le buffer à ce moment. Celui-ci peut être obtenu par :

Prenez note que, par défaut, chaque appel à la fonction grab() fait aussi appel à une fonction de conversion YUV420p vers RGB "standard". Pour changer cette opération, il faudra adapter la fonction (privée) "ReadFrame".

Il était envisagé de faire fournir un mécanisme de conversion automatique "de" et "vers" n'importe quel format d'image. Toutefois, la tâche étant colossale, le projet n'a pas été entamé au sein de code. Une fonctionnalité de la sorte serait la pièce manquante pour entâmer le développement d'une librarie dédiée à la capture d'images pour nos robots. Le temps se faisant précieux, les prioritées étant ailleurs, ceci ne verra pas le jours prochainement... Une librairie simple, peu encombrante et flexible, est peut-être ce qui manque le plus actuellement. Libwebcam (libre), apparue récemment des laboratoires de Logitech, pourrait répondre à ce besoin mais elle offre seulement des fonctionalités UVC.

Si vous voulez supporter V4L1 dans votre application, Libfg est probablement ce qui se rapproche le plus de ces objectifs et devrait servir de modèle d'inspiration dans un projet du genre. Et pourquoi pas porter libfg à V4L2 ? Des volontaires ?

Projet BOTUS : Robot d'exploration

Jean-François Duval — 2009-01-24T22:14:16Z

BOTUS est un robot d'exploration de milieux difficile. Le robot dispose d'une caméra et de plusieurs capteurs pour représenter son environnement à l'opérateur qui le contrôle. Du coté PC, une interface graphique présente la réalité perçue par le robot. Le contrôle des déplacements se fait avec une manette tandis que l'orientation de la caméra se fait par commande vocale.

Une image vaut mille mots...

... donc cet article commence par un vidéo du robot complété et quelques images !

Pour une description des différentes parties du robot, vous pouvez consulter l'Instructable de Simon St-Hilaire sur notre projet : http://www.instructables.com/id/BOTUS-Project

Électronique

Carte Colibri 101 :

Développement du prototype

Modélisation

Robot de test

Prototype électronique

Construction de Botus (1)

Construction de Botus (2)

Description "scolaire"

Contexte :

La session S2 vient de débuter, avec un nouveau projet pour le trimestre d'hiver. Voici les exigences du corps professorale.

« L'équipe professorale de S2 vous invite à participer à la conception d'un système hybride de commande vocale pour un logiciel. Sommairement, le système à concevoir est un logiciel d'application avec interface graphique interactive contrôlé par un module de reconnaissance de commandes vocales simples. »

Description générale :

Général :

Le projet consiste en la conception d'un robot d'exploration. Ce robot, nommé Botus, aura de nombreuses fonctionnalités permettant la navigation en terrain dangereux ou inaccessible. Les commandes données au robot seront transmises par l'intermédiaire d'un contrôleur analogique et à l'aide d'un système de traitement de la voix. Le robot sera contrôlé à distance à l'aide d'un modem double sens, connecté à l'ordinateur.

Fonctions annexes du robot :

Déplacement à l'aide de roues contrôlées indépendamment.
Caméra amovible dont le flux vidéo apparaît sur l'interface graphique.
Pince contrôlée, située à l'avant du robot, permettant une saisie d'objets.
Télémètres infrarouges détectant la distance des objets en périphérie du robot.

Composantes du robot :

Le robot se déplace sur deux roues ainsi qu'un patin stabilisateur. Cette fonction est contrôlée avec les manches à balai du contrôleur analogique. La pince motorisée est commandée à l'aide des interrupteurs du contrôleur analogique. Une caméra sans fil est placée sur le dessus du robot et est contrôlée par deux servomoteurs. Cette disposition permet d'obtenir une vision de 180o sur plusieurs angles. C'est alors que l'utilisation de la commande vocale s'avère légitime puisque les deux mains de l'utilisateur sont utilisées. Ainsi, les commandes vocales sont traitées afin de permettre une navigation dans les menus de l'interface graphique ainsi que pour la motion de la caméra.

Interface graphique :

L'interface graphique affiche, en plus du flux vidéo, des informations diverses telles que l'état des piles du robot, une représentation graphique de la position du robot relative aux obstacles, une boîte affichant les commandes de communication robot-PC, des témoins graphiques associés aux phonèmes reconnus et une représentation 2-D de l'environnement dans lequel se trouve le robot.

Crédits :

Ce projet est développé par l'équipe P8, composée de :

Équipe P8 (ordre alphabétique)

Alexandre Bolduc

Louis-Philippe Brault

Vincent Chouinard

Jean-François Duval

Sébastien Gagnon

Simon Marcoux

Eugène Morin

Guillaume Plourde

Simon St-Hilaire

Fichiers de développement :

Vous pouvez cliquer sur les vignettes en bas de l'article pour télécharger le projet (Microchip C18 + Cadsoft Eagle 5.0).

Conception mécanique 2008

Stéphan Couture — 2008-07-10T21:20:46Z

Plusieurs critères furent considérés lors de la conception mécanique du robot. Évidemment, les restrictions imposées par les règlements du concours venaient en tête de liste. L'expérience de l'année dernière a également fournit une ligne directrice aux concepteurs. Plusieurs problèmes simples purent donc être évités, ceci amenant un développement plus rapide et efficace.

Le document PDF joint présente un résumé de mon travail pour Eurobot 2008 : description de la conception et réalisation mécanique.

Conception électronique et logicielle [Eurobot OPEN 2008]

Jean-François Duval — 2008-07-10T17:01:08Z

Cette page présente le système électronique du robot Eurobot 2008 de l'AQRA.

Schéma de haut niveau de l'organisation électronique du robot

Cartes du CoreEB2k8

Le CoreEB2k8 est le cœur du robot. C'est l'unité de contrôle principale, qui regroupe toutes les cartes logiques. La communication avec les cartes de puissance se fait toujours par le biais d'un bus de communication I2C ou de lignes logiques dédiées.

Carte Mère et Interface Homme-Machine

La carte Mère est le cerveau principal du robot. Elle contient un dsPIC20F4013 qui agit comme gestionnaire des comportements du robot. Toutes les stratégies de haut niveau du fonctionnement du robot y sont codées. Entre autre en étant le maître du bus I2C, c'est cette carte qui contrôle et coordonne toutes les autres cartes. Sur la carte est aussi présent un petit microcontrôleur PIC18F1320 dédié à la gestion du Timer90s, la minuterie qui gère le temps lors d'un match. La carte mère supporte directement la carte Interface Homme-Machine, qui n'est qu'un support pour son interface avec l'usager. Les boutons, l'afficheur LCD de 4 lignes de 20 caractères et les afficheurs 7 segments à dels présents servent à la préparation des matchs et au débogage. En situation normale de match, suite à sa mise sous tension elle demande à l'opérateur quelle stratégie adopter puis elle attend le signal de départ. Dès que le signal est reçu, elle démarre la minuterie de 90 secondes et commence son cycle de fonctionnement : questionnements des capteurs de position, questionnement de la caméra par le biais de l'ordinateur embarqué, calcul des actions à effectuer et mouvements.

Carte Actionneurs et Barillet

Cette carte est dédiée à la manipulation des balles, par le biais de quelques capteurs et plusieurs actionneurs. Deux servos-moteurs1, dont un fonctionnant en miroir2, permettent aux pinces de saisir les balles dans les distributeurs. La turbine permet de les aspirer dans le barillet. Ce barillet, mis en mouvement par un puissant moteur pas-à-pas, peut ensuite tourner et se positionner précisément sur l'entrée des balles, sur le canon ou sur le capteur de couleur. Lorsqu'une balle est mise en position du canon, un servomoteur, le bloqueur, change de position pour libérer l'accès aux roulettes de propulsion. Un autre servomoteur, le pousseur, frappe la balle et l'envoie entre les deux roues de mousse qui l'expédieront dans un conteneur.

Capteurs

Le robot évolue dans un environnement relativement complexe, en présence d'un autre robot et de plusieurs éléments de jeu. Afin de pouvoir effectuer les actions voulues, il doit éviter l'adversaire, doit pouvoir déterminer la couleur des balles et où les placer. Plusieurs capteurs permettent de connaitre au mieux possible les obstacles dans l'entourage du robot. Pour ce faire, plusieurs télémètres infrarouges sont utilisés. Ils ont une sortie en tension liée à la distance. La conversion analogique à numérique ce fait par le microcontrôleur et une table de conversion nous donne une distance en mm. Un télémètre ultrason à l'avant du robot permet une détection plus fiable : il n'est pas handicapé par des surfaces très transparentes ou miroir. Quelques autres capteurs simples sont utilisés en plus, afin d'obtenir un maximum d'informations. La carte peut aussi contrôler une tourelle rotative (pas utilisée pour le moment) qui permet de s'orienter plus facilement sur le but. Toutes les données de ces capteurs sont traitées sur la carte Capteurs et la carte Mère peut les lire par le bus I2C au besoin.

Alimentation

Alimentation fournit les tensions nécessaires aux cartes du CoreEB2k8 et à certaines cartes externes. Les circuits de logique nécessitent un 5V bien régulé. Les servomoteurs fonctionnent aussi à 5V, mais en consommant et en parasitant beaucoup, ce qui rend difficile la cohabitation sur une même alimentation. En entrée de la carte Alimentation se trouvent les deux accumulateurs 9.6V. Autant du côté propre que du côté sale, le 9.6V est convertit par de petites alimentations à découpage1 en 5V. Il circule donc dans le robot des alimentations propres (9.6 et 5V) et sales (9.6 et 5V) qui proviennent de la carte Alimentations. Notons que la masse est commune pour les tensions sales et l'accumulateur 36V.

Back

La carte Back est simplement le support du BusEB2k8. Toutes les autres cartes s'enfichent sur elle.

Cartes externes

Plusieurs cartes sont externes au CoreEB2k8. Ce sont principalement des interfaces de puissance pour les actionneurs ou des adaptateurs de signaux.

PIMD3.1

PIMD est un acronyme de Powerful and Intelligent Motor Driver. Les cartes PIMD sont une petite série de cartes développées pour Eurobot. La version actuelle, la 3.1, permet le contrôle en puissance d'un moteur allant jusqu'à 36V 3A (6A en pointe). Elle comporte un microcontrôleur dont la tâche est l'asservissement de vitesse et la génération de profils (accélération positive et négative, courbes trapézoïdales, etc.) de vitesse. Reliée au bus I2C, elle reçoit des ordres de haut niveau, tel que « Accélère jusqu'à 560mm/s » et pilote le moteur en conséquence. Deux de ces cartes sont utilisées dans le robot, une pour chaque moteur de propulsion. L'information de vitesse provient des génératrices des moteurs.

Power Stepper

Le barillet est un dispositif mécanique composé de 5 tubes montés sur un disque rotatif. Il permet la collecte, le tri et l'éjection des balles. Il doit donc être positionné précisément. Un puissant moteur pas-à-pas le fait bouger. La carte Power Stepper comprend de la logique de contrôle et une interface de puissance. Elle permet de contrôler en pas entier ou en demis pas des moteurs bipolaires consommant jusqu'à 4A par phase.

Canon

Le canon sert à l'éjection des balles. Il est composé de deux moteurs CC. La distance du tir dépend de la vitesse de ces moteurs. La carte canon est simplement une interface de puissance qui achemine le PWM provenant de la carte Actionneurs, par le biais de drivers de Mosfets1 et de Mosfets de puissance, aux moteurs.

Turbine

La turbine est utilisée pour faire entrer les balles dans le barillet. Elle est composée d'un moteur CC et d'un ventilateur particulier. La puissance électrique consommée est considérable : de l'ordre de la dizaine d'ampères sous 15.6V. La tension moyenne de 15.6V, nominale à ce moteur, est obtenue par la batterie 36V et du PWM. La carte Turbine est l'interface de puissance, contrôlant le moteur par le biais d'un gros Mosfet.

Adapteur de couleur

Si un objet nous semble rouge, c'est car il reflète le rouge. Un objet semble blanc quand il reflète bien toutes les couleurs. La lecture de couleur est faite par un capteur maison basé sur ce principe. La tête de lecture est composée d'une diode électroluminescente RGB1 et d'un petit circuit intégré comportant une photodiode et son convertisseur courant tension. La balle est éclairée successivement par du bleu et du rouge, les sources étant pulsées à 1kHz. Chaque couleur de balle absorbe plus ou moins le bleu ou le rouge, ce qui fait que la lecture de tension faite sur le capteur est liée à la couleur. L'excitation à 1kHz, en conjonction avec un filtre passe-haut de quelques centaines de Hertz en sortie du détecteur permet de s'immuniser à la lumière ambiante. Le signal de retour est filtré puis comparé. Un PIC 18F1320 s'occupe de la modulation des sources et du décodage des couleurs. La couleur décodée est envoyée à la carte Actionneurs.

Alim Control

Il est imposé par le règlement que le robot ne doit bouger qu'après le coup d'envoie d'un match et qu'il doit s'immobiliser complètement après 90 secondes. La méthode la plus sécuritaire pour s'assurer que tout s'arrête est de couper l'alimentation. La carte de contrôle de l'alimentation fait donc le lien entre la batterie principale et tous les circuits nécessitant du 36V. Un relais et un bouton d'arrêt d'urgence sont en série : il suffit donc que l'un ou l'autre soir ouvert pour que tout s'arrête. Sur la carte est aussi présent le connecteur de départ, un jack audio utilisé en simple commutateur qui permet à l'opérateur de démarrer le robot à distance.

USB-Serie

Plusieurs des cartes possèdent une sortie pour port série. Comme l'ordinateur portable utilisé ne possède pas de port série, ce petit convertisseur émule un port série depuis un port USB et permet aux différentes cartes d'exporter des données sur un terminal.

Fichiers

Le document PDF joint présente un résumé de mon travail pour Eurobot 2008 : description de la conception électronique et de la programmation embarquée.

Le fichier elec_Eurobot_Open_2k8.zip contient tous les plans électroniques utilisés pour le robot 2008. À ouvrir avec Cadsoft Eagle 4.16r2 ou plus.

Les fichiers sources se trouvent dans CodeEurobot2008.7z.

Tous les dessins et sources fournis sont libre d'usage pour une utilisation non-commerciale.

MPLAB 7.60 sous Linux

Pierre-Luc Bacon — 2007-10-09T02:13:55Z

Si vous êtes à conserver un système Windows que pour utiliser l'environnement de développement natif pour les PIC, il devient vite intéressant d'y trouver une alternative sous Linux. Utiliser une solution de virtualisation est valable, évidemment, mais constitue aussi un gaspille en ressource évitable. Ne reste plus alors que Wine, heureusement, pour demeurer dans le confort de son Linux en tout temps. Voici quelques notes qui permettront d'éviter quelques problèmes liés en autre au démarrage du logiciel.

Les instructions suivantes ont été appliquées sous Ubuntu (Feisty).


 $ sudo apt-get install wine cabextract

Recommençons à neuf si une tentative infructueuse a été tentée :

$ rm .wine/drive_c/Program Files/Microchip -rf

winetrick permet d'installer facilement les librairies dynamiques nécessaires à l'exécution de MPLAB :


 $ wget http://kegel.com/wine/winetricks
 $ sh winetricks vcrun6
 $ wget http://ww1.microchip.com/downloads/en/DeviceDoc/mp760a.zip
 $ unzip mp760a.zip -d microchip
 $ wine Install_MP760a.exe

Pour faire disparaître la fenêtre à la fin de l'installation :


 $ wineserver -k

$ sh winetricks dcom98 $ wine .wine/drive_c/Program Files/Microchip/MPLAB IDE/Core/MPLAB.exe

 MPLAB est maintenant lancé.
 C30 a été installé sans aucune recommandation particulière. En ce qui a trait au ICD2, je ne peux confirmer encore de mon expérience qu'il fonctionne bel et bien avec cette installation. Il est fort possible qu'on ait d'abord à créer un lien symbolique dans /.wine/dosdevices nommé com1 sur /dev/ttyS0.
 Voir en ligne :
 Application database sur winehq.org
 Problème au démarrage



Port série en C sous Linux
Pierre-Luc Bacon — 2007-06-14T22:26:08Z
Sommaire
 Le port parallèle peut semble plus simple à utiliser à bien des égards quand vient le temps déterminer l'interface de communication avec un robot. Toutefois, celui-ci est appelé à disparaître sur le nouveau matériel et est bien souvent absent des cartes mères embarquées (single board computer). Certes, il en est de même pour le port série, mais les adapteurs usb/série sont très faciles à trouver. Notons ici que FTDI Chip produit le FT245 qui permet d'obtenir une liaison parallèle virtuelle au travers d'un port USB.
 Ouverture et fermeture du port
 Les fonctions qui permettent de réaliser ces opérations sont les mêmes que celles utilisées courament dans les systèmes UNIX : open() et close() serviront donc, vous l'aurez deviné.
 int srl_handle; srl_handle=open("/dev/ttyUSB0", O_RDWR | O_NOCTTY | O_NDELAY); if(srl_handle<0) { perror("serial port open"); exit(-1); }else { fcntl(srl_handle,F_SETFL,0); }
 Vous aurez ici remarqué que /dev/ttyUSB0 est passé à la fonction open() plutôt que /dev/ttyS0. Ceci n'est applicable que si la notation retenue dans udev pour un adapteur usb/série est sous cette forme. Voyez dmesg après branchement pour plus de détails. Même si la liaison RS232 s'effectue par USB, l'interface de programmation ne change pas : le driver se charge de rendre opaque les détails d'implémentation USB.
 O_NOCTTY est une option permettant de spécifier que le programme ne sera pas un "controlling terminal" : un paramètre passé presque à tout coup pour la plupart des programmes.
 O_RDWR signifie que le fichier est ouvert en lecture et en écriture.
 O_NDELAY spécifie finalement de ne pas attendre un changement de ligne sur le signal DCD. Si cette option n'est pas passée, le programme sera bloqué jusqu'à ce que DCD passe à l'état bas.
 La fonction fcntl est quant à elle appelée pour permettre de rétablir le port série en mode bloquant pour la fonction read(). Ainsi, si aucun charactère n'est encore disponible en lecture, le programme attendra en ce point du programme.
 La fermeture du port se fait avec la fonction close(), tout simplement :
 close(srl_handle);
Permissions
 Comme le port série est représenté comme un fichier en /dev, il sera nécessaire d'exécuter le programme avec les droits de super-utilisateur root.
 Sinon, il est possible de changer les droits d'accès sur le fichier ou d'en changer le groupe. Voici quelques exemples sous Linux où le port série apparaîtra comme /dev/ttSx (/dev/cuaax sous FreeBSD).
 Définir l'accès pour un nouveau groupe
 Cette solution est à préférer.
 $ groupadd robot $ chgrp robot /dev/ttyS0 $ chmod 0060 /dev/ttyS0
Donner accès à tous les utilisateurs possibles
 À éviter si possible, mais tolérable en phase de test.
 $ chmod a+rw /dev/ttyS0
Donner l'accès à soit-même seulement
$ chown alice /dev/ttyS0 $ chmod 0600 /dev/ttyS0
 Prenez note que si votre système est configuré avec udev, ces commandes n'auront pas un effet permanent après redémarrage. Il sera alors nécessaire d'adapter un fichier de configuration généralement situé dans le répertoire /etc/udev/rules.d/
 L'interface POSIX
 <termios.h> fournit les structures de contrôle ainsi que les fonctions POSIX qui permettront de définir les propriétés des laisons sérielles qui seront mises en place.
 Vitesse de connection
struct termios options; tcgetattr(srl_handle, &options); cfsetospeed(&options, B19200); options.c_cflag |= (CLOCAL | CREAD);
 Dans ce bout de code, une structure termios est déclarée et initialisée par la fonction tcgetattr. Cette structure comprend plusieurs membres qui seront assignés à des valeurs définies par des #define en utilisant des opérateurs bit à bit.
 Dans cet exemple, cfsetospeed est utilisé car cette fonction permet de définir la vitesse (le "baud rate") dans le membre approprié de la structure termios. En effet, certains systèmes POSIX ne définissent pas cette valeur des le même membre (c_flag, c_ispeed, ou c_ospeed), d'où le besoin d'une fonction indépendante du système.
 Les options CLOCAL et CREAD sont définies pour éviter que le programme soit considéré en tant que propriétaire du port. Précisons au passage que l'accès aux membres de la structure devra toujours s'effectuer avec les opérateurs bit à bit tel que montré ci-haut. Un OU binaire sert ici à combiner les nouvelles options à celles déjà existantes dans le membre sans les écraser.
 Bits de données (taille du charactère)
options.c_cflag &= ~CSIZE; options.c_cflag |= CS8;
 Cette première ligne permet de mettre toute valeur pour cette option à 0. CSIZE n'est donc ici qu'un masque "nié" par "~" et affecté à c_cflag par l'opérateur binaire "&" (ET). CS8 (8 bits) peut ensuite être attribué au membre par un OU binaire qui renverra nécessairement CS8 puisque les bits du masque sont maintenant tous à 0. Rappelons-nous que le fonctionnement du OU peut se résumer à : "l'un, ou l'autre, ou les deux en même temps". Dans ce cas, "l'un" suffit à faire égaler le résultat à la valeur exacte de CS8.
 Notez que CS5, CS6 et CS7 sont aussi disponibles.
 Parité
 Si on ne choisit pas de méthode de vérification par parité pour les données envoyées, c_flag devra être défini ainsi :
 options.c_cflag &= ~PARENB; options.c_cflag &= ~CSTOPB; options.c_cflag &= ~CSIZE; options.c_cflag |= CS8;
 Avec CSIZE et CSTOPB, on reconnaît ici la configuration 8N1 : 8 bits de données (8), pas de parité (N) et 1 bit d'arrêt (1),
 Application des attributs
 Après avoir défini la structure termios avec les options voulues, elles doivent être appliquées par la fonction tcsetattr.
 tcsetattr(srl_handle, TCSANOW, &options);
 TCSANOW indique que les changements doivent être appliqués immédiatement sans attendre la fin des données en entrée ou en sortie.
 Envoi des données
 Cette opération s'effectuera avec le simple appel de la fonction write.
 if (write(srl_handle, "g", 1) < 0){perror("write:");}
 Le troisième argument de la fonction indique le nombre d'octets à écrire. Lorsque les données ont pu être envoyées, le nombre d'octets écrits est retourné.
 Lecture
Mode non bloquant
 Comme spécifié plus haut, la fonction read() qui permet de lire les données sur le port série peut être configurée en mode bloquant ou non. En effet par un appel à fcntl() avec l'option FNDELAY, read() retournera immédiatement avec la valeur 0 si aucune donnée n'est actuellement disponible.
 fcntl(srl_handle, F_SETFL, FNDELAY);
 La syntaxe de la fonction read est quant à elle identique à write :
 if(read(srl_handle, buffer, 4) < 0){perror("read");}
 Où buffer est un pointeur sur le tableau qui contiendra les données et "4" , dans cet exemple, le nombre d'octets à copier dans cet espace.
 select
 Dans bien des cas, des contraintes de temps de réponse sont exigées dans un programme. En effet, plusieurs tâches doivent souvent être exécutées simultanément. Un appel à la fonction read peut ainsi compliquer quelque peu l'organisation du programme puisque deux choix pourraient s'offrir à priori : attendre les données (mode bloquant), ou faire un pooling sur read. La fonction select peut alors s'avérer utile pour surveiller l'état de plusieurs descripteurs de fichiers en même temps. On pourrait par exemple définir un ensemble socket et port série et à l'arrivée de donnée sur l'un ou l'autre des descripteurs, select renverrait une valeur supérieure à 0. On s'évite ainsi un pooling systématique pour chaque fichier à surveiller. [1]
 signal
 La programmation d'une routine de communication sur le port série pour un microcontrôleur aurait été facilement réalisée par un mécanisme d'interruptions. Toutefois, les interruptions matérielles à proprement dit ne sont pas accessibles dans l'espace utilisateur du système. Seul un pseudo-mécanisme d'interruptions seraient alors envisageable par la programmation d'un driver qui enverrait un signal à un programme de l'espace d'utilisateur. [2]
 Aussi, l'utilisation d'une extension temps réelle au noyau permettrait de réaliser de telles opérations avec des fonctions de son API. Ceci ne sera cependant pas couvert ici. [3]
 Enfin, c'est l'option O_ASYNC [4] passée à open qui permettra la mise en place de ce mécanisme. Un signal SIGIO sera alors généré à toute arrivée ou écriture de donnée (lorsque le buffer en sortie aura été rempli) pour un fichier ouvert en mode RW. Ensuite, il suffira de mettre en place une fonction de prise en charge du signal (handler) attaché à ce signal et de bien s'assurer par select que le SIGIO reçu corresponde bien à l'événement souhaité sur le port. L'attribut F_SETOWN [5] devrait aussi être appliqué avec la fonction fcntl pour le descripteur de fichier du port série.
 Référence

 Le livre Serial Programming Guide for POSIX Operating System de Michael R Sweet a servi de référence pour la rédaction de cet article. Il est disponible librement sur internet ou peut être acheté via lulu.com.
		
		[1] Un exemple de select : Using the SELECT System Call.
 [2] Voir opening bananas with steamrollers.
 [3] Voir RTAI Serial Port Communication Example pour plus de détails.
 [4] voir open(2).
 [5] Voir fcntl(2) .