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

Liens électronique et radio

  • Four-three-oh! : montages MSP430, entre autres avec le TI Launchpad.
  • FunCube Dongle : dongle USB pour la réception radio entre 64 à 1700 MHz (au moins, mais avec malheureusement un trou de 1100 à 1270 MHz), disponible à environ 150 €. Ce petit bijou est développé par un radio-amateur ; les unités produites se vendent comme des petits pains. Visiblement, le dongle se présente comme une carte son pour être facilement utilisable (fourniture des signaux I/Q sur les deux voies stéréo). Je regrette le trou susmentionné, ainsi la fréquence d'échantillonnage limitée à 80 kHz, mais je me laisserai peut-être tenter...

LaunchPad MSP430 : liftoff !

Texas Instruments lance une carte de développement pour ses microcontrôleurs MSP430 : LaunchPad. Les MSP430 sont des microcontrôleurs a priori intéressants, 16 bits, dont l'architecture semble plus carrée que celle des PIC 8 bits.

La carte Launchpad embarque un support à microcontrôleur, deux LED, deux boutons, et un programmateur sur port USB. Quand on sait qu'elle est disponible à $4.30, frais de ports compris, il n'y a pas à hésiter très longtemps pour passer commande ! En revanche, TI n'arrive pas à répondre à la demande ; on donc attend la livraison longtemps (presque 4 mois dans mon cas).

À la réception, l'impression est très bonne. Outre la carte LaunchPad, le kit contient deux microcontrôleurs, un câble USB, un quartz optionnel, des connecteurs. J'ai choisi d'installer l'environnement de développement IAR, disponible sur la page du LaunchPad. D'emblée, cela met en place le driver USB, qui permet de faire fonctionner l'application pré-programmée dans le micro : l'envoi sur l'émulation USB-UART de sa température interne.

En suivant ces explications pour la création d'un projet IAR, on arrive alors en quelques minutes à faire fonctionner un petit programme qui fait clignoter les LED. La programmation et le débogage in situ sont directement gérés par IAR.

Décidément, un kit prometteur !

Afficheur LCD sur I2C

20090131_lcd.jpg J'ai déjà traité des afficheurs LCD, sur une interface parallèle (les plus répandus) ou I2C (plus rares, mais bien pratiques car peu consommateurs en fils).

Sans revenir sur la description succincte du protocole que j'ai déjà donnée, cet article décrit le montage à base de microcontrôleur PIC, ainsi que le programme utilisés pour mes essais. Notons que le programme et le montage sont spécifiques à un modèle donné d'afficheur, mais peuvent être adaptés, notamment au niveau du brochage, des timings et de la table de caractères utilisée.

Lire la suite...

Décodeur RDS

Je viens de concrétiser un projet de longue date : réaliser un décodeur RDS. J'avais travaillé sur ce projet en 2001, sans aboutir, et je l'avais ensuite remis à plus tard. Voyons en quoi cela consiste, et ce qui m'a enfin permis d'avancer.

Le RDS, pour Radio Data System, permet aux émetteurs de radiodiffusion en bande FM de transmettre des informations telles que le nom de la station, des fréquences alternatives, des signaux horaires, des textes, ou encore des informations plus complexes qui permettent le basculement sur d'autres réseaux lors de la diffusion d'informations routières. D'un point de vue technique, le RDS ajoute une porteuse à 57 kHz au signal multiplexe des stations (le signal multiplexe de base est constitué du signal mono non modulé et d'un signal stéréo « différentiel » modulé en AM sur une porteuse à 38 kHz, supprimée), laquelle est modulée en amplitude, porteuse supprimée, par des symboles biphase correspondant aux bits, au débit de 1187,5 bits par seconde. Les données binaires sont structurées en « groupes » de 104 bits, composés de 4 blocs de 26 bits. Un bloc contient lui-même 16 bits de données et 10 bits qui servent à la synchronisation et à la détection/correction des erreurs. Il est possible d'acquérir la synchronisation au niveau bloc.

20090913_montage.jpg

Lire la suite...

Outil UART du PICkit 2 pour le débogage

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.

Lire la suite...

Analyseur logique du PICkit 2 et fréquence des PIC

20090717_logictool_extrait.pngDepuis quelques temps, le logiciel de programmation du PICkit 2 dispose d'une fonction analyseur logique et UART, extrêmement pratique. Intéressons-nous tout d'abord à l'analyseur logique. Il peut analyser trois canaux en parallèle, sur les broches PGC, PGD et AUX du PICkit 2. Ce qui est génial, c'est que les broches PGD et PGC sont déjà connectées sur tous les montages qui supportent la programmation sur place (ICSP), et qu'elles sont à ma connaissance multiplexées sur tous les PIC avec des I/O numériques. De plus, on essaie en général de ne pas utiliser les I/O multiplexées avec PGD et PGC, donc il y a de fortes chances que ces pins soient inutilisées dans le montage, et qu'on puisse donc les réquisitionner pour faire du débug sur les signaux ! Sans modifier un montage existant, sans déplacer le PICkit entre la phase de programmation et la phase d'exécution du programme, on peut donc analyser des signaux émis par le programme. Pratique, non ?

Lire la suite...

Afficheurs LCD

20090131_lcd.jpg 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.

Lire la suite...

Lampes fluocompactes

Je viens de devoir remplacer une lampe fluocompacte. J'ai profité de l'occasion pour m'intéresser un peu à marché et rechercher une bonne lampe. Ce billet fait d'abord un bilan économique de la lampe précédente, qui a duré 40 mois, puis présente quelques critères de choix.

Lire la suite...

USB sur PIC et AVR

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.

Alimenter ses montages électronique à base d'alims ATX

Quand on bricole de l'électronique, on a toujours besoin d'une alimentation stabilisée, fournissant au moins du 5 V. Or tout bon geek possède chez lui au moins une alimentation de PC qui traîne, et qui peut parfaitement remplir cet office, fournissant plein de tensions intéressantes :

Les connexions sont le point délicat : soit il faut couper des fils (horreur !), soit il faut trouver des connecteurs MOLEX pour brancher la chose sans l'abîmer. Or ces connecteurs sont assez rares au détail... Notons toutefois que les petits connecteurs pour lecteurs de disquettes sont compatibles avec les barrettes de connexion HE-14, ce qui est assez pratique.

Côté erreurs de manipulation, mon alim semble bien supporter les court-circuits : elle se contente de se couper, mais se remet en marche au bout de quelques secondes et après avoir été déconnectée du secteur. Cela doit être le cas de la plupart des modèles récents.

Carte de test PIC18F/USB sous Linux

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...

Notes

[1] à créer éventuellement avec mknod /dev/ttyACM0 c 166 0

[2] Je recommande de lancer Minicom par minicom -o pour éviter d'envoyer à la carte des séquences AT d'initialisation de modem...

Carte de test PIC18F/USB

Schéma de la carte de test Les expérimentations menées sur PIC pendant les vacances ont fini par porter leurs fruits. J'ai désormais un schéma fonctionnel qui permet de fabriquer un périphérique USB simple autour d'un PIC 18F2455. Ce billet présente le schéma de la carte de test, qui permet de jouer avec deux LED, ainsi que le programme correspondant.

Le montage a déjà été brièvement introduit dans ce billet. Le présent programme prend une direction un peu différente, notamment au niveau de la vitesse du bus USB (full-speed). La raison en est simple : j'ai récupéré un programme de démonstration fourni par Microchip, qui était conçu pour PIC18F4450, et je l'ai adapté sans retoucher les directives de configuration pour le moment. Je ferai quelques expérimentations lorsque j'aurai le temps, et je posterai des informations le moment venu !

Lire la suite...

PIC 18F2455 et oscillateur externe

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 :

Montage électronique : avant Montage électronique : après

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) :

PIC18F, deuxième

Après quelques essais, j'ai résolu les problèmes évoqués dans un premier billet sur les PIC !

Les problèmes électriques

Ces problèmes étaient à l'origine d'un certain non-déterminisme dans le fonctionnement du PIC. En vrac, voici les améliorations que j'ai apportées :

  • le PIC a deux pattes Vss (8 et 19). Je n'avais connecté que la 19, mais cela peut visiblement causer des soucis. J'ai donc connecté les deux ;
  • j'ai déplacé la capa de découplage (100 nF) entre Vdd et Vss pour la mettre le plus proche possible du PIC. Ça tombe bien, les deux pattes sont adjacentes (20 et 19)
  • dans certaines configurations (et bien que n'étant pas a priori concerné), la patte 1 est traitée comme /MCLR (reset). Je l'ai donc relié à Vdd par l'intermédiaire d'une résistance de pull-up (10 k). Cette résistance ne pose visiblement pas de problème pour la programmation (la patte 1 est aussi Vpp).

Après avoir apporté ces modifications, le fonctionnement est devenu entièrement déterministe et reproductible, mais ça ne fonctionnait toujours pas comme je le voulais...

La programmation

On ne le dira jamais assez, RTFM !

Je me suis rendu compte du problème en visualisant les sorties RB0..7 sur le débugueur de MPLAB. Il est très bien fait, avec un mode « oscillo ». Hé bien lorsque j'envoyais un signal carré sur RB0..7, RB2 et RB3 restaient obstinément à 0, alors que les autres fonctionnaient !

Après lecture du datasheet, j'ai fini par localiser le problème : RB0..3 sont sur les mêmes pattes que les ports analogiques AN8..12, ce qui pose souci... Il faut donc indiquer que l'on veut utiliser les ports RBi sur ces pattes, et non les ANi. Cela se fait à l'aide du registre ADCON1 (décrit p. 254). Au passage, j'en ai profité pour reprendre la procédure d'initialisation de PORTB de la page 114.

Au final, le programme suivant fonctionne de façon très satisfaisante :

#include <p18f2455.h>

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

void tempo(unsigned char val) {
	int j;

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

void main(void) {
	// PORTB initialization, from p. 114
	LATB = 0;		// clear data latches
	ADCON1 = 0x0E;	// RB0:RB4 are multiplexed with AN8:AN12
					// select digital outputs, see p. 254
	TRISB = 0;		// direction: output pins

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

Si je ne fais qu'une seule itération dans la boucle (au lieu de 700), je génère un signal de fréquence 384 Hz (merci l'oscillo...)

Je pense qu'avant d'initialiser correctement PORTB, certaines pattes prenaient des valeurs « instables », et donc le fonctionnement réel pouvait dépendre de pas mal de facteurs... Comme la déclaration d'une variable inutile, par je ne sais quelle chaîne cause-conséquence complètement tordue.

Bilan

Je sais donc écrire un programme de base pour le PIC 18F2455. Prochaine étape : l'USB !

PIC18F, première

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.

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 dès la première fois en raison de quelques bourdes.

La suite dans un second billet !

- page 1 de 2

HTML5 valide ? © . ✍ Contact. Mentions légales.
Propulsé par DotClear.