INF1900

Projet initial de système embarqué

Travail pratique No. 1

Introduction à la carte mère et à SimulIDE

Objectif: Faire les premiers pas avec la programmation d’un microcontrôleur et effectuer le sertissage de fils

Durée: Une semaine

Travail préparatoire: Lecture de certains documents du site web du cours

Documents à remettre: Aucun.

Présentations en classe:

Sertissage des fils

Le premier laboratoire a une certaine forme de préambule qui est d’arriver à compléter l’assemblage de petits câbles dit «à deux positions» par la réunion de deux fils multibrin de couleurs différentes. L’assemblage demande de prendre à la serre un morceau de métal très petit au bout d’un fil dénudé avant de l’insérer dans un réceptacle noir prévu pour le recevoir pour ainsi obtenir un câble pouvant être utilisé dans des situations variées avec le robot.

Il faudra regarder la vidéo sur le sertissage, la quatrième ici dans la liste de celle pour le montage (ou encore sur YouTube). Par la suite, on pourra suivre ce qui est à réaliser dans les opérations de sertissage.

Il vous faudra des pinces ainsi que le matériel nécessaire. Le chargé de laboratoire pourra vous fournir le tout, à votre première ou deuxième séance de laboratoire cette semaine.

Premier programme et compréhension générale du système

La première étape sera d’installer les outils nécessaires au cours. Il faudra lire certains documents pour comprendre la carte à microcontrôleurs et la programmation des microcontrôleurs AVR. La lecture des documents est essentielle pour ce travail pratique, mais aussi pour ceux à venir. Il faudra aussi comprendre comment fonctionne le simulateur SimulIDE. Lire uniquement les sections «SimulIDE» et «Utilisation de SimulIDE».

De plus, il suffit d’utiliser le câble USB pour alimenter électriquement la carte. Ce câble servira aussi à programmer la carte. Il n'est pas nécessaire de comprendre les appareils de laboratoire pour l'instant, car ils seront introduits dans les semaines suivantes, quand le contexte sera plus favorable.

Comment, au minimum, comprendre comment fonctionne le robot ? Pour débuter avec le robot en offre une partie de l’explication. Par contre, il faut noter que la partie motrice du robot (par le pont-en-H) sera plutôt abordée dans les semaines à venir. On pourra donc y revenir plus tard même si votre curiosité peut vous pousser à le parcourir dès maintenant.

Pour voir si l’installation des logiciels a mené à un système qui fonctionne bien, tout en prenant contact pour la première fois avec le simulateur, il convient de commencer le travail de programmation par des exercices simples. Le premier consistera à allumer et éteindre des diodes électroluminescentes (DEL) pour s'initier aux sorties. Pour ce qui est des entrées, un simple bouton-poussoir sera utilisé.

Pour arriver à programmer le microcontrôleur, il faudra commencer par se familiariser avec sous Linux.

Environnement de programmation

Le microcontrôleur reste fondamentalement un processeur. Il peut donc être programmé comme n'importe quel autre système à microprocesseur, comme un ordinateur personnel par exemple. Cependant, à la différence d'un ordinateur de bureau, il ne vient pas avec un clavier, un écran et une souris, ce qui le rend un peu difficile d'accès. Pour arriver à lui donner des instructions, on peut utiliser un compilateur courant, tel GCC par exemple. On compilera le code sur un PC de la même manière dont on le ferait pour le développement d'une application Windows, Linux ou Mac. La seule différence est que le fichier exécutable produit sur le PC doit être téléchargé sur le microcontrôleur. Le PC ne peut d'ailleurs même pas exécuter le fichier binaire directement, car les jeux d'instructions du microcontrôleur et du microprocesseur du PC sont différents et incompatibles. Techniquement, on dit d'un tel compilateur qu'il est un compilateur croisé (cross-compiler en anglais) puisqu'il génère des fichiers binaires pour une plate-forme différente de celle sur laquelle il évolue lui-même.

Dans le cas qui nous concerne, nous travaillerons sous Linux en employant GCC pour compiler. Que l’on utilise la carte mère ou le simulateur, il y a peu de différences dans les étapes à suivre de sorte qu’on donnera ici la procédure à suivre pour les deux tout en soulignant les différences uniquement lorsque nécessaire. On vous encourage à maîtriser les deux outils. On peut tout de même arriver à la compilation du code sans aucune différence entre les deux façons de faire. Ce n’est que le chargement de l’exécutable dans le système et l’exécution qui diffère légèrement par la suite.

L’éditeur:

Sauvegarder le fichier C/C++ qui suit sous un certain nom dans un répertoire de votre choix. Il vous faudra prend l’éditeur VS Code pour pouvoir regarder le contenu de ce fichier. Vous pouvez prendre le temps qu'il faut pour installer et voir comment fonctionne Visual Studio Code, si c'est la première fois que vous utilisez cet éditeur pour l'édition de fichiers de code source. Une fois dans l’éditeur, il vous sera possible de facilement ouvrir un fichier. Il est à noter que l'utilisation du signe de pourcentage (%) sert à indiquer l'invité (prompt) d'un terminal sous Linux. Il n’a donc pas à être retapé dans la console. Vous taperez donc ce qui suit dans l'interpréteur de commandes (shell en anglais). Si vous ne le connaissez pas, voir site pour entreprendre votre étude des commandes de base en Linux. Cependant, la page sur les éditeurs sous Linux vous donne aussi quelques ressources supplémentaires. Ceci démarrera donc l’éditeur VS-Code au bon endroit si vous vous trouvez dans le même répertoire où vous avez déposé le fichier C/C++:

% code &

Le Makefile:

Maintenant que vous avez reconnu qu'il s'agissait bel et bien de code en C dans le fichier source, il faudra le compiler. Prendre ce fichier Makefile et le déposer dans le même répertoire. L’ouvrir avec VS Code. Ce Makefile peut sembler compliqué vu son caractère très général, mais nous avons 3 lignes à adapter pour arriver à compiler à peu près n'importe quel fichier source simple. Changer la fin de la ligne commençant par PROJECTNAME pour placer le nom du fichier exécutable que vous voulez obtenir une fois la compilation terminée. Ce pourrait être, par exemple, test32bits. Un peu plus bas, dans le Makefile, à la ligne débutant par PRJSRC, placer le nom du premier fichier source de l'étape précédente au lieu de celui qui est inscrit. Remonter plus haut dans le fichier et changer la variable MCU pour indiquer le type de microcontrôleur que l'on souhaite programmer soit atmega324pa dans notre cas. Il se peut qu'il n'y ait rien à changer.

Compiler le code:

Il faut maintenant compiler et charger le programme. Une façon de faire pourrait être de taper les longues lignes des commandes pour chacun des programmes à appeler. Cette façon de faire est longue et fastidieuse en plus d'attirer facilement les erreurs. Le Makefile établi précédemment nous simplifie la tâche puisqu'il fait tout pour nous. On tapera donc la commande suivante et on lira les messages affichés à l'écran.

% make

Le simulateur et/ou la carte:

On a déjà un code compilé sans avoir eu recours ni à la carte mère ni au simulateur. Les opérations se séparent à partir d’ici.

Pour le simulateur :

Partir le simulateur SimulIDE et charger le fichier de matériel .simu. La configuration matérielle déjà en place permettra de faire tourner le code précédemment chargé.

Pour la carte mère :

Relier la carte mère au PC avec un câble USB. Prendre un câble à deux positions serti. Il doit avoir ses deux bouts femelles. Brancher un bout sur le connecteur IDC de la section «Del libre» de la carte mère. Brancher l'autre bout sur les broches 1 et 2 du port C.

Chargement de l’exécutable:

Pour le simulateur:

Il faudra par la suite charger le fichier .hex généré dans le processeur (clique-droit sur le processeur et «load firmware» par la suite). Démarrer la simulation en cliquant sur le bouton prévu dans la barre du haut en rouge.

Pour la carte mère :

Le Makefile établi précédemment nous simplifie la tâche puisqu'il fait tout pour nous. On tapera donc la commande suivante et on lira les messages à l'écran. Le Makefile appellera le chargeur AVR Dude pour effectuer le transfert de l’exécutable vers la carte par USB:

% make install

Observation du comportement:

Normalement, dans le simulateur ou sur la carte mère, les DEL devraient commencer à scintiller directement si tout se passe bien. Si le premier make n'a pas passé, il faut penser que la source du problème est probablement dans le Makefile puisque c'est le seul fichier qui a été édité (à moins que vous ayez introduit des caractères par accident en consultant le fichier source). Une autre possibilité pourrait être un problème avec une mauvaise installation de AVR-GCC ou du programme make lui-même.

Le simulateur présente des DEL sur plusieurs ports alors que pour la carte mère, leur nombre est plus limité. Tout de même, sur la carte mère, déplacer le câble à deux positions des broches 1 et 2 du port C vers d'autres paires de broches adjacentes sur d'autres ports au fur et à mesure pour explorer un peu ce qui se passe.

Essayer de comprendre ce que vous observez du comportement de la DEL et du code que vous avez. Pouvez-vous y voir un lien avec votre additionneur binaire matériel de INF1500 réalisé avec des portes logiques (demi-additionneur et additionneur complet) avec propagation de la retenue ?

Pour une recompilation depuis le départ:

Si vous voulez refaire les étapes de compilation précédentes, mais pour d'autres fichiers sources, il suffit de modifier la variable PRJSRC dans le Makefile à chaque fois. Lors d'un changement de fichier source, il est nécessaire de faire le nettoyage des fichiers intermédiaires produits durant le processus de compilation ce qui se fait avec la commande suivante:

% make clean

Contrôle d'une DEL

Il faudra reproduire le circuit suivant dans SimulIDE. Noter que les DEL peuvent être reliées à deux broches consécutives du port que vous souhaitez utiliser (n’importe quel, sauf peut-être le port D pour l’instant), tant que vous en tiendrez compte dans le code à écrire qui suivra. L’interrupteur doit obligatoirement être relié au port D2 pour des raisons qui deviendront plus claires d’ici quelques semaines. Il faudra sauvegarder ce circuit dans un fichier ayant l’extension .simu comme dans l’exemple et le placer préférablement dans le même répertoire que celui dans lequel vous placerez aussi votre code C/C++. Il est important de noter que le nom du fichier que vous choisirez ne doit absolument pas contenir d’espace, car SimulIDE aura de la difficulté à le recharger par la suite. De toute façon, aucun fichier ce code source que vous écrivez ne devrait contenir d’espaces ou de caractères avec accents. C’est une mauvaise pratique.

Si l’exercice est fait sur la carte mère, il est à noter que la DEL libre à usage général sur la carte est bicolore. Il est donc possible d'afficher une couleur différente en changeant la polarité de la tension appliquée à ses bornes tout comme le circuit réalisé dans le simulateur le permet. Du point de vue du matériel, c’est le même circuit et le même code va produire le même comportement dans le simulateur et sur la carte mère.

Il faut maintenant écrire un peu de code et faire faire à une DEL ce que nous voulons que ce soit dans le simulateur ou sur la carte mère. Il est à noter que la double-DEL libre à usage général dans le circuit prendra une couleur ou l’autre selon le sens du courant qui la traverse. Il est donc possible d'afficher une couleur différente en changeant la polarité de la tension appliquée à ses bornes. Prenons un exemple. On a décidé de relier les broches A0 et A1 du port A du microcontrôleur aux deux broches de la double-DEL mais on aurait pu prendre deux autres broches. En plaçant en sortie les combinaisons 01 et 10 sur A0 et A1 du port A, on obtient des couleurs différentes de la DEL (vert et rouge). Toute autre combinaison n'entraînera pas de chute de tension dans la DEL et donc aucune couleur ne sera émise par cette dernière. Sur une vraie carte mère physique, par contre, un changement rapide et répété de polarité sur A0 et A1 arrivera à confondre l'oeil et donnera l'apparence d'une couleur ambrée (jaune foncé) si la DEL est réellement de type bicolore. Évidemment, sur la carte mère, le câble à deux positions doit être utilisé pour relier la DEL libre aux deux premières broches du port A pour avoir un circuit équivalent à celui du simulateur.

L'exercice consiste à faire allumer la DEL de chaque couleur pour quelques secondes. On affichera d'abord la couleur rouge, puis la couleur verte puis la couleur ambrée. On répétera cette séquence à l'infini. Pour ce faire, il faut prendre en considération les aspects suivants:

• Il faudra utiliser le fichier include arv/io.h, car il faut effectuer un travail sur les entrées/sorties du microcontrôleur. Pour vous aider dans votre programmation, il faudra consulter des sections de la documentation sur la librairie AVR LibC, surtout les sections «Special function registers» et «Standard Integer Types» dans «Library Reference» de la documentation.

• L'utilisation de type uint8_t serait souhaitable puisqu'on travaille avec un processeur de 8 bits.

• Il faudra introduire des délais importants en plusieurs endroits dans le code puisque l'AVR travaille à une vitesse de 8 Mhz ce qui est énorme à l'échelle humaine. L'AVR peut faire des millions d'instructions durant une seconde. Il faut donc lui faire perdre beaucoup de temps. La section «Busy-wait delay loop» vous sera très utile.

• Bien entendu, régler la vitesse du ATMega324 à 8 MHz (clique-droit sur le processeur et l’option «Properties» dans le menu. Le changement peut se faire dans la colonne de gauche de l’outil par la suite.

• Il faudra ajuster un port A du circuit pour qu'il soit en sortie ce qui nécessite l'ajustement du registre de configuration de ce port (DDRA). Ce port doit être celui choisi pour relier les DEL dans le circuit entré dans SimulIDE précédemment.

• Il faudra avoir une boucle infinie pour répéter la séquence.

• Il serait souhaitable de s'inspirer des exemples fournis à la section précédente pour écrire votre propre code.

• Si les opérations sur des bits en C/C++ est un concept inconnu pour vous, consulter rubrique Wikipédia pour en savoir plus sur la question.

Interrupteur

La carte comporte également 2 boutons-poussoirs. Le premier est le plus bas sur le bord gauche de la carte. Son activation provoque une remise à zéro (reset) du microcontrôleur ATMega324PA. Le second, situé plus haut, est pour usage général. Il est relié à la sortie D2 s'il y un cavalier sur IntEN qui est juste sous l'interrupteur. La sortie D2 peut également être configurée pour servir d'entrée à une interruption externe (au sens microprocesseur du terme, concept qui sera abordé dans quelques semaines).

Reprendre intégralement le circuit de l’exercice précédent si vous faites l’exercice avec le simulateur, mais cette fois, nous utiliserons l'interrupteur pour servir d'entrée au programme. Alors que précédemment les couleurs changeaient automatiquement après un certain délai, il faut maintenant attendre de recevoir une commande de l'interrupteur pour provoquer le changement de couleur.

Les interrupteurs de type bouton-poussoir tels que ceux d’une vraie carte mère physique ont une nature mécanique au sens où des pièces de métal doivent venir en contact pour provoquer la fermeture d'une boucle dans le circuit. Étant donnée la nature élastique du métal de l'interrupteur, un tel contact ne se fait pas instantanément, tel qu'on serait porté à le penser. Les morceaux de métal risquent fort de rebondir l'un sur l'autre durant quelques millisecondes avant que le contact demeure stable entre les deux. Le moment où le contact s'établit est donc un concept plutôt flou. Il est donc important de prévoir un mécanisme dit d'antirebond («debouncing» en anglais) pour établir plus clairement à partir de quel moment un contact a eu lieu dans le temps. Il existe plusieurs techniques pour arriver à préciser le point dans le temps et éviter que le microcontrôleur interprète plusieurs transitions sur l'interrupteur comme autant de changements de signal alors que l'utilisateur n'a appuyé sur le bouton qu'une seule fois!

Signal sans antirebond (haut) et son interprétation possible par le microcontrôleur

Une façon de faire est d'utiliser une bascule («latch») qui verrouille sa sortie dès que le seuil en entrée a été dépassé. Un condensateur peut aussi être placé pour filtrer le signal de l'interrupteur de façon à rendre la transition plus nette. Ces solutions sont de nature matérielle. Il existe aussi une façon toute simple d'arriver au même objectif en employant une méthode logicielle. Il suffit d'effectuer deux lectures consécutives (ou plus si l'on est vraiment nerveux!) du signal, mais séparées dans le temps d'un intervalle jugé approprié. Si la seconde lecture est à la même valeur que la première, on peut confirmer que le signal est stable. Un délai de 10 millisecondes est souvent utilisé dans les cas les plus courants pour s'assurer d'une bonne lecture.

Antirebond de façon logicielle

L'exercice consiste encore à allumer la DEL. Toutefois, les changements seront commandés par l'utilisation du bouton-poussoir Interrupt du circuit. Ainsi, chaque fois que l'utilisateur appuie sur le bouton (avec la souris...), la DEL tourne à la couleur de votre choix et demeure dans cette couleur tant que le bouton n'est pas relâché. Lorsque le bouton est finalement relâché, la DEL s'éteint. Quelques consignes avant de programmer:

• S'assurer de la présence d'un cavalier (jumper) sur IntEN sur la carte mère. Cette opération n’est pas nécessaire avec le simulateur.

• Avoir une fonction qui effectue une lecture du bouton-poussoir avec l'antirebond effectué de façon logicielle

• S'assurer que le port D2 est configuré en entrée. Normalement, par défaut, l'AVR considère chaque bit de chaque port comme étant en entrée, mais il est toujours utile de s'assurer que c'est bien le cas (être bien certain que DDRD est à la bonne valeur).

• En plus, pour lire d'un port configuré en entrée, il faut utiliser la valeur prédéfinie PINx. Donc, pour savoir si le signal 2 du port D est à 1, il faudra utiliser le masque 0x04 dans l’expression qui suit. En se faisant, on pourra «isoler» (ou ne prendre en compte si l’on préfère) que le signal 2 du port. Autrement, une transition sur une autre broche du même port pourrait être considérée valide ce qui n’est pas souhaitable ici:

if ( PIND & 0x04 )

Évaluation

Vous pourrez montrer votre code au chargé de laboratoire si vous désirez vous assurer de votre bonne compréhension de l'exercice. Il pourra vous demander d'expliquer certaines parties de vos programmes et vous aider au besoin. Aucun point n'est accordé pour ce travail, mais il est nécessaire pour la suite du cours.

Remarque très importante

Sur la carte mère, les bits [4:7] du port B (broches 5, 6, 7 et 8) du ATmega324PA sont utilisés par le ATmega8 lorsque ce dernier programme le ATmega324PA lorsque la commande make install est lancée pour que l'exécutable sur le PC se retrouve en mémoire flash. Donc, si des périphériques branchés sur la carte mère utilisent ces 4 bits les plus significatifs du port B, ils peuvent nuire à la programmation de la carte mère (messages d'erreur sur PC). Il n'y a pas de solution simple à ce problème. Il est fort possible qu'on doive utiliser cette partie du port B. Dans ce cas, il faudra peut-être débrancher ces périphériques à chaque reprogrammation de la carte mère, ce qui est pénible... Dans la mesure du possible, pour éviter cet inconvénient, n'utiliser ces entrées/sorties que si la situation le nécessite (parce que les autres ports sont déjà occupés par d'autres périphériques). Le simulateur n’est pas affecté par cette contrainte.

Le saviez-vous ?…

Dans VS-Code:

• Ctrl + Shift + I : pour formater automatiquement le code

• Ctrl + Shift + ` (apostrophe autrement dit) : pour ouvrir la console

Dans un terminal Linux:

• On peut toujours faire la commande «man» (pour manuel) suivie du nom d’une commande pour avoir accès à une description de la commande voulue et en apprendre plus sur les options possibles avec celle-ci. Exemple : % man ls

• Assez souvent aussi, on peut évoquer une commande avec soit l’option -h ou l’option --help pour en apprendre plus également. Exemple: % ls --help