« PC-I2C » : différence entre les versions

De Pensée Profonde - Club de robotique
Aller à la navigation Aller à la recherche
Aucun résumé des modifications
Aucun résumé des modifications
 
(14 versions intermédiaires par le même utilisateur non affichées)
Ligne 1 : Ligne 1 :
=Principe Général=
=Principe Général=
Afin de permettre la communication entre les différentes parties électroniques du robot nous avons choisi le bus I²C. Nous ne reviendrons pas ici sur le principe de ce bus tant les documentations à ce sujet sont nombreuses sur le net ([http://fr.wikipedia.org/wiki/I%C2%B2C au hasard]).  
Afin de permettre la communication entre les différentes parties électroniques du robot nous avons choisi le bus I²C. Nous ne reviendrons pas ici sur le principe de ce bus tant les documentations à ce sujet sont nombreuses sur le net ([http://fr.wikipedia.org/wiki/I%C2%B2C au hasard]).  


==Nos utilisations==
==Nos utilisations==
===Développement===
===Développement===
[[Image:Pci2c.jpg|Interface PC-I²C de type ELV|frame]]
<div style="float:right;">
<gallery>
Image:Pci2c.jpg|Interface PC-I²C de type ELV
</gallery>
</div>
Lors du développement des différentes cartes filles il nous est indispensable de disposer d'un moyen "sur" de communiquer sur le bus I²C. Nous avons donc cherché une interface utilisable facilement et ayant fait ses preuves. Il s'avère que de nombreuses interfaces existent et s'utilise très facilement avec Linux. Ces interfaces "communes" sont directement utilisables depuis les drivers du noyau. Leur gros défaut sont une consommation cpu élevée et leur interface parallèle (DB-25 is back !).
Lors du développement des différentes cartes filles il nous est indispensable de disposer d'un moyen "sur" de communiquer sur le bus I²C. Nous avons donc cherché une interface utilisable facilement et ayant fait ses preuves. Il s'avère que de nombreuses interfaces existent et s'utilise très facilement avec Linux. Ces interfaces "communes" sont directement utilisables depuis les drivers du noyau. Leur gros défaut sont une consommation cpu élevée et leur interface parallèle (DB-25 is back !).


Pour cette utilisation nous avons choisi une interface de type ELV. Disposant d'opto-coupleurs, le montage isole électriquement le PC de nos montages. Celui-ci est reconnu nativement par le noyau linux.
Pour cette utilisation nous avons choisi une interface de type ELV. Disposant d'opto-coupleurs, le montage isole électriquement le PC de nos montages. Celui-ci est reconnu nativement par le noyau linux.


===Embarqué===
===Embarqué===
Ligne 20 : Ligne 24 :
==Nos développements==
==Nos développements==
===USB-I²C v1===
===USB-I²C v1===
[[Image:Usb-i2c.jpg|Interface USB-I²C v1 en cours d'assemblage|frame]]
<div style="float:right;">
<gallery>
Image:Usb-i2c.jpg|Interface USB-I²C v1 en cours d'assemblage
Image:Usb-i2c-2.jpg|Interface USB-I²C v1
</gallery>
</div>
Cette première interface utilise un PIC 18F4550. Celui-ci intègre un port USB et un port I²C, un cible de choix donc. En pratique l'utilisation de l'USB et d'une émulation du CDC provoque un charge cpu importante. Dés lors il devient difficile d'assurer une fiabilité optimale ...
Cette première interface utilise un PIC 18F4550. Celui-ci intègre un port USB et un port I²C, un cible de choix donc. En pratique l'utilisation de l'USB et d'une émulation du CDC provoque un charge cpu importante. Dés lors il devient difficile d'assurer une fiabilité optimale ...
De plus cette première version ne propose pas d'isolation entre PC et circuit I²C.
* En cas de problème (court-circuit, surtension ...) les risques sont importants de part et d'autre.
* Il n'est pas possible d'avoir de différence de potentiel entre les 2 circuits.
<br clear="all" />
<br clear="all" />


===USB-I²C v2===
===USB-I²C v2===
<div style="float:right;">
<gallery>
Image:Usb-i2c-v2.jpg|Interface USB-I²C v2
</gallery>
</div>
Cette seconde interface utilise un PIC 18F. Ici nul besoin d'USB natif : le support de l'USB et du CDC sont assurés par un composant spécifique. Le PIC ne voit alors qu'un port série classique. Ainsi libéré il ne s'occupe que de l'interprétation/transcription du protocole série vers I²C.
Cette seconde interface utilise un PIC 18F. Ici nul besoin d'USB natif : le support de l'USB et du CDC sont assurés par un composant spécifique. Le PIC ne voit alors qu'un port série classique. Ainsi libéré il ne s'occupe que de l'interprétation/transcription du protocole série vers I²C.


Ligne 31 : Ligne 49 :
* petite taille : généralement tous les composants sont intégrés à la prise USB
* petite taille : généralement tous les composants sont intégrés à la prise USB
* aucun développement : plug and play :)
* aucun développement : plug and play :)
Fonctionnalité intéressante : une isolation totale entre PC et circuit I²C. En effet un couple d'optocoupleur assure la communication entre les 2 circuits.<br />
Quelques défauts:
* prend plus de place
* difficile de toujours trouver le même modèle de  câble USB<=>RS232
<br clear="all" />
<br clear="all" />


===USB-I²C v3===
Cette troisième version de l'interface utilise un PIC 24. Encore en cours d'étude, cette version signe un retour à l'USB natif du PIC. La puissance supplémentaire des PIC 24 et une version plus aboutie de l'USB devrait permettre une meilleure émulation du CDC.
===Le Protocole===
Une fois connectée l'adaptateur apparait comme un nouveau port com. Il est dés lors possible de l'ouvrir comme un port classique afin d'y envoyer/recevoir des données.
Le protocole utilise un jeu de caractères volontairement limité pour les commandes et les données/adresses. De plus les données ne sont pas envoyées "brutes" mais en format ASCII. Ainsi pour envoyer la valeur "42" nous envoyons 2 caractères ASCII : le 4 puis le 2. Cela permet de différencier plus facilement les données réelles des données pratiques (adresse, commande ...) et de s'affranchir de pas mal de problèmes de transmission.
{| border="1" class="pBody"
|+ '''Jeu de caractère'''
|-
! width="100"  align="center" style="padding:2px 5px;background:lightgray"| Caractères
! width="800" align="center" style="padding:2px 5px;background:lightgray"| Fonction
|-
|align="center"| '''0-9 A-F''' ||align="center"| Codes hexa réservés aux valeurs. Toujours en majuscule.
|-
|align="center"| '''S''' ||align="center"| Start I²C
|-
|align="center"| '''R''' ||align="center"| ReStart I²C
|-
|align="center"| '''Q''' ||align="center"| Stop I²C
|-
|align="center"| '''K''' ||align="center"| Reset de la carte
|-
|align="center"| '''O''' ||align="center"| Code de retour. Indique que tout s'est bien passé ('''O'''K)
|-
|align="center"| '''E''' ||align="center"| Code de retour. Signale une erreur. Normalement suivi de 2 chiffres précisant le code de l'erreur puis d'une chaine de caractères.
|-
|}
{| border="1" class="pBody"
|+ '''Exemples de communications simples'''
|-
! width="150"  align="center" style="padding:2px 5px;background:lightgray"| Caractères
! width="50"  align="center" style="padding:2px 5px;background:lightgray"| Sens
! width="700" align="center" style="padding:2px 5px;background:lightgray"| Fonction
|-
|align="left"| '''&nbsp;S40D7Q''' ||align="center"| PC->I2C ||align="left"| <Start> <Adresse Slave 0x40 paire=écriture> <octet de donnée D7> <Stop>
|-
|align="left"| '''&nbsp;S40D705Q ''' ||align="center"| PC->I2C ||align="left"| <Start> <Adresse Slave 0x40 paire=écriture> <octet de donnée D7> <octet de donnée 05> <Stop>
|-
|align="left"| '''&nbsp;S40D7R4205Q ''' ||align="center"| PC->I2C ||align="left"| <Start> <Adresse Slave 0x40 paire=écriture> <octet de donnée D7> <Restart> <Adresse Slave 0x42 paire=écriture> <octet de donnée 05> <Stop>
|-
|align="left"| '''&nbsp;S4102 ''' ||align="center"| PC->I2C ||align="left"| <Start> <Adresse Slave 0x40 impaire=lecture> <attente de 2 octets en réception>
|-
|align="left"| '''&nbsp;R4102C5 ''' ||align="center"| I2C->PC ||align="left"| Réponse suite à une lecture de la carte 41. Le premier octet est 02 (2) et le second C5 (197)
|-
|align="left"| '''&nbsp;O41 ''' ||align="center"| I2C->PC ||align="left"| Réponse suite à une écriture de la carte 41.
|-
|align="left"| '''&nbsp;E00 Adresse invalide ''' ||align="center"| I2C->PC ||align="left"| Erreur 00 indiquant une adresse malformée.
|-
|}
Les erreurs sont envoyés au PC selon le format suivant: Exx YYYYYYYYY
* E est toujours présent. C'est le code de retour indiquant une erreur.
* xx correspond au code de l'erreur. Il est toujours sur 2 chiffres.
* YYYYYYY correspond à un message plus clair pour la lecture.
{| border="1" class="pBody"
|+ '''Liste des messages d'erreur'''
|-
! width="50"  align="center" style="padding:2px 5px;background:lightgray"| Code
! width="300" align="center" style="padding:2px 5px;background:lightgray"| Message complet
|-
|align="center"| '''E00''' ||align="center"| E00 Adresse invalide
|-
|align="center"| '''E01''' ||align="center"| E01 Probleme envoi adresse
|-
|align="center"| '''E02''' ||align="center"| E02 Probleme envoi donnees
|-
|align="center"| '''E03''' ||align="center"| E03 Char inconnu
|-
|align="center"| '''E04''' ||align="center"| E04 Kill PIC
|-
|}
Chaque "Start/Restart" émis donne lieu à une réponse de l'adaptateur.
* pour chaque réponse une ligne est renvoyée.
* dans le cas d'une écriture le caractère de status peut prendre les valeurs suivantes:
** Oxx : transmission OK. xx correspond à l'adresse de la carte
** ExxYYYYYYYYY : Erreur lors de la transmission.a
* dans le cas d'une lecture le caractère de status prend la valeur "R". L'adresse est suivi des octets renvoyés par la carte fille: "R40xxyyzz" par exemple.
** chaque octet est représenté par 2 caractères (hexa).
<br clear="all" />


=Liens=
=Liens=

Version actuelle datée du 10 décembre 2009 à 21:12

Principe Général

Afin de permettre la communication entre les différentes parties électroniques du robot nous avons choisi le bus I²C. Nous ne reviendrons pas ici sur le principe de ce bus tant les documentations à ce sujet sont nombreuses sur le net (au hasard).


Nos utilisations

Développement

Lors du développement des différentes cartes filles il nous est indispensable de disposer d'un moyen "sur" de communiquer sur le bus I²C. Nous avons donc cherché une interface utilisable facilement et ayant fait ses preuves. Il s'avère que de nombreuses interfaces existent et s'utilise très facilement avec Linux. Ces interfaces "communes" sont directement utilisables depuis les drivers du noyau. Leur gros défaut sont une consommation cpu élevée et leur interface parallèle (DB-25 is back !).

Pour cette utilisation nous avons choisi une interface de type ELV. Disposant d'opto-coupleurs, le montage isole électriquement le PC de nos montages. Celui-ci est reconnu nativement par le noyau linux.

Embarqué

Dans le cadre de l'utilisation embarquée nous devons disposer d'un système capable de fonctionner sur n'importe quel OS et sur port USB. Nous avons donc décidé de développer notre propre interface USB-I²C. Celle-ci est vue par le PC comme un simple port COM grace au CDC.
La communication se fait selon un protocole visant à maximiser la compatibilité et la lisibilité. Un simple terminal permet d'envoyer et de recevoir des données.

Nos développements sont détaillés ci-dessous.


Nos développements

USB-I²C v1

Cette première interface utilise un PIC 18F4550. Celui-ci intègre un port USB et un port I²C, un cible de choix donc. En pratique l'utilisation de l'USB et d'une émulation du CDC provoque un charge cpu importante. Dés lors il devient difficile d'assurer une fiabilité optimale ...

De plus cette première version ne propose pas d'isolation entre PC et circuit I²C.

  • En cas de problème (court-circuit, surtension ...) les risques sont importants de part et d'autre.
  • Il n'est pas possible d'avoir de différence de potentiel entre les 2 circuits.


USB-I²C v2

Cette seconde interface utilise un PIC 18F. Ici nul besoin d'USB natif : le support de l'USB et du CDC sont assurés par un composant spécifique. Le PIC ne voit alors qu'un port série classique. Ainsi libéré il ne s'occupe que de l'interprétation/transcription du protocole série vers I²C.

De nombreux composants existent pour réaliser la conversion USB<=>RS232. Le plus connus est sans conteste le FT232 de FTDI. Cependant il existe une solution beaucoup plus simple et économique : utiliser un convertisseur déjà assemblé ! On trouve par exemple des câbles USB<=>RS22 destinés aux téléphones portables. L'utilisation de de ce genre de câble possède de nombreux avantages :

  • économique: moins de 4€
  • petite taille : généralement tous les composants sont intégrés à la prise USB
  • aucun développement : plug and play :)

Fonctionnalité intéressante : une isolation totale entre PC et circuit I²C. En effet un couple d'optocoupleur assure la communication entre les 2 circuits.

Quelques défauts:

  • prend plus de place
  • difficile de toujours trouver le même modèle de câble USB<=>RS232



USB-I²C v3

Cette troisième version de l'interface utilise un PIC 24. Encore en cours d'étude, cette version signe un retour à l'USB natif du PIC. La puissance supplémentaire des PIC 24 et une version plus aboutie de l'USB devrait permettre une meilleure émulation du CDC.


Le Protocole

Une fois connectée l'adaptateur apparait comme un nouveau port com. Il est dés lors possible de l'ouvrir comme un port classique afin d'y envoyer/recevoir des données.

Le protocole utilise un jeu de caractères volontairement limité pour les commandes et les données/adresses. De plus les données ne sont pas envoyées "brutes" mais en format ASCII. Ainsi pour envoyer la valeur "42" nous envoyons 2 caractères ASCII : le 4 puis le 2. Cela permet de différencier plus facilement les données réelles des données pratiques (adresse, commande ...) et de s'affranchir de pas mal de problèmes de transmission.

Jeu de caractère
Caractères Fonction
0-9 A-F Codes hexa réservés aux valeurs. Toujours en majuscule.
S Start I²C
R ReStart I²C
Q Stop I²C
K Reset de la carte
O Code de retour. Indique que tout s'est bien passé (OK)
E Code de retour. Signale une erreur. Normalement suivi de 2 chiffres précisant le code de l'erreur puis d'une chaine de caractères.


Exemples de communications simples
Caractères Sens Fonction
 S40D7Q PC->I2C <Start> <Adresse Slave 0x40 paire=écriture> <octet de donnée D7> <Stop>
 S40D705Q PC->I2C <Start> <Adresse Slave 0x40 paire=écriture> <octet de donnée D7> <octet de donnée 05> <Stop>
 S40D7R4205Q PC->I2C <Start> <Adresse Slave 0x40 paire=écriture> <octet de donnée D7> <Restart> <Adresse Slave 0x42 paire=écriture> <octet de donnée 05> <Stop>
 S4102 PC->I2C <Start> <Adresse Slave 0x40 impaire=lecture> <attente de 2 octets en réception>
 R4102C5 I2C->PC Réponse suite à une lecture de la carte 41. Le premier octet est 02 (2) et le second C5 (197)
 O41 I2C->PC Réponse suite à une écriture de la carte 41.
 E00 Adresse invalide I2C->PC Erreur 00 indiquant une adresse malformée.


Les erreurs sont envoyés au PC selon le format suivant: Exx YYYYYYYYY

  • E est toujours présent. C'est le code de retour indiquant une erreur.
  • xx correspond au code de l'erreur. Il est toujours sur 2 chiffres.
  • YYYYYYY correspond à un message plus clair pour la lecture.
Liste des messages d'erreur
Code Message complet
E00 E00 Adresse invalide
E01 E01 Probleme envoi adresse
E02 E02 Probleme envoi donnees
E03 E03 Char inconnu
E04 E04 Kill PIC


Chaque "Start/Restart" émis donne lieu à une réponse de l'adaptateur.

  • pour chaque réponse une ligne est renvoyée.
  • dans le cas d'une écriture le caractère de status peut prendre les valeurs suivantes:
    • Oxx : transmission OK. xx correspond à l'adresse de la carte
    • ExxYYYYYYYYY : Erreur lors de la transmission.a
  • dans le cas d'une lecture le caractère de status prend la valeur "R". L'adresse est suivi des octets renvoyés par la carte fille: "R40xxyyzz" par exemple.
    • chaque octet est représenté par 2 caractères (hexa).



Liens

Quelques liens vers des sites ou des documents traitant de la réalisation d'interfaces PC/ I²C.