Protocole CAN Tutoriel. Division - Name - Date - Language 2 Protocole CAN : Controller Area Network...

Protocole CAN

Tutoriel

Division - Name - Date - Language 2

Protocole CAN : Controller Area Network Historique

Début du développement d ’un projet interne chez Bosch, destiné àdévelopper un réseau embarqué dans les véhicules

Présentation officielle du protocole CAN

Premiers puces de contrôleurs CAN, disponibles chez Intel et Philips Semiconductors

Publication par Bosch de la spécification CAN 2.0

Introduction par Kvaser de CAN Kingdom, protocole de haut niveau basé sur CAN

Création du groupement international de constructeurs et d ’utilisateurs CiA ( CAN in Automation )

Publication par le CiA du protocole CAL (CAN Application Layer)


Protocole CAN : Controller Area Network Historique

Premières voitures à utiliser le réseau CAN chez Mercedes-Benz

Publication de la norme ISO 11898

Première Conférence Internationale CAN (iCC) organisée par le CiA

Introduction par Allen-Bradley du protocole DeviceNet

Publication d ’un amendement à la norme ISO 11898 (format de trame étendu)

Publication par le CiA du protocole CANopen

Développement du protocole de communication TTCAN :Time-Triggered communication protocol for CAN


Protocole CAN : Controller Area Network Protocoles de Haut Niveau

On fait appel à des modèles pour comprendre et

expliquer les problématiques de communication, pour

décrire les objets de communication , de même que

pour décrire les services applicables sur ces objets

Les modèles en couches sont communs dans les

technologies de la communication

Le modèle OSI (Open Systems Interconnect) de l ’ISO

(International Standardization Organization) est

largement utilisé pour décrire la fonctionnalité des

systèmes de communication : il est fondé sur une

approche hiérarchisée de couches



L ’implémentation matérielle actuelle de CAN couvre

aujourd’hui les 2 couches inférieures de ce modèle; les

couches 3 à 7 étant couvertes par différentes approches

logicielles

Il existe un grand nombre de protocoles de haut niveau,

basés sur CAN, et qui ont été développés pour différents

domaines d ’application, et en fonction de différents

besoins utilisateur



Pour comprendre le modèle de référence CAN, on peut recourir à une

analogie

On peut en effet considérer que la fonctionnalité offerte par le réseau

CAN est semblable à des lettres de l ’alphabet dans les communications

écrites humaines : c ’est la base pour l ’écriture d ’une langue, mais ce

n ’est pas suffisant pour entreprendre une communication efficace

Pour spécifier une langue, il est en outre nécessaire de disposer d ’un

stock de mots disponibles, en même temps que d ’une grammaire qui va

régir la constitution des phrases



Les utilisateurs de CAN peuvent ainsi spécifier leur propre langue. En

termes techniques, il s ’agit alors d ’un protocole de haut niveau, qui

peut être conforme à la couche 7 du modèle OSI de référence

Ou bien l ’utilisateur peut décider d ’utiliser un protocole standardisé de

haut niveau, basé sur CAN.

Dans le monde CAN, il existe différents protocoles standardisés sur la

couche application

Certains sont très spécifiques, et relatifs à des domaines d ’application

spécifiques

La seule couche application qui soit pure et indépendante d ’une

quelconque application des réseaux CAN est définie par le protocole

CAN Application Layer (CAL), spécifié et maintenu par le CiA



Si l ’on en revient à notre précédente analogie, l ’utilisation d ’un

dictionnaire et d ’une grammaire n ’est pas très pratique, si l ’on a

comme seul propos de commander une boisson dans un pays étranger

Pour des tâches simples comme celles-là, il existe des guides de

conversation. Ceux-i ne font appel qu ’à un sous-ensemble de la langue,

et proposent des phrases prédéfinies qui correspondent à des situations

particulières, par exemple au restaurant ou à l ’hôpital.

Dans le monde des systèmes de communication techniques, ces guides de conversation sont dénommés des « profils »

Ainsi CANopen recouvre-t ’il une famille de profils basés sur CAN

CANopen est également spécifié et maintenu par le CiA



On peut répartir ces profils basés sur CAN entre un certain nombre de profils de communication qui s ’acquittent des spécifications que tout équipement doit être à même de fournir, et un certain nombre d ’autres profils d’équipements qui définissent chacun les caractéristiques particulières à une classe d ’équipements

Un système de communication, basé sur CAN peut se diviser en quatre couches

La couche physique est implémentée dans un certain nombre de contrôleurs CAN

Les autres parties sont assurées au moyen de boîtiers transceivers

La couche application, comme les profils basés sur CAN sont implémentés par logiciel

Dans un certain nombre de cas, couche application et profils ne sont pas toujours très clairement dissociés


Protocole CAN : Controller Area Network Norme ISO 11898

La spécification du protocole CAN est normalisée par l ’ISO

(International Organization for Standardization) dont le siège est à

Genève

Le document de l ’ISO 11898 est en cours de révision, et sera publié

selon différentes parties :

Partie 1 pour la définition du protocole CAN

Partie 2 pour la spécification de la couche physique haute vitesse

(sans tolérance de panne)

Partie 3 pour la description de la couche physique basse vitesse, à

tolérance de panne

Partie 4, en cours de développement, pour la spécification du

protocole de communication TTCAN : Time-Triggered CAN



Outre ces spécifications de base, différents travaux sont engagés au

plan international, au sein des organismes officiels de normalisation,

ainsi que dans les associations à but non lucratif, pour ce qui est des

protocoles de haut niveau pour réseaux CAN

Certaines de ces spécifications sont très liées à une nature

d’application, tandis que d ’autres sont davantage génériques

Dans les applications du secteur automobile, on trouvera les

spécification OSEK-COM et OSEK-NM, qui sont destinés à être

normalisées sous le numéro ISO 17356

En ce qui concerne les communications sur les camions et gros engins,

l ’ISO a développé la norme ISO 11992, qui est basée sur le profil

d’application J1939. Ce profil d’application SAE J1939-71 définit les

communications basées sur CAN sur les camions et bus



Pour ce qui est des réseaux intégrés, les membres du CiA ont

développé la famille des profils CANopen

La couche application CANopen ainsi que les profils de communication

CANopen sont soumis à la Normalisation Européenne sous le numéro

prEN 50325-4

DeviceNet, de son côté, se voulant dédié pour les applications

manufacturières et de process, est déjà normalisé sous le numéro

EN 50325-2

De même en ce qui concerne les Smart Distributed Systems basés sur

CAN : EN 50325-3


Protocole CAN : Controller Area Network Principes des échanges de données

Le protocole CAN est défini par la norme internationale ISO 11898

Outre le protocole lui-même, les tests de conformité avec le protocole

CAN sont spécifiés par la norme ISO 16845, qui garantit l ’inter-

opérabilité des chips CAN


Protocole CAN : Controller Area NetworkPrincipes des échanges de données

CAN est basé sur le mécanisme de

communication dît de diffusion (broadcast)

Cette communication en broadcast est

réalisée par le biais de l ’utilisation d ’un

protocole de transmission orienté

messages

De sorte que ce protocole ne définit que des messages, sans s ’intéresser aux stations, ni aux adresses de ces stations

Ces messages sont identifiés par le biais d ’un Identificateur de Message

Un tel Identificateur de Message se doit donc d ’être unique sur l ’ensemble du réseau;il définit non seulement le contenu, mais également la priorité du message

Ceci trouvera toute son importance lorsque plusieurs stations seront en concurrence pour l ’accès au réseau



Le haut niveau de souplesse atteint, tant au niveau système qu’au niveau configuration, est le résultat d ’un schéma d ’adressage orienté contenu

Il est très facile d’ajouter des nœuds à un réseau CAN existant, sans pour cela avoir à faire de modification, ni matérielle, ni logicielle

aux nœuds existantes, si ces nœuds ne se comportent que comme des récepteurs purs

Ceci autorise un concept d ’électronique modulaire, et permet également des réceptions multiple, ainsi que la synchronisation de processus distribués : les informations requises par plusieurs nœuds peuvent être transmises par le réseau, sans qu’il ne soit nécessaire que chaque nœuds connaisse le producteur de ces données

Ceci facilite aussi la mise en service et la mise à jour du réseau, dans la mesure où les échanges de données ne sont pas liés à la disponibilité de types particuliers de stations



En traitement temps réel, l’urgence des messages à échanger sur le réseau peut différer de façon significative : ainsi, une grandeur évoluant rapidement, par exemple une charge de moteur, devra être transmise plus fréquemment, et de ce fait avec moins de retard que d’autres grandeurs, par exemple la température du moteur

La priorité avec laquelle un message est émis, par comparaison ave un autre message d ’urgence moindre, est indiquée par l ’identificateur embarqué au sein de chaque message

Ces priorités sont consignées lors de la conception du système, sous la forme de valeurs binaires, et ne peuvent être modifiées de façon dynamique. Les identificateurs possédant la valeur la plus faible disposent de la priorité la plus forte

Les conflits d ’accès au bus sont réglés par le biais d ’un arbitrage s ’effectuant sur le champ Identificateur posté par chacune des stations en concurrence, et en observant bit à bit le niveau de tension du bus



Ceci met en jeu un mécanisme implicite de

"ET câblé", par l ’intermédiaire duquel un état

dominant écrase un état récessif

La compétition pour l’allocation du bus est

perdue par les nœuds en situation simultanée

d ’émission d ’un bit dominant, et d’

observation d ’un bit récessif

Tous ces "perdants" deviennent automatiquement des "receveurs" des messages disposant de la priorité la plus haute, comparativement; et dès lors ne re-tente pas de nouvelle émission, tant que le bus n ’est pas de nouveau disponible

Les demandes d ’émission sont gérées comme un tout, selon l’ordre d’importance des messages pour le système. Ceci s ’avère particulièrement avantageux dans les situations de surcharge. Etant donné que les accès au bus sont priorisés en fonction des messages, il est possible de garantir de temps de latence individuels courts sur des systèmes temps réel


Le protocole CAN admet deux formats de trame de message

la seule différence essentielle entre ces deux formats réside dans le longueur du champ Identificateur

Le format de trame CAN dit format standard, également appelé CAN 2.0 A, admet un identificateur d ’une longueur de 11 bits

Le format de trame CAN dit format étendu, également appelé CAN 2.0 B, admet un identificateur d ’une longueur de 29 bits

Protocole CAN : Controller Area Network Formats des trames des messages


Protocole CAN : Controller Area Network Format de trame standard

Un message sur le format de trame CAN standard commence sur le bit de Start appelé "Start Of Frame (SOF)"

Il est suivi d ’un champ appelé "Champ d’Arbitrage", constitué de l ’Identificateur et du bit RTR "Remote Transmission Request (RTR)", auquel il est fait appel pour opérer la distinction entre une trame de données et une trame de demande de ces données, et que l’on nomme "Remote Frame"

Le champ suivant, nommé "Champ de Contrôle" comporte un bit nommé Extension d ’Identificateur ["IDentifier Extension (IDE)" ], qui permet d ’effectuer la distinction entre une trame CAN standard et yune trame CAN étendue



Le champ suivant, nommé Code de Longueur des Données ["Data

Length Code (DLC)"] sert à indiquer la quantité des octets de données

qui fait suite, sur le champ "Données" ["Data field" ]

Si le message considéré est utilisé comme une "Remote Frame", le

champ DLC comporte alors le nombre des octets de données qui sont

demandés

Le champ "Données" qui vient ensuite est capable de copter à

concurrence de 8 octets de données



L ’intégrité de la trame est garantie par le checksum ["Cyclic Redundant

Check (CRC)"] qui fait suite.

Le champ Acquit ["ACKnowledge (ACK)"] est un compromis entre Bit

d’Acquit et un Délimiteur d ’Acquit : le bit résidant sur cette position ACK

est émis comme un bit récessif; et il est positionné en dominant par les

récepteurs ayant à ce moment-là correctement réceptionné les données.

Les messages corrects sont acquittés par les récepteurs

indépendamment des résultats du test d ’acceptation



La fin d ’un message est signifiée par un champ "End Of Frame (EOF)"

Le champ suivant : "Intermission Frame Space (IFS)" caractérise le

nombre minimal de bits séparant deux messages consécutifs

S ’il n ’y a pas d ’accès au bus, venant à la suite, de la part d ’une autre

station, le bus se place dans l ’état "idle"


Protocole CAN : Controller Area Network Format de trame étendue

Un message répondant au format étendu de trame CAN est à peu de choses près le même qu ’un message répondant au format standard de trame CAN

La différence tient dans la longueur du champ Identificateur utilisé

L ’Identificateur est réalisé à partir des 11 bits de l’Identificateur existant sur le format Standard (dénommé Identificateur de Base), auxquels se rajoute une extension sur 18 bits ( dénommée Extension d ’Identificateur)



La distinction entre format standard et format étendu de trame CAN est réalisée au moyen du bit IDE. Ce bit est émis comme un bit dominant si la trame répond au format standard, et comme un bit récessif si la trame répond au format étendu

Comme les deux formats se doivent de pouvoir cohabiter sur un même bus, cela détermine le message qui dispose de la priorité la plus haute sur le bus, dans le cas d’une collision lors de l’accès au bus, lorsque les trames en collision présentent un format différent pour un identificateur de base identique : le message décliné sous le format CAN standard a toujours la priorité sur le message décliné sous le format CAN étendu



Les contrôleurs CAN qui admettent les messages en format étendu sont également capables d’émettre et de recevoir des messages au format CAN standard

Lorsque sur un réseau apparaissent des contrôleurs CAN qui ne connaissent que le format de trame standard, seuls alors sont émis par l ’ensemble des contrôleurs présents sur l’ensemble de ce réseau des messages au format CAN standard : dans le cas contraire, les messages au format CAN étendu ne seraient en effet pas compris par les premiers

Toutefois, on pourra trouver des contrôleurs n’admettant que le format de trame CAN standard, tout en reconnaissant, mais en ignorant le format étendu (version 2.0 B passive)


Protocole CAN : Controller Area Network Détection et signalisation d’erreur

A la différence des autres bus système, le protocole CAN ne fait pas appel

à des messages d ’acquittement : les erreurs sont signalées dès leur

apparition

Pour procéder à la détection d ’erreur, le protocole CAN implémente trois

mécanismes au niveau message :

Cyclic Redundancy Check (CRC)

Vérification de Trame

Erreurs sur ACK



Cyclic Redundancy Check (CRC)

Le CRC protège les informations présentes sur la trame en ajoutant des bits de signature à la fin de l’émission. Côté récepteur, ces bits sont recalculés et comparés à ceux reçus. S ’il y a discordance, une erreur de CRC est décrétée

Test de Trame

Ce mécanisme vérifie la structure de la trame émise, en procédant à la vérification des champs de bits par rapport à un format fixe, et à la taille de la trame. Les erreurs décelées par ces tests de trame sont désignées sous l ’appellation "erreurs de format"

ACK errors

Comme cela a déjà été mentionné, les trames reçues font l ’objet d ’un acquit positif par l ’ensemble des récepteurs, par le truchement d ’un acquit positif. S’il s ’avère qu ’aucun acquit n’est reçu par l ’émetteur du message, alors est signalée une "ACK error"



Le protocole CAN implémente également deux mécanismes pour la détection d ’erreur, au niveau bit :

Monitoring

Bit stuffing (bourage)



MonitoringLa capacité de l’émetteur à déceler des erreurs est basée sur la surveillance des signaux du bus. Chaque nœud qui émet observe en même temps les niveaux du bus, et détecte ce faisant les différences entre un bit émis et un bit reçu. Ceci permet une détection fiable des erreurs de niveau global, ainsi que des erreurs locales à l ’émetteur

Bit stuffing (bourrage) Le codage des bits individuels est testé au niveau du bit. La représentation du bit utilisé par CAN est un codage de type "Non Return to Zero (NRZ)". Ce codage garantit une efficacité maximale au niveau du codage du bit. Au cas où, des fronts arbitraires de synchronisation sont générés au moyen d ’une technique dite de "bit stuffing" (bourrage). Cela signifie qu’après 5 bits consécutifs et de même niveau, l ’émetteur va insérer un bit de bourrage dont l ’état sera complémentaire de celui des bits de la séquence en cours. Ces bits de bourrage seront identifiés et retirés par les récepteurs.



Si une, voire plusieurs erreurs, sont décelées par au moins un nœud, au travers de l’un ou l’autre de ces mécanismes, l’émission en cours est interrompue par l’émission d’un "error flag"

Ceci permet d ’éviter que les autres stations n’acceptent ce message, et conforte la cohérence des donnés sur l ’ensemble du réseau

Après avoir interrompu l’émission d’un message erroné, l ’émetteur essaie automatiquement une ré-émission. Auquel cas, il peut se trouver qu ’il y ait à nouveau compétition pour l’allocation du bus



Quelle que soit la pertinence et l ’efficacité des méthodes décrites, il se peut toutefois arriver que la présence d’un nœud défectueux conduise au fait que l ’ensemble des messages (y compris les messages corrects) fassent l ’objet d ’un abort

Si aucune des mesures d ’auto-surveillance n’a été prise, le bus système va de ce fait se retrouver bloqué

C ’est pourquoi le protocole CAN fournit un mécanisme destiné à procéder à la distinction entre erreurs sporadiques et erreurs permanentes, et défaillances locales à un nœud

Ceci est réalisé par évaluation statistique des situations d ’erreur des nœuds, avec l ’objectif qu ’un nœud puisse reconnaître ses propres défaillances, et éventuellement se porter dans un mode de fonctionnement dans lequel le reste du réseau CAN ne sera pas négativement impacté

Ceci peut aller jusqu’à une déconnexion par la station elle-même, afin d ’éviter que, par erreur, les messages des autres nœuds ne soient interprétés comme incorrects


Protocole CAN : Controller Area Network Options de la couche physique

Conformément à la norme ISO 11898-1, le protocole CAN ne définit pas de couche physique

Il définit en effet deux valeurs logiques qui doivent être représentées par une couche physique

Outre l ’implémentation des valeurs logiques, la couche physique doit également être capable de permettre l ’émission et la réception de signaux exactement dans le même instant

C’est ce qui justifie l’implémentation d ’un temps de réponse, tel que requis par le protocole CAN, qui soit inclus dans le temps de bit

Deux couches physiques différentes sont actuellement définies :

couche Physique Haute Vitesse : Norme ISO 11898-2

couche Physique à Tolérance de Panne : Norme ISO 11898-3


Protocole CAN : Controller Area Network Couche Physique Haute Vitesse : Norme ISO 11898-2

La couche physique CAN à haute vitesse est spécifiée par la norme ISO 11898-2

Cette norme décrit les fonctionnalités de type Medium Access Unit (MAU) de même que certaines caractéristiques dépendantes du type de medium utilisé [MDI = Medium Dependent Interface]

Cette norme est la plus importante, en ce qui concerne la couche physique, pour ce qui se rapporte aux réseaux CAN dans les applications d’automatisation industrielle

D’autres spécifications sont détaillées dans les spécifications CANopen et DeviceNet. De même, les spécifications relatives àr J1939 sont-elles basées sur le norme ISO 11898-2

Dans les automobiles, c’est cette couche physique qui est utilisée, sur les applications gérant la motorisation et la transmission



La longueur théorique maximale du bus à 1 Mbit/s est de 40 m

La longueur effective maximale dépend de la configuration de ‘bit-timing’

Pour des débits inférieurs à 1 Mbit/s, cette longueur du bus peut être

étendue. Ainsi, la longueur maximale du bus à 50 kbit/s est de 1 km

Le nombre total de nœuds est limité par la charge électrique du bus.

Cependant, on peut recourir à des ponts ou répéteurs pour augmenter

ce nombre



Le médium physique est une ligne de bus sur 2 fils, avec un commun de

retour; il se termine sur une résistance à ses deux extrémités

Pour qu’un nœud puisse interpréter correctement les niveaux de tension

du bus, il convient que soient supprimées les réflexions des signaux

électriques sur le bus

Ceci est réalisé à l ’aide de résistances terminales (120 Ohms nominal)

que l’on place à chaque extrémité de la ligne du bus

On évitera par principe de loger cette résistance terminale au sein d ’un

équipement, car la lignes de bus perdrait alors sa terminaison en cas de

déconnexion de cet équipement



Idem, on devra faire en sorte que la topologie de câblage d’un réseau

CAN se rapproche le plus possible d’une structure mono-ligne, en sorte

d ’éviter les réflexions d ’onde sur le câble

En pratique cependant, il s’avère nécessaire de recourir à des lignes en

dérivation (stub) pour raccorder les équipements au bus

Les réflexions pourront être minimisées en réalisant des dérivations

aussi courtes que possible, en particulier pour des débits élevés.

Ainsi, à 1 Mbit/s, la longueur d’un câble en dérivation ne doit pas

excéder 0,3 m

Les câbles de bus peuvent être des fils parallèles, ou des paires

torsadées et/ou blindées, selon les contraintes EMC



Les connecteur utilisés pour raccorder les équipements au bus devront

présenter une impédance nominale de 120 Ohms, et une résistance

nominale en émission de 70 Méga-Ohms

Les câbles choisis pour les lignes du bus CAN doivent présenter une

impédance nominale de 120 Ohms, une résistance par unité de

longueur de 70 Méga-Ohms / m, et un retard de ligne nominal de 5 ns/m

Pour les lignes de bus supérieures à 40 m, la résistance spécifique du

câble de bus devra être inférieure

Pour les applications courantes, le CiA recommande l ’utilisation de

circuits drivers qui soient compatibles ISO 11898-2

Plusieurs fabricants proposent des chips intégrant ces transceivers


Protocole CAN : Controller Area Network Couche Physique à Tolérance de Panne : ISO 11898-3 Il existe plusieurs couches physiques à tolérance de panne, pour les

réseaux basés sur le protocole CAN

La norme ISO 11519-2 décrit une circuiterie de transceiver présentant

des possibilités très limitées, en termes de fan-out

Cette norme est destinée à disparaître d ’ici peu

La couche physique spécifiée dans l’ISO 11992 est dédiée aux

applications de type camion et gros engins, qui offrent des tensions

différentielles élevées

Le groupe de normalisation ISO TC22 SC3 WG1 a lancé une nouvelle

proposition de thème de travail, qui concerne une couche physique CAN

à tolérance de panne (ISO DIS 11898-3), destinée à se substituer à

l ’ISO 11519-2


Protocole CAN : Controller Area Network Couche Physique à Tolérance de Panne : ISO 11898-3 Cette nouvelle spécification de transceiver à tolérance de panne va

spécifier une consommation faible puissance, des modes de

déconnexion, ainsi que des procédures de réveil

La fonctionnalité la plus significative des couches physiques à tolérance

de panne est leur capacité à opérer une émission sur un seul fil, en cas

de court-circuit d ’une ligne de bus avec la masse ou avec la tension

d ’alimentation

Les court-circuits entre les deux lignes de bus conduisent de même à

une émission sur un seul fil


Protocole CAN : Controller Area Network Couche Physique à Tolérance de Panne : ISO 11898-3 L ’ISO 11898-3 spécifie l ’accès au bus CAN à tolérance de panne pour

des équipements plus modestes, en ce qui concerne le débit et la

longueur de bus

Elle est essentiellement destinée à être utilisée dans les réseaux

électroniques de confort, sur les véhicules à moteur

Pour fournir les conditions d ’une tolérance de panne, la résistance de

terminaison globale d’un réseau doit être d ’environ 1000 Ohms (et non

inférieure à 100 Ohms)

Il est possible d ’utiliser des transceivers de bus à faible consommation,

ce qui permet de maintenir à son minimum la consommation du bus


Protocole CAN : Controller Area NetworkCouche Physique à Tolérance de Panne : ISO 11898-3 Le nombre de nœuds participants, tel que spécifié dans la norme ISO

11898-3, ne devrait pas être inférieur à 20 (à 125 kbit/s, pour une

longueur totale de réseau de 40 m) et pourrait monter à 32

Le nombre effectif de nœuds varie, en fonction de la vitesse de

communication, de la charge capacitive du réseau, de la longueur de

ligne totale, du concept de terminaison de réseau, etc.

Pour pouvoir fournir une vitesse de communication maximale de 125

kbit/s, la longueur totale du réseau ne devrait pas dépasser 40 m.

Toutefois, il est possible d ’augmenter cette longueur totale de réseau

en diminuant le débit


Protocole CAN : Controller Area Network Couche Physique à Tolérance de Panne : ISO 11898-3 La ligne de bus, dans la spécification ISO 11898-3, peut présenter l ’un

des deux états logiques que sont les états "récessif" et "dominant". Pour

pouvoir effectuer la distinction entre ces deux états, on considère une

tension différentielle

Dans l ’état "récessif", la ligne CAN_L line est fixée à une tension

supérieure à celle de la ligne CAN_H. Ceci conduit en général à une

tension différentielle négative

L ’état "dominant" est représenté par une tension différentielle positive.

Cela signifie que la lige CAN_H est fixée de façon active à un niveau de

tension supérieur, et que la lige CAN_L est fixée de façon active à un

niveau de tension inférieur

L ’état "dominant" prend le pas sur l ’état "récessif", et s ’affirme au

travers des bits "dominants"

Protocole CAN Tutoriel. Division - Name - Date - Language 2 Protocole CAN : Controller Area Network...

Documents

Transcript of Protocole CAN Tutoriel. Division - Name - Date - Language 2 Protocole CAN : Controller Area Network...