Club robotique de Sophia-Antipolis

Accueil > POBOTpedia > Capteurs > Autres capteurs > Le PCF8591

Le PCF8591

samedi 21 février 2009, par Eric P.

Plantons le décor

Ce chip fait partie de la famille I2C initiée par Philips. Nous avons joué un peu avec dans le cadre du projet du radeau environnemental, et on commence à en parler dans l’article de cette rubrique qui présente l’électronique de contrôle. Son datasheet est également disponible dans notre bibliothèque.

En résumé, c’est un circuit qui intègre :
 4 ADC 8 bits
 1 DAC 8 bits également

Les 4 entrées peuvent aussi être associées 2 à 2 pour travailler en mode différentiel et avoir une plus grande résolution.

Dans le cadre du projet du radeau, il nous sert à équiper la sonde qui est immergée (jusqu’à 10-15 mètres) pour collecter les mesures de divers capteurs : température, luminosité, conductivité,... Pour pallier le problème de la limitation de longueur d’un bus I2C, la liaison avec la surface passe par un extender de bus I2C PCF82B715, mais dont il ne sera pas question ici.

Si vous utilisez Fritzing pour concevoir un circuit électronique, retrouvez le composant PCF8591 sur cette page

Voici la carte concernée pour illustration :

Carte sonde immergée
PCF8591

Remarque : le deuxième chip à 8 pattes visible sur la carte est l’extender de bus. Son homologue est également présent à l’autre bout, sur la carte principale du radeau (cf l’article à son sujet)

Cet article présente les manips de test effectuées pour valider le protocole de dialogue avec le chip, afin d’être certain d’avoir le bon mode opératoire au moment de l’écriture du logiciel de contrôle.

Les outils

Pour tester l’I2C, il existe pas mal d’outils à des budgets divers, dont par exemple les analyseurs Beagle et host adapters Aardvark. J’ai la chance de disposer de ce genre de chose au boulot, et on en reparlera peut-être un autre jour. Ce ne sont pas les plus chers, même si ce n’est pas cadeau, mais l’association des deux est déjà un outil très intéressant (d’autant qu’il sont proposés en bundle par Total Phase).

L’autre option, financièrement plus à notre portée, est composée :
 de l’interface USB/I2C, déjà présentée dans nos colonnes (cf cet article de Julien)
 de Docklight, déjà présenté dans nos colonnes également

Un petit aparté...

...concernant Docklight.

C’est un outil génial pour qui veut faire des tests ou du debug impliquant à la base une liaison série. Il est proposé pour quelques dizaines d’euros dans sa version de base par la société FuH (Flachmann und Heggelbacher). Vous trouverez tous les détails sur leur site web. Ne vous arrêtez pas à la mention de "liaison série", car ça marche aussi avec n’importe quoi qui se présente comme un port COM virtuel, en incluant donc l’I2C (héhé), le Bluetooth,...

Si de plus vous optez pour la version Scripting, vous avez également le support TCP/UDP, aussi bien en mode client que serveur. En conclusion, vous pouvez remplacer "liaison série" dans le descriptif qui précède par "communication". A noter que cette version scripting dispose comme son nom l’indique d’un possibilité d’écriture de scripts en VB, ce qui est fort pratique pour décoder des trames GPS, calculer des checksums à la volée,...

Vous pouvez même l’essayer gratuitement et sans limitation de temps. La seule contrainte est qu’on ne peut alors pas sauvegarder les paramétrage, les séquences, les logs,...

Mais sincèrement, pour le prix de quelques bières ou paquets de clopes, ça vaut largement le sacrifice (ce qui est dommage pour moi, c’est que je ne fume pas et ne suis pas non plus amateur de bière). Je n’ai aucune action chez FuH, et ai payé plein pot mon exemplaire de Docklight Scripting, mais quand un outil est bon, ça le mérite et il faut le dire.

Fin de l’aparté.

Retour au PCF

...8591 bien entendu, car il n’est pas question de politique dans ces rubriques ;)

Pour effectuer la conversion d’un canal et en récupérer sa valeur, il suffit d’envoyer un octet de contrôle au PCF et de lire la donnée ensuite. Au passage, il faut se souvenir ce qui est dit au paragraphe 7.4 page 9 de datasheet du PCF concernant les données transmises en retour :

The first byte transmitted in a read cycle contains the conversion result code of the previous read cycle. After a Power-on reset condition the first byte read is a hexadecimal 80.

En bon Français, le premier octet retourné est le résultat de la conversion précédente, et doit donc être ignoré. En fait le PCF lance la conversion au moment où il reçoit l’octet de commande, envoie en même temps le résultat de la dernière conversion effectuée, puis celui de la conversion demandé. Pourquoi ? Peut-être pour nous faire patienter le temps que la conversion soit effectuée et faire en sorte que la "transaction" ne soit pas interrompue. Du genre, laissez-moi quelques instants, et lisez le journal d’hier en patientant.

Maintenant qu’on connait la manip théorique, comment faire cela avec nos outils ?

On commence par repérer le port COM virtuel qui a été assigné à notre interface USB/I2C et on l’utilise pour configurer Docklight. Comme Julien en parlait dans un autre article, n’oubliez pas qu’il faut paramétrer la liaison série avec 2 bits de stop, ce qui n’est pas très courant. Cela est indiqué très clairement dans la documentation de l’interface.

Il faut ensuite définir la séquence que Docklight va envoyer pour réaliser notre opération I2C. C’est là qu’on recommence à se gratter la tête : on a besoin d’envoyer un octet de commande puis de lire 2 bytes de réponse. Comment faire cela ? La seule commande proposée par l’interface USB/I2C qui prennent une longueur de données en paramètre est "Reading from I2C with internally addressable registers", l’autre commande read ne lisant qu’un seul byte. Mais notre PCF n’a aucun registre adressable. Alors ?

Et bien on fait comme si, et on met dans la trame à destination de l’interface I2C le byte de commande en guise de numéro de registre.

La trame hexadécimale à utiliser est donc :

55 91 00 02 

Détails :

0x55 I2C_CMD
0x91 adresse de base du PCF + bit read positionné
0x00 commande : lecture simple de l’ADC 0
0x02 on veut 2 bytes en retour, sachant que le premier sera ignoré

En réponse à cela, on est gratifié de :

00 00

Ce qui signifie que l’ADC0 vaut 0. Exact : je l’avais relié à la masse pour le test.

Pour vérifier, lisons l’ADC3 maintenant. La séquence complète est alors :

[TX] - 55 91 03 02 
[RX] - 00 FF 

La seule différence par rapport à l’exemple précédent est le 3ème byte de la commande qui vaut 3 au lieu de 0, puisqu’on demande à lire ADC3. La valeur correspondante est 0xFF, ce qui est exact car l’ADC3 était relié à Vcc.

Tout baigne. Nous savons maintenant récupérer individuellement les 4 ADCs.

Mais le PCF permet aussi de faire une lecture "en rafale" grâce au mode auto-incrément du numéro de canal. Pour l’activer, rien de plus simple : il suffit de positionner à 1 le bit auto-increment flag (cf figure 5 page 6 du datasheet) de l’octet de commande envoyé. Pensez également à positionner à 1 le bit analog output enable flag. Dans ce cas d’utilisation, cela n’a rien à voir avec la sortie du DAC, mais permet de maintenir l’oscillateur interne en fonction pendant les lectures multiples. Cela est expliqué en détail au paragraphe 7.2 page 5 du datasheet.

Tout cela mis bout à bout nous donne le dialogue suivant :

[TX] - 55 91 44 05 
[RX] - FF 00 41 BC FF 

Explications :

TX

0x55 déjà vu précédemment : c’est la commande pour notre interface USB/I2C
0x91 lecture du PCF à l’adresse 0x90
0x44 octet de commande de lecture avec auto-incrément à partir de l’ADC0, et analog output enabled
0x05 on veut lire 5 bytes : les 4 valeurs, précédées de la conversion précédente qu’on ignorera

RX

0xFF la précédente conversion, qu’on s’empresse de poubelliser
0x00 ... 0xFF les valeurs des ADC0 à ADC3

Et voilà, ce n’est pas plus compliqué que cela.

Quelques jolis dessins

Pour finir en beauté, voici les chronogrammes que nous montre l’analyseur Saleae Logic :

lecture de l’ADC0

Lecture simple de l’ADC0

lecture de l’ADC1

Lecture simple de l’ADC3

lecture des 4 ADC

Lecture des 4 ADCs

On y voit bien comment la trame unique qu’on envoie à l’interface I2C via Docklight se décompose en fait en deux échanges I2C : l’écriture de l’octet de commande, puis la lecture des n bytes demandés.

Les plus observateurs d’entre vous auront remarqué que l’adresse I2C figurant sur les chronogrammes est 0x48. Et pourtant je vous ai tout le temps parlé de 0x90. Vous aurais-je abusé à l’insu de votre plein gré ? Que nenni chers lecteurs. En fait, l’affichage de Logic montre les 7 bits de poids fort de l’octet d’adressage, en laissant de côté le bit de lecture/écriture. Or 0x90 shifté d’un bit à droite cela fait tout juste 0x48. Ca trouble un peu quand on a l’habitude d’utiliser les adresses intégrant le bit R/W, ce que font les datasheets la plupart du temps. L’option de Logic est de montrer la même valeur d’adresse quel que soit le sens de l’accès. Ca se défend...

Pour tout vous avouer, c’est grâce à cette visualisation que j’ai compris le mode opératoire à utiliser dans notre cas de figure. Décidément, cet analyseur logique, c’est vraiment de la balle. Allez faire un tour sur leur site de notre part. Et dites bien que vous venez de notre part ;)

Le mot de la fin

Ce qu’il faut retenir de tout cela, c’est qu’il y a une petite gymnastique à faire pour déterminer les commandes à envoyer à l’interface USB/I2C pour obtenir un trafic donné au niveau I2C. Ce n’est pas juste un bridge transparent, à l’instar des interfaces USB/RS232 par exemple, pour qui ce qu’on envoie d’un côté ressort tel quel (en termes de données) de l’autre.

Dans notre cas l’interface génère d’elle-même les deux séquences interrogation et lecture à partir de la commande unique qu’on lui donne. On ne peut donc pas l’utiliser pour tester depuis le PC la séquence de code qui va ensuite être compilée pour le micro-contrôleur.

Cela n’en retire cependant aucun intérêt, car associée à Docklight et éventuellement à un analyseur logique, elle permet très facilement d’explorer la mise en oeuvre d’un dispositif I2C avant de se lancer dans l’écriture du code embarqué. C’est quand même mieux que de se battre ensuite avec un JTAG et le debugger ;)

QLFSAV [1]


[1Que La Force Soit Avec Vous

Un message, un commentaire ?

modération a priori

Attention, votre message n’apparaîtra qu’après avoir été relu et approuvé.

Qui êtes-vous ?

Pour afficher votre trombine avec votre message, enregistrez-la d’abord sur gravatar.com (gratuit et indolore) et n’oubliez pas d’indiquer votre adresse e-mail ici.

Ajoutez votre commentaire ici

Ce champ accepte les raccourcis SPIP {{gras}} {italique} -*liste [texte->url] <quote> <code> et le code HTML <q> <del> <ins>. Pour créer des paragraphes, laissez simplement des lignes vides.