Christophe Jacquet — Carnet — Mot-clé : Électronique

Lorsque l'on met au point un programme, il est souvent pratique d'effectuer des affichages de diagnostic. Ah, le bon vieux débogage à la printf... Pour faire des affichages à partir d'un montage à microcontrôleur, le plus simple est d'utiliser une liaison série RS-232. Les microcontrôleurs disposent généralement de ports UART, mais aux niveaux TTL (0 / +5 V), pas aux niveaux prévus par la norme RS-232 (–12 V / +12 V). On doit donc utiliser un circuit d'adaptation des niveaux, en général un MAX232 ou équivalent, accompagné de sa noria de capas au tantale. Ajoutons à cela la nécessité sur les PC récents d'utiliser un adaptateur série/USB, et on obtient une installation bien complexe pour un petit débogage.

J'ai déjà parlé de la nouvelle fonction analyseur logique du PICkit 2. Sur le même principe, le PICkit 2 dispose d'une fonction UART (aux niveaux logiques TTL), bien utile pour permettre à un programme d'effectuer des affichages de débogage. Et comme pour l'analyseur logique, les fils TX et RX se trouvent sur les broches PGC et PGD du PICkit, toujours connectées sur un circuit qui prévoit la programmation sur place (ICSP). On peut donc rajouter ce type de débogage sans modification matérielle sur des montages existants, et on n'aura même pas à débrancher/rebrancher le PICkit entre les phases de programmation et d'exécution.

Il existe de nombreux modèles d'afficheurs alphanumériques LCD, qui varient par la taille (nombre de lignes et de colonnes), par la présence de rétroéclairage et son type, ainsi que par le jeu de caractères disponibles. Malgré une telle diversité, les fabricants ont en général la bonne idée de s'aligner sur la norme de fait Hitachi HD44780.

Ce billet constitue une introduction générale aux afficheurs. Deux articles ultérieurs détailleront leur utilisation avec un microcontrôleur PIC, via l'interface parallèle standard, et via la variante sur bus I2C.

Certains microcontrôleurs PIC 18F ou AVR permettent de créer des périphériques USB. En effet, ils sont équipées de SIE (Serial Interface Engine) dédiés, d'un contrôleur d'interruptions... Mais de brillants bidouilleurs ont réussi à implémenter le protocole USB sur les plus modestes PIC 16F ou AVR ATtiny qui ne disposent pas de SIE !

• projet espagnol : le PIC 16F84A est overclocké à 24 MHz (au lieu de 20 MHz) de façon à disposer de 4 (!) instructions pour traiter chaque bit reçu sur le bus USB, directement connecté sur un port d'E/S du PIC. Malheureusement, le firmware n'est pas en ligne ;
• USBtiny : communication par USB sur un ATtiny, en GPL. Un article est consacré à ce projet dans GNU/Linux Magazine France de décembre 2007.

Le projet USB host sur un PIC 18F est également très intéressant, car ils se distingue des précédents qui réalisent des devices USB. Il est réalisé avec SIE externe (Cypress SL811HS). Cette page pointe par ailleurs vers un cours succinct sur le protocole USB. Pour plus de détails, voir « USB in a Nutshell » ou la spécification elle-même.

J'ai eu un peu de temps pour faire fonctionner ma carte de test PIC18F/USB sous Linux. Cela fonctionne très bien, à condition d'utiliser le bon pilote. Il s'agit de cdc_acm (CONFIG_USB_ACM), disponible sous le nom « USB Modem (CDC ACM) Support ». Une fois le driver chargé, la carte est reconnue automatiquement lors de la connexion. Cela crée un périphérique (/dev/ttyACM0^[1]) avec lequel Minicom^[2] (par exemple) permet de dialoguer.

Dans le log système, on retrouve des messages du type :

usb 2-1: new full speed USB device using uhci_hcd and address 5
drivers/usb/class/cdc-acm.c: This device cannot do calls on its own. It is no modem.
cdc_acm 2-1:1.0: ttyACM0: USB ACM device

Il est à noter qu'Ubuntu (Dapper Drake) possède par défaut le driver, donc ça fonctionne out-of-the-box (on branche et zou ! Minicom !). Je ne comprends pas comment ça se fait qu'il faille un fichier .inf à Windows, parce que visiblement, ce périphérique se déclare comme étant de la bonne classe...

Jusqu'à présent, j'avais utilisé l'oscillateur interne des PIC. Cependant, dans l'optique d'utiliser un jour les capacités de connexion des PIC 18F, j'ai cherché à installer un quartz. Le montage est très simple : il suffit de mettre le quartz entre les deux pins OSC1 et OSC2, et de mettre une petite capa entre chacune d'elles et la masse : j'ai mis 22 pF pour un quartz de 20 MHz. Voir le datasheet p. 27 pour quelques valeurs typiques.

Il faut ensuite faire bien attention au mode de fonctionnement choisi, entre XT (external resonator) et HS (high speed). Le choix dépend de la fréquence du quartz : en dessous de 4 MHz, prendre XT. Au-dessus, prendre HS. Si le mode n'est pas le bon, ça ne fonctionnera pas (j'en ai fait la malheureuse expérience !) Dans mon cas, j'ai donc dû choisir le mode HS.

Il existe ensuite plusieurs nuances. D'après ce que je comprends du §2.3, pour utiliser de l'USB faible vitesse, il faut que l'horloge du PIC soit à 24 MHz. Et avec un quartz de 20 MHz, la seule configuration possible est : utiliser une PLL qui prend en entrée du 4 MHz et fournit en sortie du 96 MHz. Pour cela, on doit commencer par diviser par 5 les 20 MHz pour l'entrée de la PLL, et diviser sa sortie par 4, ce qui nous donne les directives de configuration suivantes :

• FOSC = HSPLL_HS : mode oscillateur extérieur HS, PLL activée, HS utilisé pour l'USB ;
• PLLDIV = 5 : division par 5 de la fréquence avant la PLL (prescaler) ;
• CPUDIV = OSC3_PLL4 : division par 4 de la fréquence en sortie de la PLL (postscaler).

Pour le moment, j'arrive à faire clignoter deux LED, avec un oscillateur à quartz. Le montage peut être alimenté sur port USB. Je l'ai refait sur plaque à trous, ce qui peut éviter des soucis :

Sur la plaque à trous, on aperçoit au fond à gauche le connecteur ICSP (In-Circuit Serial Programming) qui permet de reprogrammer le PIC sans le déplacer.

Ressources (mise à jour 3 janvier 2008) :

• je fournis un programme de démonstration, bien commenté : blink20mhz.c
• un schéma pour la carte électronique est donné dans le billet « carte de test PIC18F/USB »

J'ai enfin pu essayer un PIC 18F2455, équipé de tout ce qu'il faut pour construire des périphériques USB. La première séance a été consacrée à la découverte du chip, sans essayer l'USB pour le moment. Et ce n'est sûrement pas pour tout de suite, étant donnés les quelques soucis rencontrés...

I — Connexion de la bête

J'ai voulu tester la programmation du PIC à l'aide du programmateur PICkit 2, qui permet par ailleurs de l'alimenter. A priori, la connexion est très simple : le PICkit 2 est équipé d'un connecteur à cinq broches ; il suffit connecter chacune d'entre elles à la patte correspondante du PIC. Si les broches Vpp, Vdd et Vss ne posent pas de problème (même nomenclature des deux côtés), j'ai en revanche eu un peu de mal à trouver la correspondance des broches « ISCP Data » et « ICSP Clock ». Je l'ai finalement trouvée dans le manuel du PIC :

• pin 28, appelée PGD, correspond à « ICSP Data » ;
• pin 27, appelée PGC, correspond à « ICSP Clock ».

Pour faire les tests, j'ai connecté des LEDs sur RB3 et RB4.

II — Programmation

Je me suis décidé à essayer de programmer le PIC en C avec C18 Student Edition. L'installation se passe sans problème et il s'intègre bien à MPLAB.

Pour programmer en C, il faut commencer par créer un projet. On crée un fichier .c ; on l'ajoute au projet, et on compile le projet avec Ctrl+F10 (lorsqu'on a juste un fichier .asm, on l'assemble avec Alt+F10).

Premier problème : MPLAB se plaint car il n'arrive pas à trouver le fichier p18f2455.h. Si cela se produit, il faut aller dans Project > Build Options > Project et mettre le bon répertoire dans ''include path" (le sous-répertoire h du répertoire d'installation de C18).

Une fois ce souci réglé, la compilation se passe sans problème. Mais on obtient un module objet, pas de fichier HEX. C'est logique, il faut linker le fichier objet issu de la compilation du fichier .c avec les bibliothèques de C18. Pour cela, il faut un linker script, fourni avec C18. Faire Project > Add files to project, et aller chercher le script 18f2455.lkr dans le sous-répertoire lkr de C18. On obtient alors un fichier HEX qu'il est possible d'envoyer sur le PIC.

III — Débogage

On commence par sélectionner le simulateur : Debugger > Select Tool > MPSIM

Ensuite, c'est un jeu d'enfant : Debugger > Run, puis Halt, et ensuite il suffit de survoler les variables pour voir s'afficher leur valeur...

IV — Tests grandeur nature

Après connexion du programmateur PICkit 2 sur la plaque à bidouille, la programmation s'est effectuée sans problème. Cependant, je n'ai pas réussi à obtenir des résultats vraiment fiables et reproductibles.

Le programme suivant fonctionne à peu près convenablement ; il fait clignoter les deux LEDs, qui s'allument alternativement :

#include <p18f2455.h>

#pragma config WDT = OFF
#pragma config FOSC = INTOSC_XT

void tempo(int val) {
   unsigned int i, j; // <--- line 7

   for(j=0; j<1000; j++) {
       PORTB = val;
   }

   PORTB = 0;  // <--- line 13
}

void main(void) {
   TRISB = 0;

   while(1) {
       tempo(0b00010000);
       tempo(0b00001000);
   }
}

Cependant, si je supprimer la déclaration de i à la ligne 7, ça ne fonctionne plus : la sortie GP4 reste allumée alors que l'autre reste éteinte. C'est complètement incompréhensible !

Et si j'enlève l'instruction PORTB = 0 à la ligne 13, ça compile toujours (normal...), mais je ne peux plus envoyer le programme sur le PIC ! Le logiciel de programmation affiche « error in program memory ». Encore une fois, c'est complètement incompréhensible !

Au bilan, ça pourrait marcher plus mal (j'ai quand-même fait un clignotant), mais un certain non-déterminisme des opérations m'inquiète... Il faudra refaire des essais...