Auteur Sujet: BreakoutBoard CAN  (Lu 18002 fois)

Jean-Luc

  • Global Moderator
  • Hero Member
  • *****
  • Messages: 1204
    • Voir le profil
Re : BreakoutBoard CAN
« Réponse #30 le: janvier 24, 2015, 04:07:08 pm »
Nickel !

Dominique

  • Global Moderator
  • Hero Member
  • *****
  • Messages: 1337
  • 100% Arduino et N
    • Voir le profil
Re : BreakoutBoard CAN
« Réponse #31 le: janvier 24, 2015, 04:24:35 pm »
et c'est mieux avec 2 cartes et 2 Megas
J'ai testé en passant les exemples qui fonctionnent donc nickel, comme les cartes, notamment la reception sous interruption.
Ca tourne depuis 1/2 heure

Dominique

  • Global Moderator
  • Hero Member
  • *****
  • Messages: 1337
  • 100% Arduino et N
    • Voir le profil
Re : BreakoutBoard CAN
« Réponse #32 le: janvier 24, 2015, 04:29:17 pm »
C'est vrai que ce n'est pas plus compliqué que l'I2C.
Je n'ai pas eu le temps d'étudier les principes. Si je comprend bien l'exemple fait un envoi avec l'id 0x00 et tous les récepteurs reçoivent la même chose.
Comment spécifier un récepteur spécifique ? La réponse doit être "avec les filtres" je suppose.

Jean-Luc

  • Global Moderator
  • Hero Member
  • *****
  • Messages: 1204
    • Voir le profil
Re : BreakoutBoard CAN
« Réponse #33 le: janvier 24, 2015, 06:21:50 pm »
Oui, c'est avec les filtres. Si aucun filtre n'est en place, tous les nœuds reçoivent tous les messages sauf ceux qu'ils émettent.

Comme je t'expliquais jeudi, le CAN fonctionne un peu comme un crieur public. Tous les nœuds sont potentiellement destinataires. Si des nœuds ne sont intéressés que par certains messages, ils doivent mettre en place des masques et des filtres

Il y a 2 masques et 6 filtres. Il faut tous les initialiser.

Exemple :

  CAN.init_Mask(0,0,0xFFFF);
  CAN.init_Mask(1,0,0xFFFF);
  CAN.init_Filt(0,0,1); // Filtre 0, trame standard, id = 1
  CAN.init_Filt(1,0,3); // Filtre 1, trame standard, id = 3
  CAN.init_Filt(2,0,0); // Filtre 2, trame standard, id = 0
  CAN.init_Filt(3,0,0); // Filtre 3, idem
  CAN.init_Filt(4,0,0); // Filtre 4, idem
  CAN.init_Filt(5,0,0); // Filtre 5, idem

Les masques font que tous les bits de l'identifiant sont significatifs
Les filtres font que seuls les identifiants 0, 1 et 3 sont acceptés
« Modifié: janvier 24, 2015, 06:23:48 pm par Jean-Luc »

Jean-Luc

  • Global Moderator
  • Hero Member
  • *****
  • Messages: 1204
    • Voir le profil
Re : BreakoutBoard CAN
« Réponse #34 le: janvier 24, 2015, 06:33:26 pm »
Plus la valeur de l'identifiant est faible et plus sa priorité est élevée.

Quand on construit un système avec du CAN, on définit une messagerie : l'ensemble des messages qui vont transiter et leur identifiant.

Par exemple, supposons que tu utilises le bus pour envoyer des ordres à des moteurs d'aiguillage et pour envoyer des ordres à des signaux. Tu vas définir un jeu d'identifiants pour les messages destinés aux cartes qui commandent les moteurs d'aiguille. On va rester en trame standard, donc les identifiants font 11 bits. Supposons qu'au maximum tu aies 16 cartes de moteurs d'aiguillage : 4 bits

Par exemple, on va choisir un identifiant qui sera 0000111xxxx, xxxx étant le numéro de carte. Ensuite les données du message vont spécifier la position de chaque moteur. Les cartes aiguillage vont donc définir un masque à 11111111111 (donc 0xFFFF) dans la bibliothèque et un filtre à 0000111xxxx, xxxx étant défini par la position d'un dip-switch sur la carte. Ensuite si tu branches une carte pour piloter le TCO et que tu veuilles recevoir tous les ordres à destination des moteurs d'aiguillage, elle spécifiera un masque à 11111110000 car xxxx n'a pas d'importante et un filtre à 00001110000, comme les 4 bits de poids faible du masque sont à 0, les 4 bits de poids faible du filtre sont ignorés dans la comparaison avec les identifiants des messages entrant. Donc le TCO recevra tous les messages à destination des cartes aiguillage.

Pour les signaux, supposons qu'on ait 32 cartes, on va choisir un identifiant moins prioritaire : 000010xxxxxx. Idem, masque à 11111111111, filtres à 000010xxxxx, xxxxx étant récupéré d'un dip-switch. Le TCO quand à lui aura un 2e masque à 111111 et un 2e filtre à 00001000000. Il récupérera tous les ordres pour les signaux.

Enfin, si les cartes de pilotage des aiguillages émettent les positions effectives récupérée via des contacts de fin de course, on attribue un autre identifiant, 0000001xxxx, plus prioritaire car la connaissance de la position des aiguillages est plus importante que ce qui s'affiche sur les feux ou les commandes des aiguillages. Les autres cartes aiguillage et les cartes feux ne verront pas ces messages car cet identifiant n'est pas accepté par leur filtre.
« Modifié: janvier 25, 2015, 01:22:35 am par Jean-Luc »

Jean-Luc

  • Global Moderator
  • Hero Member
  • *****
  • Messages: 1204
    • Voir le profil
Re : BreakoutBoard CAN
« Réponse #35 le: janvier 31, 2015, 04:39:27 pm »
Bonjour,

Je viens de faire un essai de performance sur le CAN.

Le bus est réglé a 125kbps, pas agressif donc mais, pour les accessoires, c'est largement suffisant.
Deux Arduino sont connectés : un Nano et un compatible Uno (le Visduino que je viens d'acheter).

Les deux Arduino sont chargés avec le même sketch. Le sketch fait la chose suivante :

Dans setup
- lecture d'une broche numérique pour avoir l'identifiant du message CAN. Sur l'un des Arduino, cette broche est raccordée a la masse et sur l'autre elle est raccordée à 5V. Les sketchs récupèrent dont respectivement un identifiant 0 et un identifiant 1.
- intialisation d'un buffet ne comprenant qu'un seul octet.
- après initialisation du CAN, envoi d'une trame avec l'octet en question.

Dans loop
- attente de réception de message, on utilise une interruption externe.
- quand le message est reçu, il est lu, on vérifie que ca longueur est bonne et que l'octet de données est bon puis il est renvoyé.

C'est donc une sorte de double ping pong avec deux messages qui tournent.

Le rythme d'arrivée des interruptions sur un des Arduino est de 1,64ms et stable. C'est équivalent à 205 bits. Sachant qu'au maximum une trame comportant un octet de données comprend 65 bits et que le contrôleur attend 11 bits pour s'assurer que le bus est libre, soit 76 bits. Donc 152 bits. Il y a du temps perdu dans le programme et sur la communication SPI également. Ça me semble donc cohérent.

Dominique

  • Global Moderator
  • Hero Member
  • *****
  • Messages: 1337
  • 100% Arduino et N
    • Voir le profil
Re : BreakoutBoard CAN
« Réponse #36 le: août 23, 2015, 10:38:43 pm »
Bonjour,

Concernant le DUE, il y a un fil très développé sur le forum Arduino qui est consacré à la réalisation d'une carte d'extension et d'une bibliothèque.

http://forum.arduino.cc/index.php?topic=131096.480

La bibliothèque existe (Due-CAN), mais pas l'extension apparemment constituée d'un seul chip.

On y voit aussi comment utiliser les 2 bus CAN disponibles sur le Due (la doc n'en présente qu'un seul).

Qu'en pensez-vous ?

Dominique

  • Global Moderator
  • Hero Member
  • *****
  • Messages: 1337
  • 100% Arduino et N
    • Voir le profil
Re : BreakoutBoard CAN
« Réponse #37 le: août 23, 2015, 10:50:54 pm »
La bibliothèque est là

https://github.com/collin80/due_can

1600 messages CAN par seconde sur une Zoe de Renault parfaitement reçus par un Due : pas de souci à se faire pour nos trains  8)


DDEFF

  • Sr. Member
  • ****
  • Messages: 449
    • Voir le profil
Re : BreakoutBoard CAN
« Réponse #38 le: août 29, 2015, 07:37:40 pm »
De retour de Montpellier  8) 8) 8)  ...

Merci Dominique

Effectivement, fil très développé (34 pages !!). Dans l'un des liens, la façon "d'extraire" les 2 bus CAN de l'Arduino DUE (j'ai failli dire du DUE  ;D) et l'utilisation du SN65HVD234. Nous, ce seront des 2551 si j'ai bien tout compris.

Quand tu dis la doc n'en présente qu'un seul, c'est à nuancer : ça dépend quelle doc. Si tu prends celle-là, il y a bien tout.
http://www.robgray.com/temp/Due-pinout-A4.png

Pour le MEGA, j'aime bien celui-là :
http://www.arduteka.com/wp-content/uploads/2013/02/ArduinoMega.png

Ensuite, la bibliothèque due-can, d'après ce que je vois dans le due_can.h, on gère bien le CAN 0 et le CAN 1.
Par contre, c'est du costaud !
Il va falloir que je détaille les exemples donnés pour mieux comprendre.

Et, pour terminer, même si je suis convaincu que le bus CAN est très largement dimensionné pour nos trains, ton argument "1600 messages par seconde" ne tient pas. Si ce sont des messages d'1 bit, ça ne fait pas un gros débit ( ;D ;D)

Plus sérieusement, je pense que je vais être obligé de passer par les mots de 29 bits et pas 11 bits.
En effet, la limite à 30 nœuds maximum est, dans mon cas, un problème.

Dominique

  • Global Moderator
  • Hero Member
  • *****
  • Messages: 1337
  • 100% Arduino et N
    • Voir le profil
Re : BreakoutBoard CAN
« Réponse #39 le: août 29, 2015, 08:33:26 pm »
Bizarrement j'ai vu que Marklin utilise aussi des Id de 29 bits.

Franchement je n'en vois pas la justification. Mais, bon, ils font ce qu'ils veulent.

Méfies toi tout de même de la façon de faire le filtrage. Avec 2 masques et 6 filtres seulement, sur des Id de 29 bits, tu vas souffrir ! Tu as vu les questions sur le forum Arduino !

Attendons l'avis de l'expert : Jean-Luc

Jean-Luc

  • Global Moderator
  • Hero Member
  • *****
  • Messages: 1204
    • Voir le profil
Re : BreakoutBoard CAN
« Réponse #40 le: octobre 09, 2015, 09:43:33 am »
Bonjour,

Pourquoi aurais-tu besoin de 29 bits d'identifiant de message (je rappelle que les 11 bits ou 29 bits sont les identifiants de message, pas les données du messages. Les données vont de 0 (message de signalisation d'événement donc sans données) à 8 octets.

jac56

  • Newbie
  • *
  • Messages: 12
    • Voir le profil
Re : BreakoutBoard CAN
« Réponse #41 le: décembre 06, 2015, 12:41:43 am »
Bonjour,

J'ai commencé à étudier le bus CAN au travers des articles de Locoduino et du forum (encore bravo); j'aurais quelques questions à poser à propos du schéma de câblage du breakout du CAN bus présenté un peu plus haut dans ce fil (cf. l' intervention de Jean-Luc du 23 janvier, dans [2]). Ces interrogations sont simplement formulées  pour m'éviter doutes et tâtonnements. Elles seront peut-être utiles à d'autres et permettront de nous assurer que notre compréhension est correcte. Malgré l'excellente clarté des explications, il peut se faire que je comprenne de travers.

En l'étudiant, il semblerait que le schéma puisse être beaucoup simplifié, en ne câblant pas ce qui n'est, en réalité, pas utilisé, et sans perdre la flexibilité pour le couplage, au choix, à des Arduino Uno ou à des Due.

Par exemple, tout ce qui concerne le Reset physique semble inutile puisqu'on se charge de le faire par logiciel avec une commande SPI, quand c'est nécessaire. Sur un montage définitif, le bouton-poussoir ne sera même pas accessible...
On peut donc omettre : bouton-poussoir, pont de résistances, diode. Et dans ces conditions, même la borne 6 (Reset) du bornier K3 est superflue. K3 peut donc se limiter à cinq contacts.

Par ailleurs, il y a toutes les pins de IC1 qui ne sont pas du tout utilisées dans la façon présentée d'utiliser les composants CAN (tous les TXiRTS ou RXiBF, pin 4 à 6 et 10-11 de IC1), ainsi que SOF (pin 3). Il s'ensuit que le bornier K5 tout entier peut-être omis. A moins que cela présente un intérêt pour tester le fonctionnement du montage à l'oscillo (certaines pins sont des signaux d'interruptions)? Sur un proto, peut-être cela présente-t-il un intérêt, mais est-ce utile sur un montage de 'série'?

L'examen de la bibliothèque CAN proposée pour le Uno ne montre même pas de possibilités d'utiliser les fonctionnalités de ces 'registres' TXiRTS ou RXiBF autrement que par logiciel au travers du bus SPI. Je n'ai pas encore vérifié dans le cas Due.
Est-ce une compréhension correcte du montage proposé? Et le breakout ainsi simplifié fonctionnera-t-il de façon satisfaisante?


Enfin, dans la même intervention de Jean-Luc, l'usage des straps est défini.
L'usage du premier cité (S2 entre GND et Rx) ne me paraît pas totalement clair.
Si c'est pour utilisation avec un Due, on utilise les pins 2 et 3 de K4 pour piloter directement le transceiver CAN MCP2551 (le 2515 ne sert pas du tout) avec les Tx, Rx qui existent spécifiquement sur le Due pour piloter un CAN.  Dans ce cas, il faut omettre le strap S2 de façon à atténuer la réception Rx en 5V sur le MCP2551 pour l'adapter au 3,3V du Due grâce à un pont diviseur ?
Si c'est pour utilisation avec un Uno (5V), cette atténuation n'est au contraire pas souhaitable, donc il  faut shunter le strap dans ce cas. De toutes façons, avec un Uno, on n'utilise pas ce canal direct pour piloter le MCP2551, puisqu'on passe par les pin Tx Rx du contrôleur MCP2515, lui-même relié au bus SPI du Uno. Les bornes 2 et 3 de K4 sont 'à vide' dans ce cas. Je me demande même si la résistance de tirage ainsi introduite entre Rx et GND (R4= 18kOhm ) est nécessaire avec le Uno; elle va jouer sur l'entrée Rx du 2551. Elle ne semble pas nuisible puisque les tests montrent un fonctionnement correct, mais est-elle utile? Dans ce cas ne pourrait-on mettre le strap en série avec R5? Et on ne shunterait le strap, ainsi disposé, que pour l'utilisation avec un Due?

Est-ce une évolution correcte?

D'avance merci et encore bravo pour cette initiation au CAN.


Jacques

DDEFF

  • Sr. Member
  • ****
  • Messages: 449
    • Voir le profil
Re : BreakoutBoard CAN
« Réponse #42 le: décembre 06, 2015, 10:30:11 am »
Bonne analyse.
Le circuit a été conçu pour faire des tests et pouvoir utiliser toutes les broches, s'autoriser tous les essais.

Il est donc "surdimensionné". Mais le circuit imprimé prévoit tous les cas.

Ce qui ne nous impose pas de souder tout.

1°) Le reset n'est pas utile. Ou, du moins, je ne m'en suis jamais servi.
2°) K5 ne me sert à rien
3°) Avec un DUE, on ne met pas les straps S2, S3 et S4, ce qui fait que le MCP2515, le quartz et autres ne sert pas
4°) Avec les Arduino qui n'ont pas de CAN intégré (ATmega328), on met, au contraire, les 3 straps S2, S3 et S4.
Les broches 2 et 3 de K4 ne servent alors à rien. Par contre, je pense que R4 est nécessaire en pulldown.

Pour avoir utilisé dans le même montage des NANO et un DUE avec ces cartes, je confirme qu'elles fonctionnent parfaitement (voir photo jointe et article à venir)

Attention a un "détail" :
Pour le DUE, il faut utiliser la bibliothèque due_can_master
Pour les Atmega328, il faut utiliser la bibliothèque CAN_BUS_Shield-master

Dominique

  • Global Moderator
  • Hero Member
  • *****
  • Messages: 1337
  • 100% Arduino et N
    • Voir le profil
Re : BreakoutBoard CAN
« Réponse #43 le: décembre 07, 2015, 02:21:18 pm »
Merci à Denis qui a répondu complètement à cette excellente analyse de la carte conçue par Jean-Luc et dont nous avons pu fabriquer quelques exemplaires que nous utilisons avec bonheur !

Cette carte avait d'abord l'énorme avantage de coûter moins cher que les versions commerciales, ce qui est normal en DIY.

Pour le Due, on peut trouver en Chine quelques BoB (BreakoutBoard) ne comportant que le transmetteur donc pour quelques € seulement.

Si vous pensez pouvoir proposer un circuit simplifié pour les Mega, Uno et Nano, ce serait super. L'article 13 sur le site éditorial vous donnera les fournisseurs intéressants :
http://www.locoduino.org/spip.php?article13
Notamment Electrodragon et TME.

Cordialement
Dominique

Jean-Luc

  • Global Moderator
  • Hero Member
  • *****
  • Messages: 1204
    • Voir le profil
Re : BreakoutBoard CAN
« Réponse #44 le: décembre 07, 2015, 02:29:40 pm »
Bonjour,

Effectivement certains élément peuvent ne pas servir. La carte a été conçue pour être universelle.

- K5 a été mis pour pourvoir brancher facilement un oscillo ou un analyseur logique. Notamment SOF qui permet de synchroniser avec le début de trame
- le bouton reset à été mis par sécurité
- le diviseur de tension sur RX permet de brancher un micro 3,3V
- si on a un DUE qui intègre un contrôleur CAN, il suffit d'utiliser le 2551 et on ne monte pas.

Dans mon esprit, cette carte n'est pas destinée à du déploiement mais à de la mise au point (du moins pour moi)

La résistance de tirage est utile pour ne pas que TX flotte et que le bus CAN reçoive des bits aléatoires tant que le 2515 n'est pas initialisé.

Par contre il faut monter la circuiterie de RESET pour assurer le démarrage du 2515. Si il plante, le reset via SPI n'aura aucun effet je pense.