Programmation d'un bridge CAN<->CAN
Description
Je poste cette réalisation qui est très spécialisée et ne servira sans doute pas à beaucoup de monde mais je pense que le code, entièrement réalisé en assembleur PIC18, montre diverses techniques de programmation et d'optimisation intéressantes:
- Utilisation de l'USART, optimisation de la vitesse, contrôle de flux.
- Calcul de CRC, optimisation par utilisation d'une table (adressage PLUSW).
- Détection d'erreur de transmission par time-out.
- Machine à états finis (ou séquenceur).
Ce montage permet de connecter 2 bus CAN fonctionnant suivant le protocole 2.0B.
Il est basé sur micro-controleurs PIC18F2680 et offre les possibilités suivantes :
- Prolonger un bus CAN existant sans devoir réduire le débit des trames.
- Effectuer des dérivations en T de grande longueur.
- Faire du câblage en étoile ou peigne.
- Augmenter le nombre de nœuds raccordés au bus.
Le projet est fourni avec toutes les sources permettant de réaliser la carte électronique et de programmer les PIC.
Un document détaillant la conception, le fonctionnement et conseils d'utilisation du montage est fourni.
Pour installer le projet :
Décompresser le fichier Can_Bridge.zip dans le répertoire de votre choix. Rien n'est écrit ailleurs, ni dans la base de registre.
Pour désinstaller, il suffit donc de supprimer le répertoire avec son contenu.
Description détaillée :
La mise en oeuvre d'un bus CAN physique sur paires torsadées impose que le câble soit unique terminé à chaque extrémité par une résistance de charge de 120 Ohms. Cette contrainte a des conséquences qui peuvent être gênantes :
- Il n'est pas possible d'effectuer une dérivation en T par exemple pour atteindre un local annexe. Il faut faire un aller retour vers ce local ce qui peut augmenter significativement la longueur du bus.
- Il n'est pas possible d’effectuer un câblage en étoile par exemple pour partir d'une armoire électrique avec un câble par niveau et/ou aile de l'habitation. Là aussi, cela conduit en général à augmenter la longueur du bus.
- Le débit autorisé sur le bus dépend de la longueur du câble, de l'ordre de 1 Mb/s pour 40 m, 500 Kb/s pour 100 m, 250 Kb/s pour 200 m etc...
Dans le cas d'une application domestique, la réduction de vitesse n'est pas vraiment gênante (à moins d'habiter un château) une bonne réactivité n'est vraiment nécessaire que pour les éclairages : quand on appuie sur le bouton ou que le détecteur de présence réagit, il faut que la lampe s'allume sans délai perceptible à l'échelle humaine. Hors le temps de transfert d'un message à 125 Kb/s va de 0,5 à 1 milliseconde suivant le nombre de datas, ce qui est tout à fait négligeable.
Par contre, l'allongement du câble a au moins deux conséquences fâcheuses :
- Le coût qui peut devenir important si on utilise du câble de bonne qualité. Dans mon cas, j'avais approvisionné du câble de type « bus de terrain DEVICENET » composé d'une paire AWG15 pour l'alimentation et une paire AWG18 pour les données, une bobine de 64 m pour 200 € en 2014. Si je voulais poursuivre l'installation en faisant des allers-retours je devrais ajouter plus de 100 m de câble soit plus de 400 €.
- Les travaux de câblage sont plus conséquents et peuvent être plus onéreux suivant la technique utilisée (encastrement par saignées, sous goulotte...)
Le montage proposé a pour objectif de supprimer ces inconvénients en permettant le couplage de 2 bus CAN physiques. En utilisant plusieurs bridges, il est possible de multiplier les dérivations en T ou de réaliser une architecture en étoile ou encore une combinaison des deux.
J'ai nommé ce montage « bridge-CAN », dans l'industrie vous trouverez la dénomination « répétiteur » ou encore « répéteur ». J'ai préféré la notion de « pont » qui correspond bien à ce que fait ce montage alors que les répétiteurs ont généralement des fonctionnalités supplémentaires telles que :
- Isolation galvanique des bus. Ce n'est pas le cas ici, l'alimentation 12V / 5V étant commune.
- Filtrage des messages. Il n'y en a pas dans ce montage (ce serait possible en modifiant le soft).
- Support des normes CAN 2.0A et 2.0B. Ici seule la norme CAN 2.0B est supportée.
- Support de la norme CAN-FD. Impossible avec le PIC18F2680.
- Certains équipements ont même des fonctions de switch, par exemple 4 bus et paramétrage du routage de chaque bus.
Caractéristiques techniques :
CAN
Les caractéristiques sont identiques à celles de la carte EZL_r2 du projet DOMOCAN (auteur BigOnOff) à l'exception :
- Du buffer de réception CAN / émission USART : 768 octets voir §3.2.2
- Taille de trame variable : de 5 à 13 octets suivant le nombre de données.
- Pas de filtre ni de masque.
- Débit sélectionnable par jumpers (15 valeurs)
- Emission désactivable par jumper.
USART
- Vitesse jusqu'à 3 333 333 bauds, sélectionnable par jumpers (15 valeurs)
- Pas de parité, 1 start bit, 1 stop bit.
- Contrôle de flux : type « Stop and Wait » matériel.
- Buffer de réception USART / émission CAN : 2048 octets voir §3.2.2
- Taille des trames : variable de 6 à 14 octets (5 à 13 octets CAN plus un CRC )
- Contrôle des trames : par CRC sur 8 bits.
Autres
- Type de pic : 18F2680 (x2)
- Oscillateur externe type CXO 10 MHz.
- Alimentation par +12 V du bus CAN.
- 2 LEDS de trafic USART par PIC (Rx et Tx)
- 4 LEDS d'état par PIC (erreurs et warning)
- Bouton de RAZ des LEDS d'état.
- CI double face.
- Connecteurs alimentation et CAN doublés.
- Utilisation de l'USART, optimisation de la vitesse, contrôle de flux.
- Calcul de CRC, optimisation par utilisation d'une table (adressage PLUSW).
- Détection d'erreur de transmission par time-out.
- Machine à états finis (ou séquenceur).
Ce montage permet de connecter 2 bus CAN fonctionnant suivant le protocole 2.0B.
Il est basé sur micro-controleurs PIC18F2680 et offre les possibilités suivantes :
- Prolonger un bus CAN existant sans devoir réduire le débit des trames.
- Effectuer des dérivations en T de grande longueur.
- Faire du câblage en étoile ou peigne.
- Augmenter le nombre de nœuds raccordés au bus.
Le projet est fourni avec toutes les sources permettant de réaliser la carte électronique et de programmer les PIC.
Un document détaillant la conception, le fonctionnement et conseils d'utilisation du montage est fourni.
Pour installer le projet :
Décompresser le fichier Can_Bridge.zip dans le répertoire de votre choix. Rien n'est écrit ailleurs, ni dans la base de registre.
Pour désinstaller, il suffit donc de supprimer le répertoire avec son contenu.
Description détaillée :
La mise en oeuvre d'un bus CAN physique sur paires torsadées impose que le câble soit unique terminé à chaque extrémité par une résistance de charge de 120 Ohms. Cette contrainte a des conséquences qui peuvent être gênantes :
- Il n'est pas possible d'effectuer une dérivation en T par exemple pour atteindre un local annexe. Il faut faire un aller retour vers ce local ce qui peut augmenter significativement la longueur du bus.
- Il n'est pas possible d’effectuer un câblage en étoile par exemple pour partir d'une armoire électrique avec un câble par niveau et/ou aile de l'habitation. Là aussi, cela conduit en général à augmenter la longueur du bus.
- Le débit autorisé sur le bus dépend de la longueur du câble, de l'ordre de 1 Mb/s pour 40 m, 500 Kb/s pour 100 m, 250 Kb/s pour 200 m etc...
Dans le cas d'une application domestique, la réduction de vitesse n'est pas vraiment gênante (à moins d'habiter un château) une bonne réactivité n'est vraiment nécessaire que pour les éclairages : quand on appuie sur le bouton ou que le détecteur de présence réagit, il faut que la lampe s'allume sans délai perceptible à l'échelle humaine. Hors le temps de transfert d'un message à 125 Kb/s va de 0,5 à 1 milliseconde suivant le nombre de datas, ce qui est tout à fait négligeable.
Par contre, l'allongement du câble a au moins deux conséquences fâcheuses :
- Le coût qui peut devenir important si on utilise du câble de bonne qualité. Dans mon cas, j'avais approvisionné du câble de type « bus de terrain DEVICENET » composé d'une paire AWG15 pour l'alimentation et une paire AWG18 pour les données, une bobine de 64 m pour 200 € en 2014. Si je voulais poursuivre l'installation en faisant des allers-retours je devrais ajouter plus de 100 m de câble soit plus de 400 €.
- Les travaux de câblage sont plus conséquents et peuvent être plus onéreux suivant la technique utilisée (encastrement par saignées, sous goulotte...)
Le montage proposé a pour objectif de supprimer ces inconvénients en permettant le couplage de 2 bus CAN physiques. En utilisant plusieurs bridges, il est possible de multiplier les dérivations en T ou de réaliser une architecture en étoile ou encore une combinaison des deux.
J'ai nommé ce montage « bridge-CAN », dans l'industrie vous trouverez la dénomination « répétiteur » ou encore « répéteur ». J'ai préféré la notion de « pont » qui correspond bien à ce que fait ce montage alors que les répétiteurs ont généralement des fonctionnalités supplémentaires telles que :
- Isolation galvanique des bus. Ce n'est pas le cas ici, l'alimentation 12V / 5V étant commune.
- Filtrage des messages. Il n'y en a pas dans ce montage (ce serait possible en modifiant le soft).
- Support des normes CAN 2.0A et 2.0B. Ici seule la norme CAN 2.0B est supportée.
- Support de la norme CAN-FD. Impossible avec le PIC18F2680.
- Certains équipements ont même des fonctions de switch, par exemple 4 bus et paramétrage du routage de chaque bus.
Caractéristiques techniques :
CAN
Les caractéristiques sont identiques à celles de la carte EZL_r2 du projet DOMOCAN (auteur BigOnOff) à l'exception :
- Du buffer de réception CAN / émission USART : 768 octets voir §3.2.2
- Taille de trame variable : de 5 à 13 octets suivant le nombre de données.
- Pas de filtre ni de masque.
- Débit sélectionnable par jumpers (15 valeurs)
- Emission désactivable par jumper.
USART
- Vitesse jusqu'à 3 333 333 bauds, sélectionnable par jumpers (15 valeurs)
- Pas de parité, 1 start bit, 1 stop bit.
- Contrôle de flux : type « Stop and Wait » matériel.
- Buffer de réception USART / émission CAN : 2048 octets voir §3.2.2
- Taille des trames : variable de 6 à 14 octets (5 à 13 octets CAN plus un CRC )
- Contrôle des trames : par CRC sur 8 bits.
Autres
- Type de pic : 18F2680 (x2)
- Oscillateur externe type CXO 10 MHz.
- Alimentation par +12 V du bus CAN.
- 2 LEDS de trafic USART par PIC (Rx et Tx)
- 4 LEDS d'état par PIC (erreurs et warning)
- Bouton de RAZ des LEDS d'état.
- CI double face.
- Connecteurs alimentation et CAN doublés.
Codes Sources
A voir également
- Programmation d'un bridge CAN<->CAN
- Librairie programmation ✓ - Forum C / C++ / C++.NET
- Can not issue data manipulation statements with executequery(). - Forum Java
- Programmation synonyme - Forum C / C++ / C++.NET
- Programmation de pic 16f877 en mikroc - Forum ASM
- Programmation pic16f877a + afficheur LCD - Forum C++ & C++ .NET
Vous n'êtes pas encore membre ?
inscrivez-vous, c'est gratuit et ça prend moins d'une minute !
Les membres obtiennent plus de réponses que les utilisateurs anonymes.
Le fait d'être membre vous permet d'avoir un suivi détaillé de vos demandes et codes sources.
Le fait d'être membre vous permet d'avoir des options supplémentaires.