Le PCF8591

Le PCF8591
Extrait du PoBot
http://www.pobot.org
Le PCF8591
- Composants - Les entrées - Autres capteurs -
Date de mise en ligne : samedi 21 février 2009
Description :
Quelques récits d'expérimentation avec le PCF8591, un convertisseur analogique/numérique avec liaison I2C
PoBot
Copyright © PoBot
Page 1/8
Le PCF8591
Sommaire
• Plantons le décor
• Les outils
• Un petit aparté
• Retour au PCF
• Quelques jolis dessins
• Le mot de la fin
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 [/-Radeau-environnemental-.html], et on commence à en parler dans l'article de cette rubrique qui
présente l'électronique de contrôle. Son datasheet [IMG/pdf/pcf8591.pdf] 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
[IMG/pdf/P82B715_6.pdf], mais dont il ne sera pas question ici.
Si vous utilisez Fritzing pour concevoir un circuit électronique, retrouvez le composant PCF8591 sur cette page
[http://fritzomatic.quick2wire.com/component/ZeNqtkl1LwzAUhv_KoVcK6tb6ud2V1o-BboPpEMSLLDnWYGxKkqpD9t9
NmzFdlsEuvEo4p8-TNOf9jsy8wqgPUYElKk4PGa-iA4gMN6KtDx_HMM6uLk57MaT5uOkJMkPR9Jb1psZQU8Urw2XZ
dFoFKbTdP0X5oMX-fJ3mWbMMkix6tiunLfXtzPFSvToqaQoturClipeNNj6ze8uVSI1UusXjX0mDpINhN3C3tCRCFsDLqj
ZHrTLZ4OKduOMNLtmJO9ngjnfiTj0u9Hc3RLFPohAIYwq1XvJwV2sDM4QZJxoZ4JdBZQ8Qc6c-89Tx_6nPPXXyf-qLd
fVU64B7iAUx_ANB11Ul5vAhhY0mtoLeumCSpwGBjSkwYoi7VEfWZjWRuOsJststAiokffs7zNhL62iSBdCRplwIYiO-dro
zeLm9fLwPGCaf3NBXeLEG6cmgv3pR6NiS2zq3n-3rYb49o4WSdckc6IV7qvAlAE7dEMB2UWFJ0d3IKfycjx7ut5_tHgT
28jSDd8lw3zm8QE_z0PXHUvNANOyAFosfDqGQlQ%3D%3D/]
Copyright © PoBot
Page 2/8
Le PCF8591
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
[http://www.totalphase.com/products/beagle_ism/] et host adapters Aardvark
[http://www.totalphase.com/products/aardvark_i2cspi/]. 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
[http://www.totalphase.com/products/i2c_devkit/] 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é...
Copyright © PoBot
Page 3/8
Le PCF8591
...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 [http://www.fuh-edv.de/docklight/]. 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 ?
Copyright © PoBot
Page 4/8
Le PCF8591
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
Copyright © PoBot
Page 5/8
Le PCF8591
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
Copyright © PoBot
Page 6/8
Le PCF8591
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
[http://www.saleae.com/] 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]
Copyright © PoBot
Page 7/8
Le PCF8591
[1] Que La Force Soit Avec Vous
Copyright © PoBot
Page 8/8