Hehe
Je connais assez bien le sacerdoce d'aider les newbies, avec parfois un petit agacement face au temps perdu à devoir répondre à des personnes qui posent des questions avant même de faire un petit effort personnel de recherche et de documentation.
Aussi j'essaye de vous épargner sur ce point, si si j'vous jure
Effectivement le CAN est au centre de mes réflexions en ce moment.
Je ne pense pas être passé à côté des aspects essentiels de la communication sur bus CAN, ou du moins pas à côté de ceux évoqués plus haut.
C'est juste que j'arrive avec un oeil neuf, donc j'ai envie de prendre le temps de réévaluer les questions fondamentales avant d'emprunter les chemins déjà balisés.
Pas de doute sur le fait qu'au niveau physique la communication est bien assurée sur le bus.
Mais sur l'ensemble de la chaîne de liaison, j'ai évalué que la faiblesse se trouve entre l'arduino et le MCP2515, voire dans le MCP2515 lui-même, trop faiblement bufferisé.
Avec un bus à 500 kbs, j'ai mesuré que deux arduino peuvent échanger jusqu'à 4000 trames de 0 octet par seconde (et 2400 trames de 8 octets).
En réception, ca fait potentiellement un message à traiter toutes les 250 microsecondes, qui doit être consommé rapidement par l'arduino sous peine de perte de messages.
Les possibilités de filtre au niveau du MCP2515 apportent un début de réponse au risque de perte de message utile, dans la mesure ou ceux qui sont hors scope sont éliminés dès le départ.
Mais si on reçoit plusieurs messages utiles en rafale, le risque demeure.
Il faut un arduino dont le programme est structuré en unités d'oeuvres très courtes, capable de s'interrompre pour lire les messages du MCP2515, quitte à les placer temporairement dans un buffer plus gros en RAM. Ce n'est pas toujours évident à obtenir.
Par exemple : j'ai en tête de réaliser une mini console de bus can, avec un affichage direct sur écran LCD, pour y restituer tous types d'infos qui peuvent passer sur le bus.
D'habitude j'utilise des LCD 4x20 à interface I2C, très bon marché et simples à mettre en oeuvre, mais dont le principal inconvénient est la lourdeur de la laison I2C avec un PCF8574 en intermédiaire côté LCD.
Visuellement, on peut se contenter d'un rafraichissement d'écran chaque demi seconde. Le problème reste de ne pas perdre de messages CAN pendant ce rafraichissement, qui peut durer jusqu'à 20 millisecondes. Je suis bien parti pour devoir réécrire une bibliothèque LCD_I2C interruptible.
Autre point : en potassant le datasheet du mcp2515, j'ai aussi vu que les deux filtres/buffers de réception ne sont pas traités de manière égale.
Les messages issus du filtre0 peuvent déborder dans le buffer1 si le buffer0 n'a pas été consommé.
Il y a donc intérêt à mettre la sélection des messages importants dans le filtre0.
A mon sens, c'est encore une rustine qui vise à contourner la faible bufferisation du MCP2515.
Perso, si je devais adresser des besoins extrêmes, je serais assez tenté d'ajouter un arduino intermédiaire, dont la seule fonction serait de gérer la bufferisation du MCP2515 en exploitant toute sa RAM.
Et encore, je reste dans le cas favorable où le bus CAN est à seulement 500 kbs, c'est-à-dire un débit utile plus faible que celui de la liaison SPI entre l'arduino et le MCP2515.
Il n'y a donc pas de risque que l'arduino se fasse déborder par le débit sur le bus, tant qu'il garde un mimimum de dispo régulière pour lire le MCP2515.
Dans ce contexte, il me semble raisonnable de prévoir un système où, par exemple, une centrale émet une consigne de bascule d'aiguillage, puis se met à l'écoute d'un message d'information de changement d'état en provenance de l'aiguillage, pour s'assurer que la commande a bien été traitée et éventuellement réemettre la consigne.
Ca c'est déjà ce que j'appelle un sur-protocole, avec un début d'acquittement.
Je me pose donc la question de normer ce sur-protocole, pour que la plupart des cas d'usage puissent s'inscrire dans un modèle générique.
Et effectivement le risque est d'alourdir les trames de base et donc de réduire le débit utile sur le bus.
Il y a certainement un juste curseur à positionner.
Et dans tous ça, il est clair que les règles de valorisation des identifiants des messages CAN sont essentielles, et pas forcéement évidentes à édicter.
Techniquement, on est libre d'utiliser des identifants courts sur 11 bits ou étendus sur 29 bits.
La valorisation des identifiants est également libre. On peut y mettre la notion de type de message et/ou d'émetteur et/ou de destinataire.
Et encore, la notion d'émetteur / destinataire peut correspondre au MCP2515 ou à un dispositif plus fin, comme une commande d'aiguillage ou un capteur quelconque.
Ajoutez à cela les notions de priorisation des messages selon la valeur de l'identifiant (protocole CAN), ainsi que les possibilités de filtrage offertes par le MCP2515.
Au final je trouve qu'il n'est pas évident de se faire une religion sur le bon usage de la bestiole.
