BUS CAN HOME PAGE

 

 

 

Liens:

Une très bonne page CAN à voir : oberle.org/can-index
enseirb.fr/~kadionik/formation/canbus
CAN in Automation (CiA), multiples documents : can-cia.de
Linux CAN-bus driver project : wanadoo.nl/arnaud
Controller Area Network - Available Devices : mjschofield.com/devices
Présentation du 82c250 : lsc.cemif.univ-evry.fr:8080
Le réseau CAN et le protocole CAN Open : a2v.fr/program/canopen

 

can2spec.pdf

can-rapport.pdf

INTRODUCTION

Le CAN (Controller Area Network) est un bus de communication série développé à la fin des années 80 par l'entreprise allemande Robert Bosch. L'objectif était de fournir à l'industrie automobile un bus peu coûteux pour l'électronique embarquée des automobiles, comme alternative aux encombrants et complexes câbles des modèles de l'époque.

Aujourd'hui, l'efficacité et la robustesse de ce protocole l'ont amené à être utilisé dans de nombreuses autres applications industrielles, en particulier celles nécessitant un débit important jusqu'à 1 Mbits/s avec un très faible taux d'erreur.

Le CAN est aussi devenu un standard international reconnu par l'ISO.

De nombreux contrôleurs CAN sont aujourd'hui disponibles chez la plupart des fabricants, qui proposent aussi des versions de leurs microcontrôleurs avec des contrôleurs CAN intégrés. De nombreux packages de développement existent aussi sur le marché.


Ce site présente un exemple d'implémentation d'un bus CAN reliant différentes plateformes : une carte PowerPC 403 avec sa carte contrôleur CAN, un PC utilisant aussi une carte contrôleur CAN, et des noeuds autonomes.

Cet environnement est le résultat du développement :

  • de plusieurs cartes mettant en oeuvre des contrôleurs CAN,
  • des librairies permettant d'utiliser ces cartes et de développer des applications utilisant le bus CAN,
  • d'applications de développement et de démonstration.

 

I) LE PROTOCOL CAN
.1 Origines et utilisations du CAN.
1.1.1 Le CAN dans l'industrie automobile.
1.1.2 Autres applications industrielles.
1.1.3 Perspectives.

1.2 Le CAN dans le modèle ISO/OSI.
1.2.1 Le modèle ISO/OSI.
1.2.1.1 La couche physique.
1.2.1.2 La couche liaison.
1.2.1.3 La couche réseau.
1.2.1.4 La couche transport.
1.2.1.5 La couche session.
1.2.1.6 La couche présentation.
1.2.1.7 La couche application.

1.3 Fonctionnement du CAN.
1.3.1 Principes.
1.3.1.1 "Identifiers".
1.3.1.2 Notions de bits dominants / récessifs.
1.3.2 Fonctionnement détaillé de l'arbitrage.
1.3.3 Transmission des messages.
1.3.3.1 Protocoles 2.0A et 2.0B.
1.3.3.2 Types de messages.
1.3.4 Format des trames de données.
1.3.4.1 Start of frame.
1.3.4.2 Arbitration field.
1.3.4.3 Control field.
1.3.4.4 Data field.
1.3.4.5 CRC field.
1.3.4.6 ACK field.
1.3.4.7 End of frame.
1.3.5 Bit-stuffing.
1.3.6 Détection et gestion des erreurs.
1.3.6.1 Types d'erreurs.
1.3.6.2 Trames d'erreurs.
1.3.6.3 Gestion et confinement des erreurs.
1.3.6.4 Probabilité de détection des erreurs.

Le CAN est un protocole de communication série qui supporte efficacement le contrôle en temps réel de systèmes distribués tels qu'on peut en trouver dans les automobiles, et ceci avec un très haut niveau d'intégrité au niveau des données.

Le CAN a été standardisé par l'ISO dans les normes 11898 pour les applications à hauts débits et ISO 11519 pour les applications à bas débits.

1.1 Origines et utilisations du CAN.

1.1.1 Le CAN dans l'industrie automobile.

Pour satisfaire les exigences de plus en plus importantes du client en matière de sécurité et de confort, et pour se conformer aux les lois de réduction de la pollution et de la consommation de plus en plus drastiques, l'industrie automobile a développé de nombreux systèmes électroniques : systèmes anti-patinage, contrôle électronique du moteur, de l'air climatisé, fermeture centralisée des portes, etc.

La complexité de ces systèmes et la nécessité d'échanger des données entre eux signifient de plus en plus de câbles. A côté du coût très important de ce câblage, la place qui lui est nécessaire pouvait le rendre tout simplement impossible. Enfin, le nombre croissant de connections et de câbles posait de sérieux problèmes de fiabilité et de réparation.

Bosch, un important équipementier automobile, a fournit la solution dans le milieu des années 80 avec le bus CAN. L'entreprise allemande a définit le protocole et a autorisé de nombreux autres fabricants à développer des composants compatibles CAN.

Avec le protocole CAN, les contrôleurs, capteurs et actionneurs communiquent entres eux sur deux câbles à une vitesse pouvant aller jusqu'à 1 Mbits/s.

1.1.2 Autres applications industrielles.

Les contrôleurs CAN sont physiquement petits, peu coûteux et entièrement intégrés. Ils sont utilisables à des débits importants, en temps réel et dans des environnements difficiles. Enfin, les transmissions ont un haut niveau de fiabilité. C'est pourquoi ils ont été utilisés dans d'autres industries que l'automobile et des applications utilisant le CAN sont aujourd'hui disponibles dans l'agriculture, la marine, le matériel médical, les machines textiles, etc.

1.1.3 Perspectives.

On apprend dans une enquête de la publication Electronics Weekly du 15 novembre 1995 que, dans le monde :

  • 5,5 millions de composants CAN ont été vendus en 1995,
  • plus de 3 millions de bus CAN installés dans des véhicules et 6 millions dans des applications non automobiles,
  • en 1999, 140 millions de composants CAN devraient avoir été vendus.

1.2 Le CAN dans le modèle ISO/OSI.

Le CAN étant un protocole réseau, il s'intègre dans la norme ISO/OSI (ISO : International Standards Organization, OSI : Open Systems Interconnection) qui définit 7 couches permettant de couvrir la totalité d'un protocole.

Les différentes couches définissent les services du protocole.

Le tableau suivant résume les couches utilisées par le protocole CAN.

 

Spécifications Couche OSI Implémentation
à spécifier par l'utilisateur Couche application Software embarqué ou non
Spécifications du protocole CAN Couche de communication de données Logical Link Control On-chip hardware
Medium Access Control
Couche physique Physical Signaling
Physical Medium Attachment
Medium Dependent Interface Off-chip hardware
  Transmission Medium
Couches OSI appliquées au CAN

1.2.1 Le modèle ISO/OSI

1.2.1.1 La couche physique.

La première couche du modèle a pour but de conduire les éléments binaires jusqu'à leur destination sur le support physique. Elle fournit les moyens matériels nécessaires à l'activation, au maintien et à la désactivation de ces connections physiques.

Cette couche gère la représentation du bit (codage, timing, synchronisation), et définit les niveaux électriques, optiques,... des signaux ainsi que le support de transmission.

Le protocole CAN ne décrit que la représentation détaillée du bit (Physical Signalling), mais pas le moyen de transport et les niveaux des signaux de telles sorte qu'ils puissent être optimisés selon l'application.

1.2.1.2 La couche liaison.

Elle fournit les moyens fonctionnels nécessaires à l'établissement, au maintien et à la libération des connexions entres les entités du réseau. Cette couche (aussi appelée couche de communication de donnée, Data Link Layer) devra notamment corriger les erreurs qui ont pu se produire au premier niveau (même s'il est impossible de corriger toutes les erreurs).

Le protocole CAN décrit entièrement cette couche.

La couche liaison est subdivisée en deux sous-couches. La sous-couche LLC (Logical Link Control) effectue :

  • le filtrage des messages,
  • la notification des surcharges (overload),
  • la procédure de recouvrement des erreurs.

La sous-couche MAC (Medium Access Control), qui est le coeur du protocole CAN, effectue :

  • la mise en trame du message,
  • l'arbitrage,
  • l'acquittement,
  • la détection des erreurs,
  • la signalisation des erreurs.

1.2.1.3 La couche réseau.

La couche réseau doit permettre d'acheminer correctement les paquets d'informations jusqu'à l'utilisateur final, en passant par des passerelles qui interconnectent plusieurs réseaux entre eux. Elle assure le contrôle des flux (pour tenir des temps de réponse acceptables), le routage des paquets, et l'adressage (pour l'ensemble des machines du monde !).

C'est aussi ici qu'interviennent les deux philosophies concurrentes des réseaux:

  • Le mode connecté, à la base du protocole X.25, où l'émetteur et le récepteur se mettent d'accord sur un comportement commun.
  • Le mode non connecté, à la base du protocole IP (Internet Protocol), sans contraintes pour l'émetteur vis-à-vis du récepteur.

Cette couche est vide dans le protocole CAN.

1.2.1.4 La couche transport.

La couche transport est le dernier niveau qui s'occupe de l'acheminement des informations. Elle doit optimiser la qualité de la transmission, notamment avec des outils de détection d'erreurs et des algorithmes de renvoi des messages perdus.

Cette couche est vide dans le protocole CAN.

1.2.1.5 La couche session.

La couche de session permet aux différents éléments du réseau d'organiser et de synchroniser leur dialogue. Il faut en effet s'assurer si l'on veut émettre de l'information qu'un récepteur est là pour récupérer ce qui a été envoyé.

Cette couche est vide dans le protocole CAN.

1.2.1.6 La couche présentation.

Cette couche se charge de la syntaxe des informations que se communiquent les éléments du réseau, c'est-à-dire que ces éléments utilisent bien un langage commun pour transférer des données.

Cette couche est vide dans le protocole CAN.

1.2.1.7 La couche application.

C'est la dernière couche du modèle OSI. Elle donne aux applications le moyen d'accéder aux couches inférieures.

Cette couche a été normalisée en 1987 au sein d'une structure globale : la structure de la couche application, ou ALS (Application Layer Structure). Elle détermine comment différentes applications vont pouvoir coexister et utiliser des modules communs. De très nombreuses normes ont été définies sur cette base.

Cette couche n'est bien sûr pas vide pour le protocole CAN, mais sa spécification est laissée à l'utilisateur.

1.3 Fonctionnement du CAN.

1.3.1 Principes.

1.3.1.1 "Identifiers".

Les trames de données transmises par un noeud sur le bus ne contiennent ni une quelconque adresse du noeud expéditeur ou du noeud destinataire. C'est plutôt le contenu du message, sa signification (son "meaning") qui est précisé par un identificateur (ID). Chaque noeud recevant un message regarde si celui-ci est intéressant pour lui grâce à l'ID. Si c'est le cas, il le traite, sinon, il l'ignore.

Cet unique ID indique aussi la priorité des messages. Plus la valeur est faible, plus le message sera prioritaire. Si deux noeuds ou plus cherchent à avoir accès au bus en même temps, c'est celui de plus haute priorité qui gagne. Les messages de priorité inférieure seront automatiquement retransmis lorsque le bus sera libre.

1.3.1.2 Notions de bits dominants / récessifs.

La norme CAN ne spécifie pas de couche physique. Différentes implémentations sont donc possibles : filaire, HF, infrarouge, par fibre optique, etc.

Mais toute implémentation doit respecter le principe des bits dominants / récessifs. Chaque noeud doit pouvoir présenter sur le bus un bit appelé dominant (0 logique) et un bit appelé récessif (1 logique). Les implémentations doivent aussi respecter la règle suivante : si 2 noeuds présentent des niveaux logiques différents, le bit dominant s'impose.

1.3.2 Fonctionnement détaillé de l'arbitrage.

Dans un système typique, certains paramètres vont changer plus rapidement que d'autres. Ce sera par exemple la vitesse d'un moteur, tandis qu'un paramètre plus lent pourra être la température de l'habitacle.

Il est donc naturel que les paramètres qui varient le plus soient transmis le plus souvent et par conséquent doivent avoir une plus grande priorité.

Dans les applications en temps réel, ceci nécessite non seulement une vitesse de transmission importante, mais aussi un mécanisme d'allocation du bus efficace qui soit capable de traiter les cas où plus d'un noeud cherchent à transmettre en même temps.

Pour déterminer la priorité des messages, le CAN utilise la méthode CSMA/CD (Carrier Sense, Multiple Access with Collision Detect) avec la capacité supplémentaire de l'arbitrage non destructif (Non-Destructive Bitwise Arbitration) afin d'offrir une disponibilité maximale du bus.

Comme on l'a vu précédemment, la priorité d'un message est déterminée par la valeur de son ID. La valeur de chaque ID, et donc la priorité de chaque type de messages, est assignée durant la conception du système. Un certain nombre de standards ont été développés selon les domaines d'utilisation du bus CAN pour fixer la priorité des ID et permettre une interopératibilité des différents équipements.

Tout conflit de bus est résolu par le mécanisme du "ET cablé", c'est-à-dire qu'un état dominant écrase un état récessif. Concrètement, si plusieurs noeuds débutent leur trame en même temps, le premier qui présente un bit récessif alors qu'au moins un autre présente un bit dominant perd l'arbitrage (dans la trame, l'ID commence par le bit de poids fort).

Exemple de perte d'arbitrage : le noeud perd l'arbitrage au 11ème bit.
Exemple de perte d'arbitrage : le noeud perd l'arbitrage au 11ème bit.

Tout ce passe donccomme si le message de plus haute priorité était le seul à être transmis. Lorsqu'un noeud perd l'arbitrage, il devient automatiquement un récepteur du message en cours de transmission, et il n'essaiera de retransmettre son message que lorsque le bus sera à nouveau libre.

L'avantage d'un tel système est une utilisation meilleure du bus qu'avec d'autres mécanismes, tels que le mécanisme de "fixed time schedule allocation" du Token ring ou l'arbitrage destructif de l'Ethernet.

1.3.3 Transmission des messages.

L'information sur le bus est envoyée sous la forme de messages (Appelés aussi trames ou "frames".) au format fixé. Quand le bus est libre, n'importe quel noeud peut commencer à envoyer un message.

1.3.3.1 Protocoles 2.0A et 2.0B.

Le protocole CAN 2.0 comporte deux sous-spécifications qui diffèrent uniquement au niveau de la longueur de l'ID. La version 2.0A définit des ID de 11 bits et la version 2.0B des ID de 29 bits. On appelle ces trames respectivement des trames standards ("Standard Frames") et des trames étendues ("Extended Frames").

Le format standard est équivalent au format tel qu'il était décrit dans la version 1.2 du protocole. Le format étendu est une nouvelle fonctionnalité du protocole 2.0. Pour permettre le développement de contrôleurs assez simple, le support complet du format étendu n'est pas requis pour être conforme au protocole 2.0. Les contrôleurs sont considérés conforme au protocole 2.0 s'ils respectent les deux conditions suivantes :

  • Le format standard doit être totalement supporté.
  • Ils doivent être capables de recevoir des trames étendues, mais sans forcément être capable de les traiter. Elles ne doivent seulement pas être détruites.

On se référera à la description du protocole CAN en 10.3.1.2 pour le détail du fonctionnement de la compatibilité du CAN 2.0B par rapport au 2.0A.

1.3.3.2 Types de messages.

Quatre types de messages peuvent être transmis :

  • Les Data Frames sont utilisées pour transporter des données sur le bus. Leur format est détaillé ci-après.
  • Les Remote Frames sont utilisées par un noeud pour demander la transmission d'une Data Frame par d'autres noeuds avec le même ID. Deux éléments distinguent cette trame d'une trame de données normale : elles ne contient aucun bit de données et son bit RTR est récessif.
  • Les Error Frames sont transmises par un noeud ayant détecté une erreur. Leur format et utilisation est détaillée par la suite.
  • Les Overload Frames sont utilisées pour produire un délai entre deux Data ou Remote Frames successives. Voir le protocole CAN en 10.3.4.

1.3.4 Format des trames de données.

Les trames de données (Data Frames) sont composées de 7 parties détaillées ci-après.

Le format est indiqué pour des trames respectant le protocole 2.0A. On se référera à la documentation du protocole CAN pour le format des trames 2.0B.

Data frame.
Data frame.

1.3.4.1 Start of frame.

Le bit Start of frame (SOF) marque le début d'une Data Frame ou d'une Remote frame. C'est un unique bit dominant.

Un noeud ne peut bien sûr débuter une transmission que si le bus est libre.

Ensuite, tous les autres noeuds se synchronisent sur SOF du noeud ayant commencé une transmission.

1.3.4.2 Arbitration field

Arbitration field : format standard.
Arbitration field : format standard.

L'Arbitration field est constitué de l'identifieur et du bit RTR.

L'identificateur (ID) permet d'identifier le message. Il est transmis dans l'ordre ID10 à ID0, où ID0 est le bit le moins significatif.

Le bit RTR (Remote Transmission Request) caractérise les Remote Frames. Il est dominant dans les Data Frames et récessif dans les Remote Frames.

1.3.4.3 Control field

Control field.
Control field.

Le Control field est composé de 6 bits. Les 2 premiers sont des bits réservés et les 4 suivants constituent le Data length code (DLC). Le DLC indique le nombre d'octets du Data field. La valeur du DLC est forcément comprise entre 0 et 8, soit 9 valeurs. 4 bits dominants (0000) correspondent à la valeur 0 pour le DLC, tandis que 1 bit récessif et 3 bits dominant (1000) correspondent à la valeur 8.

1.3.4.4 Data field

Ce sont les données transmises par la Data frame. Il peut contenir de 0 à 8 octets, où chaque octet est transmis avec le bit de poids fort en premier.

1.3.4.5 CRC field

CRC field.
CRC field.

Le CRC field est composé de la séquence de CRC sur 15 bits suivi du CRC delimiter (1 bit récessif).

La séquence de CRC (Cyclic redundancy code) permet de vérifier l'intégrité des données transmises. Les bits utilisés dans le calcul du CRC sont ceux du SOF, de l'Arbitration field, du Control field et du Data field.

1.3.4.6 ACK field

Le ACK field est composé de 2 bits, l'ACK Slot et le ACK Delimiter (1 bit récessif). Le noeud en train de transmettre envoie un bit récessif pour le ACK Slot. Un noeud ayant reçu correctement le message en informe le transmetteur en envoyant un bit dominant pendant le ACK Slot : il acquitte le message.

1.3.4.7 End of frame

Chaque Data frame et Remote frame est terminée par une séquence de 7 bits récessifs.

1.3.5 Bit-stuffing

Pour les Data Frames et les Remote Frames, les bits depuis le Start of frame jusqu'à la séquence de CRC sont codés selon la méthode du bit stuffing. Quand un transmetteur détecte 5 bits consécutifs de même valeur dans les bits à transmettre, il ajoute automatiquement un bit de valeur opposée.

Exemple de bit stuffing.
Exemple de bit stuffing.

1.3.6 Détection et gestion des erreurs.

Le CAN a été créé pour opérer dans des environnements difficiles et c'est pourquoi il comprend de nombreux mécanismes de détection d'erreur.

1.3.6.1 Types d'erreurs

Le CAN implémente cinq mécanismes de détection des erreurs, 2 au niveau bits (le "bit monitoring" et le "bit stuffing") et 3 au niveau messages (vérification du CRC, de la forme des trames et de l'acquittement).

Ces cinq types d'erreurs différents qui peuvent être détectée par un noeud sont :

Bit error
Un noeud envoyant un bit sur le bus regarde aussi en même temps les bits qu'il reçoit (Bit monitoring). Il considère comme une erreur de bit lorsque le bit envoyé est différent du bit reçu, à l'exception de l'envoi d'un bit récessif durant l'arbitrage (cas de la perte d'arbitrage) ou pendant le ACK Slot (trame acquittée).
Stuff error
Le noeud détecte une erreur de stuffing lorsqu'il reçoit 6 bits consécutifs de même valeur dans une partie d'un message qui devrait être codé avec la méthode du bit stuffing.
CRC error
Une erreur de CRC est détectée lorsque le CRC calculé par un récepteur est différent de la valeur du CRC contenu dans la trame.
Form error
Une "Form error" est détectée lorsqu'un bit qui devrait être à une certaine valeur est à une valeur différente (un délimiteur par exemple).
ACK error
Le transmetteur détecte une erreur d'acquittement lorsqu'il ne reçoit pas de bit dominant pendant le ACK Slot.

1.3.6.2 Trames d'erreurs

Une trame d'erreur est constituée de deux parties. La première est formée par la superposition des différents "Error flags" mis par les noeuds du bus. La seconde partie est un délimiteur.

Un noeud qui détecte une erreur la signale en envoyant un Error flag. Celui-ci viole la règle du bit stuffing (6 bits dominants consécutifs) et par conséquent, tous les autres noeuds détectent aussi une erreur et commencent à envoyer un Error flag. La séquence de bits dominants qui existe alors sur le bus est le résultat de la superposition de plusieurs Error flags, et sa longueur varie entre 6 et 12 bits.

Il existe deux types d'Error flags :

Active error flag
6 bits dominants consécutifs.
Passive error flag
6 bits récessifs consécutifs, jusqu'à ce qu'ils soient écrasés par des bits dominants.

L'Error delimiter est composé de 8 bits récessifs. En fait, après avoir transmis son Error flag, chaque noeuds envoie des bits récessifs et observe le bus jusqu'à ce qu'il détecte un bit récessif, après quoi il envoie encore 7 bits récessifs supplémentaires.

1.3.6.3 Gestion et confinement des erreurs

Le confinement des erreurs est un mécanisme permettant de faire la différence entre des erreurs temporaires ou permanentes. Les erreurs temporaires peuvent être causées par des glitchs par exemple, tandis que des erreurs permanentes sont en général due à de mauvaises connections ou à des composants défaillants.

Ce système va permettre d'enlever un noeud défaillant du bus qui sinon aurait pu perturber les autres noeuds.

Un noeud peut être dans trois états : error-active, error-passive ou bus-off.

  1. Un noeud en mode d'erreur actif (error-active) peut prendre part normalement dans la communication sur le bus. Il transmettra un Active error flag s'il détecte une condition d'erreur.
  2. Un noeud en mode d'erreur passif (error-passive) peut prendre part dans la communication, mais s'il détecte une condition d'erreur sur le bus, il transmettra un Passive error flag. Ce mode indique un noeud à problèmes.
  3. Un noeud en mode bus-off n'est pas autorisé à avoir une quelconque influence sur le bus.

Deux compteurs d'erreurs sont implémentés dans chaque noeud : celui des erreurs en transmission (Transmit error count) et celui des erreurs en réception (Receive error count).

Les grandes règles de modifications des compteurs d'erreurs sont les suivantes. Elles sont détaillées avec leurs exceptions dans le protocole CAN en 5.2.

  • Lorsqu'un récepteur détecte une erreur, son Receive error count est augmenté de 1.
  • Lorsqu'un transmetteur envoie un Error flag, son Transmit error count est augmenté de 8.
  • Après une transmission réussie, le Transmit error count est diminué de 1.
  • Après une réception réussie, le Receive error count est diminué de 1.

Un noeud est en mode error-active si ses deux compteurs d'erreurs sont inférieurs à 127. Il est en error-passive si l'un des deux est compris entre 128 et 256. Si le Transmit error count est supérieur à 256, le noeud est en bus-off.

1.3.6.4 Probabilité de détection des erreurs

Le protocole CAN est extrêmement fiable au de niveau de la détection des erreurs.

Les erreurs survenants sur tous les noeuds sont détectables à 100 %.

Au niveau des erreurs survenants sur un seul noeud, rien que la vérifcation du CRC peut permettre de détecter jusqu'à 5 erreurs de bits avec une probabilité de 100 % . La probabilité qu'une erreur ne soit pas détectée par le mécanisme du CRC est de 3.10-5.

Avec tous les autres mécanismes de détection, la vraie valeur est de 10-11.

 

II) Les Composants CAN
2.1 Le P82C150.
2.1.1 Configuration du SLIO
2.1.1.1 Choix de l'ID
2.1.1.2 Calibration
2.1.2 Utilisation du 82C150
2.1.2.1 Format des trames
2.1.2.2 Les registres

2.2 Le PCA82C250
2.2.1 Codage physique des bits
2.2.2 Débit

2.3 Le SJA1000
2.3.1 Présentation
2.3.1.1 Caractéristiques
2.3.2 Le mode BasicCAN
2.3.3 Le mode PeliCAN
2.3.4 Les principaux registres
2.3.4.1 Le registre MODE
2.3.4.2 Le registre COMMAND
2.3.4.3 Le registre STATUS
2.3.4.4 Le registre INTERRUPT
2.3.4.5 Les registres BUS_TIMING0 et BUS_TIMING1
2.3.5 Le buffer de réception
2.3.6 Le buffer d'émission
2.3.7 Le filtre d'acceptation

2.1 Le P82C150

Le P82C150 est un CAN Serial Linked I/O (SLIO), un noeud CAN sans intelligence.

Ce périphérique inclut un contrôleur CAN et 16 pins d'entrées/sorties. Son contrôleur CAN respecte les spécifications 2.0A et 2.0B (en mode passif) du protocole CAN. Il inclut un oscillateur interne l'affranchissant d'une horloge externe.

Ses 16 pins d'E/S sont individuellement configurables en mode analogique ou digital. Il est ainsi possible d'avoir jusqu'à 16 entrées digitales, avec la possibilité d'une transmission automatique d'un message au changement d'une des entrées. Le 82C150 intègre un ADC sur 10 bits, qu'il est possible de multiplexer sur 6 entrées. On peut aussi configurer jusqu'à 16 sorties 3 états ou 2 sorties quasi-analogiques (DPM, Discrete Pulse Modulation) avec une précision de 10 bits.

L'oscillateur interne limite le débit entre 20kbits/s et 125kbits/s. Cet oscillateur interne, un RC, implique aussi une procédure complexe de calibration au RESET du SLIO et ensuite régulièrement à l'utilisation. Ces deux limitations peuvent être dépassées en utilisant un oscillateur externe.

L'absence d'intelligence du SLIO oblige à le mettre sur un bus où un noeud plus "intelligent", typiquement un microcontrôleur sera capable de le configurer et de le commander.

2.1.1 Configuration du SLIO

2.1.1.1 Choix de l'ID

L'ID du 82C150 se fixe de façon hard. En fait, seuls 4 bits (sur les 11) sont paramètrables. Ceci limite en pratique le nombre de SLIO sur un réseau à 16.

2.1.1.2 Calibration

Afin de minimiser l'encombrement des systèmes à base de 82C150, celui-ci ne nécessite pas d'horloge externe grâce à l'utilisation d'un circuit RC interne. Ce circuit se calibre grâce à certaines trames qu'il recoit.

Plus concrètement, l'utilisation du 82C150 implique de le calibrer lors de son reset grâce à des messages de calibration, puis de le maintenir calibré en lui envoyant régulièrement ce message de calibration (environ tous les dixièmes de secondes pour un débit de 50kbits/s).

Message de calibration.
Message de calibration.

Un message de calibration est un message avec un ID particulier (imposé) dont la trame (non imposée) a pour caractéristique de présenter un nombre important de transitions 1-0. Au reset, il faut envoyer ce message plusieurs fois au SLIO, qui, lorsqu'il sera correctement calibré, renverra un message d'identification, le sign on message. Celui-ci indique l'ID du 82C150 ainsi que l'état des 16 entrées digitales.

2.1.2 Utilisation du 82C150

A l'exception de l'ID, le pins du 82C150 se configurent et se commandent entièrement avec des trames de data.

Ces trames permettent d'écrire dans les registres du 82C150. Celui-ci envoie aussi des trames indiquant l'état de ses registres.

2.1.2.1 Format des trames

Les trames envoyées ou reçues par le SLIO ont toujours 3 octets (sauf les remote frame bien sûr). Le premier de ces bytes indiquent le numéro du registre du SLIO. Les registres étant de 16 bits, les 2 bytes suivant indiquent le contenu du registre spécifié par l'adresse.

2.1.2.2 Les registres

Le 82C150 possède 9 registres. En voici le détail :

  • Le Data Input Register contient l'état des 16 pins en entrées. L'état de ce registre sera transmis soit après réception d'un remote frame ou d'un data frame de premier octet le numéro de ce registre, soit au changement d'état de l'une des entrées si le 82C150 est configuré ainsi.
  • Les registres Positive Edge Register et Negative Edge Register permettent de configurer, pour chaque bits, à quel moment doit être envoyé la data frame contenant l'état des pins. Autrement dit, si par exemple le bit 10 du Positive Edge Register est à 1, une data frame sera automatiquement envoyé lorsque l'entrée 10 passe à 1, pour peu qu'elle soit configurée en entrée digitale.
  • Le Data Output Register permet d'indiquer l'état des pins configurés en sortie.
  • Le Output Enable Register permet de configurer les pins en sorties digitales.
  • L'Analog Configuration Register configure l'ADC.
  • Les registres DPM1 et DPM2 configurent les sorties quasi-analogiques. Celles-ci sont sur les pins 10 (DPM1) et 4 (DPM2).
  • L'ADC Register contient le résultat d'une conversion analogique--digitale. Une lecture de ce registre lance une conversion.

Il est important de noter que toute écriture dans l'un de ces registres provoque l'envoi d'une data frame avec la valeur du registre modifié.

2.2 Le PCA82C250

Le protocole CAN ne spécifie pas la couche physique, c'est pourquoi la plupart des contrôleurs CAN ne possèdent pas de circuits permettant de les connecter à un bus, qu'il soit filaire, à fibre optique ou tout autre mode de transmission possible.
Un transceiver, tel que le 82C250 de Philips, permet de faire l'interface entre le contrôleur CAN et le bus physique.

2.2.1 Codage physique des bits

La seule contrainte pour une couche physique, est l'implémentation d'un ET cablé: si un seul noeud transmet un bit DOMINANT, l'état du bus est DOMINANT, et si tous les noeuds transmettent un état RECESSIF, l'état du bus est RECESSIF.

Le transceiver 82C250 code les bits DOMINANT et récessifs de la manière suivante :

  • Etat DOMINANT (TX=0) CANH - CANL = 2V
  • Etat RECESSIF (TX=1) CANH - CANL = 0V

Remarque : Lors de la transmission d'un bit RECESSIF, le 82C250 pilote la paire différentielle avec une forte impédance, laissant ainsi la possibilité à tout autre noeud d'imposer une tension différentielle de 2V, correspondant à un état dominant.

Couche Physique du CAN.
Couche Physique du CAN.

2.2.2 Débit

Le débit maximal d'un noeud utilisant un du 82C250 est de 1Mbit/s, soit la limite théorique de débit d'un bus CAN. En cas d'utilisation du 82C2500 à débit réduit pour environnements critiques, il est possible de régler le slew-rate des transitions DOMINANT-RECESSIF, afin de limiter les RFI.

2.3 Le SJA1000

2.3.1 Présentation

Le SJA1000 est un contrôleur CAN ne nécessitant qu'un microcontrôleur externe. Il a été développé par Philips en 1997 comme un successeur (compatible) du 82C200.

2.3.1.1 Caractéristiques

  • Buffer de réception de 64 octets
  • Supporte le CAN 2.0A et 2.0B
  • Débit jusqu'à 1Mbit/s (En fait environ 600Kbit/s de données utiles)
  • Compteurs d'erreur avec accès lecture/écriture
  • Interruptions pour chaque type d'erreur sur le bus
  • Capture de la dernière erreur disponible
  • Détails sur le bit d'ID ayant causé une perte d'arbitration
  • Mode "Listen Only" (aucune action sur le bus)

2.3.2 Le mode BasicCAN

Ce mode est un mode simplifié dont la principale utilité est la compatibilité totale avec le 82C200 (prédecesseur du SJA1000)

2.3.3 Le mode PeliCAN

Le mode Pelican est le mode dans lequel il faut utiliser le SJA1000 pour avoir accès à toutes ses fonctionalités (CAN 2.0B, registres d'erreur, informations sur arbitration perdue...).

2.3.4 Les principaux registres

2.3.4.1 Le registre MODE

Ce registre contrôle le mode de fonctionnement du SJA1000. Il précise en particulier si le SJA1000 est en mode normal ou en mode de réinitialisation ("Reset Mode"). Outre le mode normal, le SJA1000 peut fonctionnner dans les modes :

Listen Only
Aucune action sur le bus.
Self test mode
Acquittement par un autre noeud non-nécessaire pour une bonne transmission.
Sleep mode
Déconnexion du bus tant qu'il n'existe aucune activité sur celui-ci.

Le registre MODE permet également de régler différents modes de fonctionnement du filtre d'acceptation (voir plus bas).

2.3.4.2 Le registre COMMAND

Comme son nom l'indique, le registre COMMAND est utilisé pour commmander le contrôleur CAN. Ces commandes peuvent-être:

Transmit Request (bit 0)
Demande la transmission des données présentes dans le buffer de transmission.
Abort Transmission (bit 1)
Annule une demande de transmission faite (et qui n'a pas encore commencé). Si elle a déja commencé, elle se termine.
Release Receive Buffer (bit 2)
Libère la place du dernier message reçu dans le buffer de reception.
Clear Data Overrun (bit 3)
Ré-initialise l'indicateur de surcharge.
Go To sleep (bit 4)
Ordonne au SJA1000 de passer en Sleep mode.

2.3.4.3 Le registre STATUS

Receive Buffer Status (bit 0)
vaut 1 si un message est présent dans le buffer de réception.
Data Overrun Status (bit 1)
vaut 1 si un message a été perdu à cause d'une saturation du buffer de reception.
Transmit Buffer Status (bit 2)
vaut 1 si le buffer de transmission est prêt à recevoir des donnée.
Transmission Complete (bit 3)
vaut 1 si la dernière transmission demandée a été correctement transmise et acquittée.
Receiving Status (bit 4)
vaut 1 si un message est en cours de réception.
Transmit Status (bit 5)
vaut 1 si un message est en cours de transmission.
Error Status (bit 6)
vaut 1 si le compteur d'erreur de transmission ou celui de réception a atteint la limite d'alerte (96 par défaut).
Bus Status (bit 7)
vaut 1 si le noeud est connecté au bus (ni en Sleep Mode ni Bus-Off pour cause d'erreurs à répétitions).

2.3.4.4 Le registre INTERRUPT

Ce registre permet d'autoriser la génération d'interruption sur la broche INT pour les évènements suivants:

  • Réception d'un message (bit 0)
  • Transmission d'un message compléte
  • Changement des STATUS d'erreurs (Error Status et Bus Status)
  • Changement du STATUS de saturation (Data Overrun STATUS)
  • Wake-up interrupt (reveil du noeud pour cause d'activité sur le bus)
  • Passage du mode "error-active" au mode "error-passive" ou vice-versa (seuil de 127 des compteurs d'erreurs)
  • Perte d'une arbitration
  • Détection d'une erreur sur le bus

2.3.4.5 Les registres BUS_TIMING0 et BUS_TIMING1

Ces registres permettent de régler la durée d'un bit. Bien évidemment, le bit-timing doit être le même pour chaque noeud présent sur le bus.

2.3.5 Le buffer de réception

Le buffer de réception est implémente sous la forme d'une FIFO de 64 octets. Le SJA1000 donne accès a une "fenêtre" qui permet à l'utilisateur de lire le dernier message reçu. Une fois cette lecture faite, l'utilisateur peut ordonner au SJA1000 de libérer la place correspondante dans le buffer. Ceci aura pour conséquence de déplacer la fenêtre vers le message suivant. La figure ci-dessous permet de visualiser le fonctionnement du buffer.

En plus de la fenêtre de réception, l'utilisateur peut également accéder directement aux 64 octets du Buffer. On dispose pour cela d'un registre précisant la position du dernier message reçu (RX_BUFFER_START_ADDRESS) et d'un registre précisant le nombre de messages présents dans le buffer (RX_MESSAGE_COUNTER).

Lorsqu'un message arrive alors que le buffer de réception est plein, le message arrivant est perdu (par ce noeud), et l'indicateur de saturation ("Data Overrun Satus") est positionné.

Buffer de réception.
Buffer de réception.

2.3.6 Le buffer d'émission

Le buffer de transmission est un simple buffer de 12 octets (jusqu'à 4 octets d'ID pour le CAN 2.0B et 8 octets de données).

Une fois que l'utilisateur a rempli ce buffer, il peut faire une demande de transmission.

Buffer de transmission.
Buffer de transmission.

2.3.7 Le filtre d'acceptation

Le filtre d'acceptation (Acceptance Filter) a pour rôle de contrôler les identificateurs (identifiers) des messages présents sur le bus avant de les laisser entrer dans le buffer de réception. Une bonne utilisation de ce filtre permet d'éviter une saturation du buffer de réception.

Le filtre d'acceptation est constitué des Acceptance Code Registers et Acceptance Mask Register.

Les Acceptance Code Registers contiennent l'ID "optimal" attendu par le SJA1000 (c'est-à-dire celui que devra avoir un message pour pouvoir entrer dans le buffer de réception, si les Acceptance masks sont tous à 0).

Les Acceptance Mask Registers précisent les bits de l'ID qu'il faut tester (0 si un bit doit être contrôlé et 1 s'il n'a pas d'importance).

 


Si ce qui refusait de marcher depuis des semaines marche soudainement, c'est que quelque chose d'autre ne va plus fonctionner.

Loi de de la Mécanique en Robotique de Corwin.

 

 

III) Cartes de developpement
Carte SJA1000-PPC.
3.1.1 Description
3.1.2 Utilisation
3.1.2.1 Macros de lecture-écriture
3.1.2.2 Exemples d'utilisation

3.2 Carte SLIO
3.2.1 Description
3.2.2 Utilisation
3.2.2.1 Calibration
3.2.2.2 Pilotage des sorties analogiques et digitales
3.2.2.3 Lecture des entrés analogiques ou digital

3.1 Carte SJA1000-PPC

Comme vu précédemment, le SJA1000 est un composant complet et assez simple d'emploi pour ajouter des fonctionnalités CAN à un système à base de microcontrôleur. Le 68HC912 de Motorola, intégrant un module CAN, n'étant pas encore au point, nous nous sommes tournés vers le PowerPC 403, dont la carte de développement existait déjà.

La carte d'interface (wrappée) implémente la partie protocole CAN ainsi que la couche physique de type bifilaire différentielle grâce au 82C250.

3.1.1 Description

Carte SJA1000-PPC (cliquez pour aggrandir)
Carte SJA1000-PPC (cliquez pour aggrandir)
  • IC1: SJA1000
  • IC2: 82C250
  • IC3: EP600
  • X1: Quartz 10MHz
  • R1: strap (définit la pente des transitions)
  • C1 à C4: 100 nF (découplage)
  • C5, C6: 33 pF

Les signaux de contrôle venant du PowerPC lors de cycles de lecture/écriture n'ont pas tout à fait le même format que ceux attendus par le SJA1000. La "glue logic" a été inclue dans un EPLD, ce qui permet une adaptation très simple à d'autres microcontrôleurs.

Le choix des broches rend possible l'utilisation d'un PAL22V10 à la place de l'EP600.

SC/ML/VO
ESIEE
March 1999

OPTIONS: TURBO=ON
PART: 5C060

INPUTS: CS5@2
        CS6@3
        OE@4
        WBE0@5

OUTPUTS: ALE@22
        CS@21
        RD@20
        WR@19

NETWORK:

CS5=INP(CS5)
CS6=INP(CS6)
OE =INP(OE)
WBE=INP(WBE0)

ALE1=NOT(CS5)
WRITE=OR(WBE,ALE1)

ALE=CONF(ALE1,VCC)
CS=CONF(CS6,VCC)
RD=CONF(OE,VCC)
WR=CONF(WRITE,VCC)

END$
Programme de l'EPLD (fichier cs.adf)

3.1.2 Utilisation

Les adresses et les données doivent être multiplexées sur le bus du SJA1000, c'est-à-dire que l'adresse est présentée en premier, puis ensuite viennent les données.

La lecture d'un registre se fait alors en deux temps : écriture de l'adresse (avec le CS5 du PPC positionné), puis lecture des données (avec CS6). De même l'écriture se fera en deux fois.

Lecture d'un registre
Lecture d'un registre

3.1.2.1 Macros de lecture-écriture

La lecture et l'écriture dans les registres du SJA1000 ont été implémentées sous forme de macros (fichier rwsja.h)

/*** Macros de lecture-ecriture SJA1000-PPC***/ 

/* Macro wrsjai : ecrit la donnee d dans le registre r */
   .macro  wrsjai d, r
    
    li	  r2,\r
    stb    r2,0(r18) 
    li	  r2,\d
    stb    r2,0(r19)

   .endm


/* Macro wrsja : registre p1 du PPC -> p2 du SJA1000 */
   .macro  wrsja p1, p2
    
    li     r2,\p2
    stb    r2,0(r18)
    stb    \p1,0(r19)
    
   .endm


/* Macro pour lire une donnee du SJA (registre p1 -> reg p2) */
   .macro  rdsja p1, p2
    
    li     r2,\p1
    stb    r2,0(r18)
    lbz    \p2,0(r19)
    
   .endm	
Macros de lecture-écriture (fichier rwsja.h)

3.1.2.2 Exemples d'utilisation

wrsjai    0xDB,OUTPUT_CONTROL
Pour écrire 0xDB dans le registre OUTPUT_CONTROL
 
wrsja    r3,TX_DATA
Pour écrire l'octet de poids faible du registre r3 dans le registre TX_DATA
 
rdsja    STATUS,r3
Pour lire le registre STATUS et placer le résultat sur l'octet de poids faible de r3

3.2 Carte SLIO

3.2.1 Description

Cette carte de démonstration est construite autour du SLIO (Serial Linked Input/Output) 82C150 de Philips. La configuration des entrées/sorties a été choisie de manière à donner une bonne idée des possibilités de ce SLIO. Elle a été développée et routée sous Protel.

  • P0-P3 : ID / Entrées digitales (switches)
  • P5 : Entrée analogique ADC1
  • P6 : Entrée analogique ADC2 (potentiomètre)
  • P7-P9,P11,P12 : Sorties digitales (LEDs)
  • P13 : Sélection des entrées
  • P15-P17 : Réservé multiplexage ADC
Schéma de la carte SLIO (au format postscript)

Les 4 entrées digitales sont multiplexées avec les 4 bits d'ID, eux aussi déterminés avec des switches. C'est un EPLD qui assure le multiplexage, commandé par la pin 14 du SLIO (qui n'est donc plus disponible comme entrée/sortie).

Les LEDs sont montées sur des connecteurs, ce qui permet d'utiliser ces sorties pour une autre utilisation.

Une des entrées analogiques est utilisée par un potentiomètre, l'autre peut servir pour un retour tachymétrique (pour un asservissement de moteur), ou pour toute autre source de tension entre 0 et 5V. Le multiplexage des entrées analogiques (en interne) occupe malheureusement 3 broches supplémentaires (P14 à P16) comme l'indique le schéma.

Enfin les sorties analogiques de type DPM (Discrete Pulse Modulation) sont amplifiées par des buffers (7407) avant d'attaquer des transistors de puissance. L'emploi de transistors PNP plutôt que NPN n'a pas de raison particulière, il est seulement dû à l'approvisionnement.

3.2.2 Utilisation

3.2.2.1 Calibration

Comme décrit dans la description du 82C150, il est nécessaire, pour que le SLIO reste calibré, de lui envoyer régulièrement un calibration message. Cette calibration doit se faire tous les 3000 à 8000 bit-times selon la documentation de Philips.

Par exemple, pour un débit de 50 kbit/s, soit un bit-time de 20 us, 5000 bit-times durent un dixième de seconde. Notre gestion des calibrations est décrite dans la partie Programmation PowerPC.

3.2.2.2 Pilotage des sorties analogiques et digitales

Il est tout d'abord nécessaire de configurer le registre OUTPUT_ENABLE des SLIOs. Sur la carte SLIO, étant donné les sorties utilisées, ce registre doit être mis à la valeur 0x3F90 (Pour effectuer cette affectation, voir le fichier slio.s) Une fois la configuration faite :

  • Pour une sortie digitale écrire dans le registre DATA_OUTPUT.
  • Pour une sortie DPM écrire dans les registre DPM1 ou DPM2.

3.2.2.3 Lecture des entrés analogiques ou digitales

Pour lire l'état des entrés digitales, il suffit de faire une lecture du registre DATA_INPUT Pour lire la valeur des ADCs, il faut configurer le registre ANALOG_CONFIGURATION (Pour effectuer cette configuration voir le fichier slio.s).

  • Ecrire 0xE0 pour une conversion sur l'ADC1
  • Ecrire 0xC0 pour une conversion sur l'ADC2.

Ces valeurs spécifient à la fois la configuration interne des multiplexeurs internes du SLIO (pour "router" le signal jusqu'au module ADC), et la demande de conversion (bit 8)

Une fois ces donnés reçues, le SLIO concerné effectue la conversion, et envoie une trame contenant le contenu de son registre ADC, c'est-à-dire le résultat de la conversion.

 


Moins un appareil remplit de fonctions, plus il les remplira parfaitement.
Remarque inquiète : Les ordinateurs sont les appareils les plus multifonctionnels qui soient, et notre société repose dessus.

Principe des Appareils Multifonctions