LOCODUINO

Discussions Générales => Bus CAN => Discussion démarrée par: Jean-Luc le février 03, 2015, 04:16:53 pm

Titre: Le bus CAN
Posté par: Jean-Luc le février 03, 2015, 04:16:53 pm
Nous avions démarré en interne une discussion sur le bus CAN qui a débouché sur la réalisation d'un module permettant d'expérimenter le bus sur un Arduino. La carte réalisée est visible sur le fil voisin : BreakoutBoard CAN (http://forum.locoduino.org/index.php?topic=2.0). Ce développement a été entrepris car les shields CAN sont mystérieusement hors de prix (20€ et plus). 

Le bus CAN est déjà utilisé dans notre hobby. Il y a tout d'abord le MERG (http://www.merg.org.uk) (Model Electronic Railway Group). Organisation anglaise qui a choisi le CAN pour interconnecter les modules qu'elle développe. L'explication est donnée ici : http://www.merg.org.uk/merg_resources/cbus.php

Ensuite il y a Zimo qui a choisi le bus CAN comme bus de rétro signalisation : http://www.zimo.at/web2010/aboutus/highlights_EN.htm

Enfin il y a CAN Digital Bahn : http://www.can-digital-bahn.com/news.php

J'utilise moi même le CAN sur mon réseau (2 bus en fait, l'un à 125kb et l'autre à 700kb+)

Des informations concrètes suivront sur le site éditorial.
Titre: Re : Le bus CAN
Posté par: railyRabbit le mai 16, 2015, 09:47:37 pm
J'ai un doute à lire les différents post : le bus CAN intègre-t-il un système de validation / renvoi des ordres si nécessaire ?
Que se passe-t-il si l'information transmise est corrompue en chemin, ou si le destinataire ne la reçoit pas (buffer plein, pb transitoire sur la connexion...) ?
Titre: Re : Le bus CAN
Posté par: DDEFF le juillet 08, 2015, 01:48:53 pm
Jean-Luc est pas mal occupé en ce moment.
Je peux néanmoins répondre à tes questions : oui, le bus CAN s'occupe de tout. Il a plusieurs niveaux de sécurité et renvoie les messages si nécessaire.
Je n'ai pas pu tester encore, mais c'est ce qui se fait de mieux comme bus.
Titre: Re : Le bus CAN
Posté par: Dominique le juillet 29, 2015, 08:55:22 am
J'ai fait quelques tests entre un UNO et un MEGA:

J'ai réalisé un banc de test avec un Mega qui émet des messages CAN sur 4 IDs et 4 tailles différents toutes les 25ms ( variable en fait, avec une limite basse à 10ms) et un Uno qui les reçoit sous IT, les compte et renvoie les compteurs (message de 4 octets) au Mega.
Pour garantir la réception, les messages sont récupères dans l'IRQ du CAN dans un buffer circulaire de 256 octets et traites 1 par 1 dans la LOOP qui est assez rapide pour suivre sans problème. Le buffer ne se sature jamais.

Apparemment il faut respecter 2 règles:
- mettre le moins de traitement possible dans l'ISR, juste un flag à monter,
- vider complètement le buffer du MCP2515 à chaque LOOP si le flag est monté.

Le UNO qui teste combine le CAN, l'I2C et un timer1 pour un Watchdog. Il compte les messages reçus, les affiche et renvoie un message avec ses compteurs toutes les secondes.

J'ai mis en place le maximum de précautions:
- la surveillance de l'IRQ du 2515, avec vidage forcé si plus d'IRQ depuis 1 seconde (ça peut servir à surveiller la vie des autres modules)
- la surveillance des overflows
- un Watchdog sur la LOOP avec réinit du CAN si la librairie se bloque.

Pour le moment ça tient à l'aise les 40 messages par seconde (4 messages de taille différents repères toutes les 25 ms.)

En augmentant la cadence, je vois que ça tient encore à 100 messages par seconde.

Mais il y a quelques pertes tout de même : 6/1000 à 40 messages/sec, 17/1000 à 100 messages/sec, 1/1000 à 20 messages/sec.

Il faut donc utiliser des messages Accusés de Réception au niveau application, notamment pour confirmer l'exécution d'une commande
Titre: Re : Le bus CAN
Posté par: Dominique le juillet 29, 2015, 05:42:10 pm
Mise à jour :

La cause des pertes de message résidait dans le test de non réception (plus d'IRQ pendant 1seconde) dont le traitement consistait à vider le tampon du 2515 pour lui permettre de générer à nouveau un IRQ.
En supprimant ce vidage forcé, les pertes de messages ont disparu !

Néanmoins, avec toutes les tortures qui je lui fais subir, il reste une perte de 1 message sur 10.000 environ.
Titre: Re : Le bus CAN
Posté par: Dominique le août 19, 2015, 07:36:04 pm
J'irai même jusqu'à dire que je prépare un article pour la mise en oeuvre "à coup sûr" du bus CAN, avec la carte Locoduino qui fonctionne à merveille !

J'ai réalisé ma carte de commande des aiguilles et des dételeurs, + quelques capteurs (RFID, infrarouge et Hall notamment), ainsi qu'une carte de test pour valider tous les scenarii de communication.

A bientôt pour lire le résultat ...
Titre: Re : Le bus CAN
Posté par: DDEFF le août 22, 2015, 12:44:59 pm
Salut Dominique,
J'attends le résultat avec impatience !  :D
Mon programme fait tous les calculs en 6 ms
A 300 km/h, un TGV fait environ 1 cm/10 ms au 1/87.
Je pense qu'il ne faut pas dépasser 10 ms pour récupérer les infos du réseau via le CAN.
Titre: Re : Le bus CAN
Posté par: Dominique le août 22, 2015, 04:11:03 pm
Bonjour Denis,

Effectivement un TGV à 300 km/h ça fait pas loin d'1 mètre par seconde au 1/87eme.
Comme ton TGV mesure pas loin d'1m de longueur en HO, la longueur de tes cantons (supérieure au train le plus long) fait donc au moins 1 m.
Donc tu auras au maximum une détection de passage par seconde pour ce TGV. Et vu que c'est un TGV a pleine vitesse, tu lui donneras la priorité la plus haute pour les traitements.

Si ton traitement total dure 6 ms, il reste 94 ms pour piloter les trains, les aiguilles, les signaux, le décor et même le café du chef de gare.

Bon, blague à part, un seul Arduino pourrait faire le job s'il n'y a pas trop de trains en mouvement.

Maintenant, avec le CAN a 500 kb/s , les temps de transmission seront largement inférieurs au temps de détection et au temps de traitement (tes 6 ms).

De toute façon le problème ne peut pas se poser de façon aussi simple : Il y a des tas de temps de latence à compter comme, par exemple, le temps d'exécution d'un changement d'aiguille qui nécessite d'attendre l'accusé d'exécution (la fin de l'impulsion de commande du moteur dans mon cas). Imagines des enclenchements multi-aiguilles !.

Cela veut dire que chaque cycle de détection/action devra prendre plusieurs tours de LOOP dans le Central, et que l'organisation du logiciel multiprocesseur deviendra une affaire sérieuse ;)

Je reviendrai sur cette question intéressante un peu plus tard car ça concerne aussi l'architecture logicielle.

Titre: Re : Le bus CAN
Posté par: Dominique le août 22, 2015, 06:20:06 pm
Voici une "recette de cuisine" pour la mise en oeuvre rapide du bus CAN.

Au dela de l'installation et de la mise en oeuvre de la carte CAN Locoduino, j'ai mis au point une gestion de mémoire tampon circulaire dans laquelle les messages sont enregistrés aussitôt que possible, et exploités ensuite tranquillement par la fonction LOOP.
Comme cela, on est certain de ne rien perdre !

Le matériel se compose d'une carte Arduino (par exemple ici un Mega2560) et d'une carte CAN Locoduino.
On commence par relier à la carte CAN les broches du bus SPI du Mega : 50 (MISO), 51 (MOSI), 52 (SCK), 53 (SS : chip select CAN), ainsi que le +5V et le 0V (Gnd).
Ajoutons une liaison entre la broche INT (interruption) de la carte CAN et la broche 2 (Interruption 0) de l'Arduino.

Il faut aussi télécharger une bibliothèque qui se trouve ici : https://github.com/Seeed-Studio/CAN_BUS_Shield
Puis il faut placer le dossier téléchargé dans le dossier des autres bibliothèques (voir l'article "Installer un bibliothèque").

Ensuite on peut placer ces 2 lignes en tête de programme :

#include <SPI.h>                 // pour la bibliotheque CAN
#include "mcp_can.h"             // bibliotheque CAN

Puis il faut créer l'objet CAN comme le permet la bibliothèque :

// variables globales pour l'interface CAN
MCP_CAN CAN(53);                // Definition du CS (chip select) pin 53 (SS du bus SPI)
unsigned char Flag_Recv = 0;    // variable d'échange avec l'interruption IRQ

Ainsi, on le voit, qu'une variable "Flag_Recv" qui servira à faire savoir à la LOOP qu'un ou plusieurs messages sont arrivés "sous interruption".

Cette variable est positionnée par la routine d'interruption suivante :

/*
 *  ISR CAN (Routine de Service d'Interruption)
 *  le flag IRQ monte quand au moins un message est reçu
 *  le flag IRQ ne retombe QUE si tous les messages sont lus
 */

void MCP2515_ISR()
{
     Flag_Recv = 1;
}

Après avoir placé ces lignes de code en tête de programme, abordons le SETUP dans lquel on insère les lignes suivantes :

  /* -----------------------------------------------------
  *                       SETUP
  * -----------------------------------------------------
  */

  /////////////// INIT CAN /////////////////
 
START_INIT:

  if(CAN_OK == CAN.begin(CAN_500KBPS))       // initialisation du can bus : baudrate = 500k
  {
    Serial.println(F("CAN BUS init ok!"));
  }
  else
  {
    Serial.println(F("CAN BUS init echec !"));
    Serial.println(F("Init CAN BUS a nouveau"));
    delay(200);
    goto START_INIT;
  }


On comprend bien ici que l'instruction CAN.begin(baudrate) démarre l'interface, avec un compte-rendu "CAN_OK", sinon cela se répète car, à ce stade de l'initialisation (SETUP), si le bus CAN ne démarre pas, il est inutile d'aller plus loin.

Personnellement je n'ai jamais vu d'échec sauf si la carte CAN n'est pas (ou est mal) branchée .

Puis il faut "attacher" l'interruption 0 à la routine MCP2515_ISR() précédente :

  attachInterrupt(0, MCP2515_ISR, FALLING); // interrupt 0 (pin 2)

Enfin on définit les filtres CAN qui limiteront les messages reçus à seulement ceux qui intéressent cette réalisation :

  /*
   * set mask & filter
   */
   
  CAN.init_Mask(0, 0, 0x3ff);               // there are 2 mask in mcp2515, you need to set both of them
  CAN.init_Mask(1, 0, 0x3ff);               // a preciser
   
  CAN.init_Filt(0, 0, 0x03);                // Reception possible : Id 03 (hex)
  CAN.init_Filt(1, 0, 0x04);                // Reception possible : Id 04 (hex)
  CAN.init_Filt(2, 0, 0x30);                // Reception possible : Id 30 (hex)
  CAN.init_Filt(3, 0, 0x40);                // Reception possible : Id 40 (hex)
  CAN.init_Filt(4, 0, 0x31);                // Reception possible : Id 31 (hex)
  CAN.init_Filt(5, 0, 0x41);                // Reception possible : Id 41 (hex)

Le SETUP ayant mis en place tous les acteurs, la LOOP peut commencer son travail répétitif !

/*-----------------------------------------------------
 *                        LOOP
 *-----------------------------------------------------                       
 */

void loop()
{

  if (Flag_Recv)  {
    Flag_Recv = 0;  // Flag MCP2515 pret pour un nouvel IRQ
    CAN_recup();    // récupération  et traitement du ou des messages CAN reçus
  }


et la fonction CAN_recup() est là :

// Message recu
byte IdR;                       // Id pour la routine CAN_recup()
unsigned char lenR = 0;         // Longueur "    "       "
unsigned char bufR[8];          // buffer reception      "
// Message emis
unsigned char bufS[4];          // buffer emission

// Memoire circulaire pour le stockage rapide des messages recus
unsigned char _Circule[256];    // recepteur circulaire des messages CAN sous IT
int _indexW, _indexR, _Ncan;    // index d'ecriture et lecture, nb d'octets a lire
byte _CANoverflow = 0;          // flag overflow (buffer _Circule plein)

/*
 * Routine de récuperation des messages CAN dans la memoire circulaire _Circule
 * appelee par LOOP lorsque Flag_Recv = 1;
 */
 
void CAN_recup()
{
  unsigned char len = 0;                // nombre d'octets du message
  unsigned char buf[8];                 // message
  unsigned char Id;                     // Id

  while (CAN_MSGAVAIL == CAN.checkReceive())  {
    CAN.readMsgBuf(&len, buf);          // read data, len: data length, buf: data buf
    Id = CAN.getCanId();
    if ((_Ncan+len+2) < sizeof(_Circule))  { // il reste de la place dans _Circule
      _Circule[_indexW] = Id;           // enregistrement de Id
      _indexW++;
      _Ncan++;
      if (_indexW == sizeof(_Circule))  {_indexW = 0;}
      _Circule[_indexW] = len;          // enregistrement de len
      _indexW++;
      _Ncan++;
      if (_indexW == sizeof(_Circule))  {_indexW = 0;}
      for (byte z = 0; z<len; z++)  {
        _Circule[_indexW] = buf[z];      // enregistrement du message
        _indexW++;
        _Ncan++;
        if (_indexW == sizeof(_Circule))  {_indexW = 0;}
      }
    } else {
      _CANoverflow = 1;  // depassement de la capacite de Circule
    }
  }
}


Dans Loop, récupérer un message, en parfaite indépendance de leur réception se fait ainsi :

  // traitement d'un seul message par loop dans la memoire circulaire _Circule
   
  if (_Ncan > 2)  {                 // messages dans _Circule : au moins 3 bytes
    _Ncan--;
    RId = _Circule[_indexR];        // recup Id
    _indexR++;
    if (_indexR == sizeof(_Circule))  {_indexR = 0;}
    _Ncan--;
    Rlen = _Circule[_indexR];       // recup longueur
    _indexR++;
    if (_indexR == sizeof(_Circule))  {_indexR = 0;}
    if (_dumpCan)  {               // _dumpCan est un flag qui permet de "sortir" les messages ou non
      Serial.print("CAN id ");
      Serial.print(RId);
      Serial.print(", data ");
    }
    for (int k = 0; k < Rlen; k++)  {
      _Ncan--;
      Rbuf[k] = _Circule[_indexR];  // recup octets message
      _indexR++;
      if (_indexR == sizeof(_Circule))  {_indexR = 0;}
      if (_dumpCan)  { 
      Serial.print("0x");
      Serial.print(Rbuf[k], HEX);
      }
    } // le message est dans les globales RId, Rlen et Rbuf[..]
    Serial.println();
 

Voilà que ce je dois expliquer…

Titre: Re : Le bus CAN
Posté par: DDEFF le août 23, 2015, 09:53:21 am
Formidable !!
J’essaierai bien, mais je fais partie de ceux qui n'ont pas eu les breakouts de Jean-Luc  :'(
Je pense que si on utilise un DUE, on peut éviter de mettre des F(...).
C'est très clair et bien expliqué. Merci.

Concernant mes "temps TGV", je pense surtout aux aiguilles que je gère en PRS, avec détection du train pour chaque aiguille.
Donc, des zones de 20 cm en HO.
Mais tu as raison, il faut adapter l'architecture du programme pour que ce soient les interruptions qui mettent à jour les différentes "tables".
Ce que je note, c'est que ce n'est pas le chrono qui va nous bloquer.
Titre: Re : Le bus CAN
Posté par: Dominique le août 23, 2015, 04:06:15 pm
J'ai démarré la rédaction de l'article 130.
Titre: Re : Le bus CAN
Posté par: DDEFF le août 23, 2015, 08:24:47 pm
Je pense que j'ai compris l'essentiel de ton programme et ça me rassure.
J'ai près de 60 aiguilles et donc, ça fera 2 octets à traiter, mais ça ne change rien à la logique.
L'idée de la mémoire circulaire est bonne, à mon avis. Voir sa taille en fonction du réseau, si nécessaire.
Vivement que je puisse avoir des breakouts !!
Ce sera avec un DUE et je vais réfléchir a l'intégration de tout ça dans mon programme.
Mais l'horizon se dégage  :D
Merci Dominique
Titre: Re : Le bus CAN
Posté par: Dominique le août 23, 2015, 09:52:39 pm
Sur le fil d'à coté (BoB CAN), le cas du DUE est abordé. Il ne faut y ajouter que le 2551 car un contrôleur est déjà intégré. La carte CAN Locoduino peut se connecter à un DUE via les connecteurs ad'hoc. Mais je n'ai pas encore essayé.

Ça m'intéresse et j'ai déjà 2 DUE qui attendent.

On peut, bien-entendu, envisager une petite production de cartes en accord avec Jean-Luc, et en le déchargeant des tâches ingrates, notamment l'appro des composants. Il faudra de toute façon en faire un minimum.
Titre: Re : Le bus CAN
Posté par: Jack56 le novembre 28, 2015, 02:46:57 pm
Bonjour,

Tout d’abord j’espère avoir posté ma question dans le bon fil.

J’ai vu sur le net des cartes SPI-CAN mais avec des quartz à 8 MHz ou 20 MHz du coup en regardant le code de la CAN_BUS_Shield j’ai remarqué qu’il y avait des constantes (MCP_16MHz_200kBPS_CFG1, MCP_16MHz_200kBPS_CFG2, …) qui permettent de configurer les registres du MCP2515 CNF1, CHF2 et CNF3. Cependant ces constantes sont déterminées pour une FOSC = 16 MHz.

J’ai essayé de trouver la logique pour adapter ces constantes à d’autres fréquences, mais j’avoue ne pas en avoir trouvée. J’ai bien sûr regardé le datasheet du 2515, mais j’avoue avoir du mal avec les subtilités de l’anglais. :-[

Y-a-t-il une logique pour déterminer BRP, PRSEG, PHSEG1, PHSEG2 en fonction(FOSC, BitRate) afin de pouvoir paramétrer correctement les registres CNF1, CNF2 et CNF3.

Merci d'avance
Titre: Re : Le bus CAN
Posté par: Dominique le novembre 28, 2015, 03:05:49 pm
Bonjour Jack,

Cette carte : "MCP2515 CAN Bus Module TJA1050"

http://www.ebay.fr/itm/311379482437 (http://www.ebay.fr/itm/311379482437)

contient un quartz à 8Mhz
Vous pouvez le dessouder (il faut une bonne tresse à dessouder) et mettre un quartz de 16 MHz à la place.

Je l'ai testé et ça marche avec la bibliothèque CAN préconisée.

Cordialement
Dominique
Titre: Re : Le bus CAN
Posté par: Snake 94 le mars 12, 2017, 01:43:31 pm
Bonjour à tous,
à moins que je ne trompe personne n'a évoqué la chose suivante :
http://openlcb.com/ (http://openlcb.com/)
... êtes-vous en mesure de m'en dire davantage ?
Cordialement,
Titre: Re : Le bus CAN
Posté par: DDEFF le mars 12, 2017, 02:03:26 pm
Bonjour Snake 94,

Je viens de voir la vidéo, mais je n'ai pas vu le plus petit Arduino dedans...
Nous aussi, on utilise le bus CAN (voir les articles), mais on ne vend pas de matériel.

Denis
Titre: Re : Le bus CAN
Posté par: bobyAndCo le mars 12, 2017, 07:37:38 pm
Bonsoir,

LCC ou openLCB n'est pas un bus mais un protocole avec un gros avantage, c'est qu'il est normalisé par le NMRA . Il peut fonctionner sur le bus CAN mais aussi ETHERNET et WIFI. A terme, ce qui est essentiellement visé c'est le WIFI très haut débit.

Désolé Denis mais nos ARDUINO vont s'accaparer ce protocole comme il ont merveilleusement su le faire par avec le DCC. Voir par exemple http://www.sumidacrossing.org/LayoutElectricity/microcontrollers/Arduinos/LCCforArduino/ (http://www.sumidacrossing.org/LayoutElectricity/microcontrollers/Arduinos/LCCforArduino/)

Bien amicalement

PS : Lien sur la note technique du NMRA (100 pages environ) : http://openlcb.org/wp-content/uploads/2016/02/LCC-Adopted-2016-02-20-Complete-Set.zip (http://openlcb.org/wp-content/uploads/2016/02/LCC-Adopted-2016-02-20-Complete-Set.zip)
Titre: Re : Le bus CAN
Posté par: DDEFF le mars 12, 2017, 08:23:10 pm
Bonsoir Christophe,

Je n'ai pas dit que ce n'était pas une bonne idée et je suis comme toi : le fait que ce soit normalisé NMRA est un énorme avantage.
C'est vraiment l'avenir, je suis d'accord.
Et surtout, ça nous changera des protocoles propriétaires des différents constructeurs. Enfin !  ::)

Par contre, heureusement que c'est "open" parce que tu ne me feras pas acheter les shields à 20 $ ou 25 $...
Quand je vois la vidéo, je ne vois que du matériel tout fait, avec uniquement des CMS, donc hors de notre portée si on veut les faire nous même.

Donc :
1°) Progrès certain, nette amélioration d'avoir un protocole universel.
2°) J'attends de voir ce que ça coûte. Je ne suis pas certain que ce soit moins cher que le DCC.

Le challenge va consister pour nous à analyser le protocole et à réaliser nous même des platines bon marché avec des composants soudables. :P

Bien amicalement
Denis
Titre: Re : Le bus CAN
Posté par: bobyAndCo le mars 12, 2017, 08:51:09 pm
Oui Denis, je suis comme toi convaincu que nous avons affaire à une technologie d'avenir au moins aussi importante que ne l'a pu l'être le DCC. On commence à voir apparaitre un certain nombre de bibliothèques ARDUINO autour de LCC gage d'une maîtrise des dépenses.

Une précision importante, LCC n'a pas vocation à remplacer DCC. Il est au contraire conçu pour le compléter.

C'est un sujet dont LOCODUINO devra se saisir !

Bien amicalement
Christophe
Titre: Re : Le bus CAN
Posté par: Dominique le mars 12, 2017, 10:25:05 pm
C'est intéressant de revoir Don Goodman-Wilson de RailStar, qui a conçu CmdrArduino (celui qu'on laisse au profit de DCC++). Don avait disparu du support de son produit, pour se consacrer à Open-LCB qui a finalement été choisi par NMRA comme standard qui s'appelle maintenant LCC. Bravo Don !

Je n'ai pas encore tout compris, à part le choix du bus CAN pour les échanges fiables et la câblage facile.

Ce que je peux en déduire (mais je vais surement me tromper), c'est que pour interconnecter autant de choses différentes que des aiguilles, des feux, des panneaux de led et boutons (TCO ?), des détecteurs d'occupation et Railcom, des manettes, des boosters (on dit centrale en général)... et un soft gestionnaire comme JMRI, ET TOUT CELA PLUG&PLAY, c'est forcément compliqué (tout ce qui est simple pour l'utilisateur est forcément une usine à gaz à l'intérieur).

L'expérience du Wifi et de TCP/IP ont donné lieu, finalement, à des choses simples à mettre en oeuvre, avec des composants pas cher (vu les millions d'unités produites) et des bibliothèques ad'hoc.

Mais ce ne sera pas à la portée du gars qui voudrait seulement faire clignoter un led 5 fois (joke), avant un bon moment.
Apparemment chaque "noeud" du réseau (connecté à un équipement) doit contenir un fichier de configuration qui semble ne pouvoir être construit et modifié que par JMRI. En tous cas c'est un fichier XML : ajouter un parser et un éditeur Wisiwyg dans un Arduino n'est pas une mince affaire !

Du coté des locos (la commande DCC++ par exemple), on imagine bien qu'un gros paquet de données sont stockées dans le noeud connecté à la centrale, de façon à piloter toutes les locos d'une manière standard (par exemple en leur donnant un ordre contenant la vitesse réelle à l'échelle, et non pas un cran DCC).

Cela dit, on va se faire un point d'honneur à Locoduino, à tenter de vous expliquer tout ça et de construire quelque chose.

Ca tombe bien, mon réseau est constitué de plusieurs éléments (à base d'Arduino) qui communiquent entre eux via un bus CAN  ;D ;D, sans JMRI, chaque élément (DCC booster, détecteurs d'occupations, contrôleur d'aiguilles, TCO, gestionnaire) a forcément sa configuration propre qui m'a valu une description sur papier, ainsi que les messages qui s'échangent entre modules.

Je ne me sens pas trop dépaysé, donc à suivre ...
Titre: Re : Le bus CAN
Posté par: DDEFF le mars 12, 2017, 10:30:35 pm
Citer
tout ce qui est simple pour l'utilisateur est forcément une usine à gaz à l'intérieur

Je confirme  ;D ;D ;D
Titre: Re : Le bus CAN
Posté par: Dominique le mars 14, 2017, 09:20:17 am
Cela veut dire que LCC est encore trop jeune !
Titre: Re : Le bus CAN
Posté par: gerard31 le septembre 10, 2017, 10:42:37 pm
Bonsoir,

Je ressort ce fil pour parler installation logiciel CAN.
Aprés divers essais analogiques ou numeriques sur mes micros reseaux HO et N je me tourne vers le CAN.
 J'ai récupéré le logiciel  dans "Mise en oeuvre du Bus CAN entre modules Arduino (2)"   et commencé l'installation.
J'ai utilisé la biblothéque CAN préconnisée dans l'article.
Avec l'Arduino Mega et l'interface CAN trouvée ici http://www.ebay.fr/itm/311379482437 le programme
 me dit bien  CAN bus init OK.
Arduino UNO plus même interface toujours CAN bus init OK.
Arduino Nano, même interface et programme que le UNO (modification  broche CS) cela se corse avec
CAN bus init echec et la led TX du Nano clignote en permanence.
J'ai vérifié les cablages, changer de Nano, d'interface, de support de Nano (terminal adapter de Deek Robot),
de port USB, rien n'y fait toujours échec.
Quelqu'un a-t-il était confronté à ce problème ? Toute info sera la bienvenue pour solutionner (tenter de)
ce problème.

Avec mes remerciements anticipés et bonne nuit aussi

Gérard :(
Titre: Re : Le bus CAN
Posté par: Dominique le septembre 11, 2017, 12:03:54 am
Le Nano mis à part, au delà du "CAN bus init Ok", est-ce que la communication entre le Mega et le Uno fonctionne ?

Étant donné que le Nano et le Uno ont le même contrôleur, il n'y a pas de raison que le Nano ne fonctionne pas, sauf erreur de câblage et d'initialisation.

Dominique
Titre: Re : Le bus CAN
Posté par: Jean-Luc le septembre 11, 2017, 08:27:03 am
CAN bus init ok indiqué que la communication SPI entre l'Arduino et le MCP2515 fonctionne correctement.

Pourrait-on avoir le code du Nano ? Quelle broche est employée pour le CS ?

Pourquoi la led TX flashe-t-elle ? Le programme du Nano écrit-il en permanence sur la sortie série ?
Titre: Re : Le bus CAN
Posté par: gerard31 le septembre 11, 2017, 12:01:15 pm
Bonjour et merci à tous les deux pour vos réponses,

Pour l'instant je ne me suis pas posé la question de la communication entre deux modules CAN.
Je débute et je m'en suis tenu au propos de Dominique :

On comprend bien ici que l'instruction CAN.begin(baudrate) démarre l'interface, avec un
compte-rendu "CAN_OK", sinon cela se répète car, à ce stade de l'initialisation (SETUP), si le bus CAN
ne démarre pas, il est inutile d'aller plus loin.
Personnellement je n'ai jamais vu d'échec sauf si la carte CAN n'est pas (ou est mal) branchée.

La broche employée pour CS est 10 comme indiquée ici http://www.locoduino.org/spip.php?article148

Pour le logiciel recopié et remis en forme (...???) voir le fichier joint.

Je ne suis pas posé encore la question pour la Led et le port série puisque j'ai toujours le message
"CAN échec sur le moniteur"

Merci pour votre aide en attendant de poursuivre mon apprentissage

Amitiés

Gérard
Titre: Re : Le bus CAN
Posté par: Jean-Luc le septembre 11, 2017, 01:33:33 pm
Essaye ceci pour voir où ça coince :

Ligne 56 de mcp_can_dfs.h (dans le répertoire où est la bibliothèque CAN), dans la directive :

#define DEBUG_EN        0

remplace le 0 par un 1 :

#define DEBUG_EN        1

La progression de l'initialisation apparaîtra sur la console
Titre: Re : Le bus CAN
Posté par: gerard31 le septembre 11, 2017, 03:23:04 pm
Bonjour Jean Luc,

Je viens de regarder la librairie MCP2515_lib-master et son fichier mcp_can_dfs.h.
Avant de faire une bêtise, je n'y ai pas trouvé le libellé indiqué dans votre message mais ceci :

#define MCPDEBUG        (0)
#define MCPDEBUG_TXBUF  (0)

juste aprés les instructions 8mhz. Il existe aussi celle-ci   #define CANDEBUG   1.

La question peut paraître naïve mais je préfére une confirmation sur la ligne à modifier
qui est, il me semble, #define MCPDEBUG       (0) a transformer en #define MCPDEBUG      (1)
Question subsidiaire quel editeur utlisez-vous pour afficher le numéro des lignes ?

Amitiés

Gérard
Titre: Re : Le bus CAN
Posté par: Jean-Luc le septembre 11, 2017, 04:51:17 pm
Bonjour Gérard

Ah. On n'est pas sur la même version. J'ai regardé la version qui est ici : https://github.com/Seeed-Studio/CAN_BUS_Shield
D'où vient la votre ?

Concernant l'éditeur, j'utilise atom (https://atom.io) mais l'éditeur de l'IDE Arduino affiche également les numéros de ligne via une case à cocher dans les préférences.

Amicalement
Titre: Re : Le bus CAN
Posté par: gerard31 le septembre 11, 2017, 11:36:30 pm
Bonsoir Jean-Luc,

Merci pour le lien Atom que j'ai installé et me permet d'ouvrir les fichiers .h
En ce qui concerne la bibliothéque MCP2515_lib-master c'est une mauvaise question car je n'en ai plus souvenir
à moins que ce ne soit ici au détour d'un des messages des forum.
J'ai installé la bibliothéque indiquée sur votre message et modifié la ligne 56 comme demandé
Je n'ai rien constaté sur la console hormis le sempiternel :
CAN BUS init echec
Init CAN BUS a nouveau
Enter setting mode fall
Le même fichier de mon ancienne bibliothéque MCP2515_lib-master indique à la ligne 39
#define DEBUG_MODE 0 que j'ai mis à 1. Même probléme, même sanction (message ci-dessus).
Je vous le joints en copie.
Au niveau du cablage je ne pense pas m'être trompé. Sur le Nano La pinoche 0 correspond à TX,
la 1 à RX et ainsi de suite.
Je remarque qu'au bout d'un certain temps la led TX du Nano cesse de clignoter.
La compilation ne pose pas de probléme ni le téléversement tant que COM1 n'est pas utilisé.
Demain je vais essayer de vérifier que la communication entre le Mega et UNO fonctionne
en reprenant vos articles.

Amitiés et bonne nuit

Gérard
Titre: Re : Le bus CAN
Posté par: Jean-Luc le septembre 12, 2017, 05:47:57 pm
La différence est le

Citer
Enter setting mode fall

Qui indique où ça échoue. Et ça échoue immédiatement lors de la mise en mode configuration du 2515 qui constitue la première tentative de lecture d'un registre du 2515 via le SPI.

Pour moi il y a un problème de câblage.
Titre: Re : Le bus CAN
Posté par: gerard31 le septembre 14, 2017, 12:14:11 pm
Bonjour Jean-Luc,

J'ai re-vérifié plusieurs fois le cablage de l'ensemble . Je n'ai rien trouvé qui me paraisse erronné.

En me baladant sur divers forums j'ai retrouvé les mêmes indications de branchement entre le Nano
et la carte CAN.

Voici trois photos qui montre ce que j'ai fait. 2 pour le Nano et une carte can.
La carte Nano22 branchement alimentation et Nano 12 liaisons CAN

J'espére simplement quelles sont de qualités suffisantes et j'attends votre verdict sur le sujet.

Amitiés et merci pour le temps que vous me consacrez

Gérard
Titre: Re : Le bus CAN
Posté par: gerard31 le septembre 14, 2017, 12:15:13 pm
et voici la 3éme
Question annexe : comment alimenter les 2 Arduinos sans générer de problème ?
Un est branché au port USB pour visualiser les messages reçus (moniteur).
Le second peut-il être alimenté par un autre port USB ou dois-je utiliser une alimentation extérieure ?
Configuration pour tester la bonne réception des messages du UNO vers le Mega.

Merci et bonne journée

Gérard
Titre: Re : Le bus CAN
Posté par: Dominique le septembre 14, 2017, 02:02:37 pm
Pour alimenter un Arduino, un simple chargeur USB suffit, ou une alimentation 6 à 12V avec une sortie Jack pour les Uno ou le Mega :

voir l'article http://www.locoduino.org/spip.php?article16 (http://www.locoduino.org/spip.php?article16)
Titre: Re : Le bus CAN
Posté par: gerard31 le septembre 14, 2017, 02:47:12 pm
Bonjour Dominique,

Tout à fait d'accord avec vous ; c'est ce que je fais en "Arduino autonome".
Mon interrogation est surtout le fait que  les 2 Arduinos sont "reliés" entre eux
 au travers des interfaces Can ((liaison H et L) et que transite-t-il au travers des interfaces Can ?

Merci et amitiés

Gérard
Titre: Re : Le bus CAN
Posté par: Dominique le septembre 14, 2017, 03:50:41 pm
Bonjour Gerard,

Les liaisons CanH et CanL sont "flottantes" et les signaux qui transitent sont considérés en "différentiel", sans référence au GND ou à l'alimentation des émetteurs et récepteurs.
Une émetteur peut être en 3,3V (un Due par exemple) et un récepteur en 5V (un Uno par exemple).
Il n'est pas besoin de relier les GND ensemble.

Chaque nœud est connecté au bus par l'intermédiaire d'une paire torsadée (blindée ou non).
Les deux extrémités du bus doivent être rebouclées par des résistances de 120 Ω (tolérance entre 108 Ω et 132 Ω).

Donc 2 fils et c'est tout.
voir :
http://www.locoduino.org/spip.php?article130 (http://www.locoduino.org/spip.php?article130)
http://www.locoduino.org/spip.php?article148 (http://www.locoduino.org/spip.php?article148)

... et les nombreux commentaires.

Bon courage
Dominique
Titre: Re : Le bus CAN
Posté par: Jean-Luc le septembre 14, 2017, 05:32:48 pm
Bonjour Gérard,

Je vais contredire en partie Dominique.

Bien que le signal soit différentiel, la différence de tension entre les masses des nœuds connectés aux réseau CAN ne doit pas dépasser une certaine valeur. La norme ISO-11898 indique un différentiel compris entre -2V et +7V. Le MCP2551 de Microchip indique de -12V à +12V. En pratique, quand toutes les cartes sont branchées sur une ou plusieurs alimentations, le réseau EDF donne une référence commune à tout le monde.

Dans ta plateforme d'essais, un problème de communication pourrait survenir si un ensemble de nœuds CAN est alimenté via un bloc secteur, alors qu'un autre ensemble de nœuds est alimenté via l'USB d'un ordinateur portable fonctionnant sur batterie. Dans ce cas, il se pourrait que le différentiel de masses dépasse ce qui est toléré avec des erreurs de transmission à la clé.
Titre: Re : Le bus CAN
Posté par: gerard31 le septembre 15, 2017, 10:19:15 pm
Bonsoir Jean-Luc et Dominique,

Quelques progrés.
Il faut lire et relire les deux articles et surtout le second pour la mise en application.

Aujourd'hui test de fonctionnement du réseau CAN entre le Mega et le Uno.
Procédure simple envoi d'une valeur différente par chacun d'eux et  réception
par l'autre : c'est OK sans probléme hormis ceux traditionnels de la copie du programme. MERCI

La deuxième phase mise en application sur le reseau et j'ai déjà mon idée.
Avec le Uno je teste  le nombre de tour (decodeur IR Dominique) et transmet l'info au Mega
 qui gére la circulation. Lourd sans doute mais je me fait la main.

Ce matin j'ai changé l'IDE Arduino (version 1.6.13 à 1.8.4) et réessayer de téléverser sur mes Nanos
toujours impossible. Personne ne sétant manifesté je pense qu'il s'agit peut être d'un probléme ponctuel.

Je n'ai pas changé le quartz sur les cartes Can chinoises 2515 donc 8 mhz.

Pour Dominique bon courage pour l'intervention et bon prompt rétablissement.

Amitiés

Gérard

Titre: Re : Le bus CAN
Posté par: Dominique le septembre 15, 2017, 11:08:41 pm
Bonsoir Gérard,

Pour trouver ce qui se passe sur le Nano, le mieux serait de poster le schéma complet et le programme. En général on ne voit plus la petite erreur qui est sous ses yeux et un oeil extérieur la voit du premier coup.
Si ça marche sur le Uno et pas le Nano, ça reste étrange.

Amicalement
Dominique
Titre: Re : Le bus CAN
Posté par: gerard31 le septembre 15, 2017, 11:57:07 pm
Bonsoir Dominique,

Je suppose le shéma des branchemens entre le Nano et la carte Can ?

Amitiés

Gérard
Titre: Re : Le bus CAN
Posté par: Dominique le septembre 16, 2017, 08:49:08 am
Le schéma complet et le programme complet c'est mieux.
Titre: Re : Le bus CAN
Posté par: gerard31 le septembre 17, 2017, 12:49:10 pm
Bonjour Dominique,

Voici de quoi satisfaire les deux demandes.
J'ai eu une surprise hier. J'ai laissé tourné mon Nano pendant plusieurs heures.
Au début la led Tx clignote en permanence ; à mon retour  le moniteur
affiche correctement le contenu de la valeur envoyée ????????
Ci-joint les deux fichiers shèma de cablage des cartes et programme utilisé
(il porte le nom...UNO mais est aussi adapté au Nano);

Amitiés,

Gérard
Titre: Re : Le bus CAN : Quartz 8 MHz et quartz 16 MHz
Posté par: bobyAndCo le septembre 26, 2018, 03:51:05 pm
Bonjour,

Je ne crois pas que cela est déjà été évoqué sur le forum, je vous pousse donc cette info. Si vous utilisez sur le même bus CAN des cartes à 8 et des cartes à 16 MHz, il faudra régler les vitesses en conséquence dans votre programme. La vitesse du 8 MHz devra être le double de celle du 16 MHz.

Respectivement par exemple : CAN.begin(CAN_1000KBPS) et CAN.begin(CAN_500KBPS)

Bien amicalement
Titre: Re : Re : Le bus CAN
Posté par: Dominique le septembre 26, 2018, 04:19:33 pm
Bonjour Dominique,

Voici de quoi satisfaire les deux demandes.
J'ai eu une surprise hier. J'ai laissé tourné mon Nano pendant plusieurs heures.
Au début la led Tx clignote en permanence ; à mon retour  le moniteur
affiche correctement le contenu de la valeur envoyée ????????
Ci-joint les deux fichiers shèma de cablage des cartes et programme utilisé
(il porte le nom...UNO mais est aussi adapté au Nano);

Amitiés,

Gérard

Quelques remarques sur .ino

- ne pas mettre de GOTO !
- ne pas mettre de delay() mais faire des tests sur la valeur de millis()
- CAN_recup() : ne garder que la première partie, le traitement d'un seul message par loop dans la memoire circulaire doit être dans la loop.
- Serial.println(Rbuf[8]) n'affiche que le 8ème octet et ça ce sert à rien car il est affiché avant correctement
- dumpcan est une variable locale dans CAN_recup et non initialisée. Il faut la mettre en globale.
- ...

Donc à revoir...