Discussions Générales > Bus CAN
Réception CAN optimale
Dominique:
Bon d’accord c’est un benchmark du bus CAN et des fonctions d’emission et réception des Arduino qui sont de bons exemples.
Plusieurs questions :
- sur quels Arduino ?
- avec quelle interface CAN (le petit chinois bleu à 8 MHz ?)?
Donc les tests sont OK et on peut passer à autre chose, par exemple les applications au modelisme qui nous intéressent ici.
Quel est ton projet personnel ?
Bien entendu le sujet du train du futur avec des modules communicant via CAN est très intéressant, mais surtout la définition des messages à échanger, qui va déterminer les risques de pertes et leurs solutions.
Je suis ravi que tu nous rejoignes sur ce terrain.
Mais Noël approche et je ne vais pas avoir beaucoup de temps.
Bon Noel en tout cas ;D
Amicalement
Dominique
bricoleau:
Oui exact c'est juste du benchmark et ce n'est pas plus intéressant que ça.
Mais sur ce point je n'ai fait que réagir et répondre, je n'ai pas introduit le sujet ici.
Je suis effectivement en train de faire diverses expérimentations pour bien définir les limites d'usage des petites cartes CAN à 8Mhz (oui les "petits chinois" à 2€ pièce).
J'utilise des cartes arduino standard, c'est-à dire tout ce qui a un atmega328p à 16 Mhz (arduino classique / nano / pro mini / arduino ethernet)
Mon projet modélisme est exposé dans un fil de discussion dédié, dans la section du forum prévue à cet effet. C'est là qu'il sera développé au grée de mes avancées.
Ici on est dans les discussions générales autour du bus CAN, il m'a donc semblé naturel d'y mettre ce que j'aurais aimé trouver à ce sujet, et qui pourrait être utile pour les suivants.
Mais bon si tu trouves que c'est sans valeur ajoutée pour le forum, ok je m'adapte sans une once de contrition. Cela me va aussi.
Sur le bus CAN spécifiquement : je travaille d'abord tous les aspects techniques émission/réception. Là j'en suis à l'implémentation du buffer circulaire en réception, qui me semble indispensable.
J'ai encore pas mal de tests à faire, en particulier sur les diverses stratégies possibles d'utilisation des filtres (et donc de codage des identifiants de messages).
Car je pense que ce sont les contraintes techniques qui vont dicter les bonnes règles d'usage des filtres.
Au bout du bout, je vise une implémentation la plus propre possible, packagée sous forme d'une bibliothèque la plus simple possible d'utilisation.
Je peux détailler ce cheminement ici dans la section CAN, ou bien me contenter d'en exposer un exemple de mise en application dans le cadre de mon projet, lorsque j'en serais là. Tout me va.
Bon Noel également :)
Dominique:
--- Citation de: bricoleau le décembre 23, 2017, 04:33:15 pm ---Mais bon si tu trouves que c'est sans valeur ajoutée pour le forum, ok je m'adapte sans une once de contrition. Cela me va aussi.
--- Fin de citation ---
C'est maladif chez moi, il faut que je modère 8) ??? ::)
Mais pas du tout, c'est très utile pour tout le monde car le CAN doit faire peur à beaucoup de modélistes et on est malheureusement trop peu à s'en servir. De plus tes tests confirme ceux que j'avais fait il y a 2 ans.
Il se trouve qu'au bout de quelques semaines, j'en ai eu marre des tests et je suis parti dans l'utilisation du Can dans mon projet et j'avoue que ça se passe plutôt bien.
En passant j'ai regardé tes autres contributions, toujours très interessantes et précises, et j'ai pensé ajouter un peu de mon cru à celle consacrée aux boutons poussoirs.
http://forum.locoduino.org/index.php?topic=122.msg4268#msg4268
Bonne fêtes
Dominique
Jean-Luc:
Dominique, le modérateur immodéré :)
Le sujet est tout à fait intéressant et il faut continuer ce fil sans aucun doute.
Coincidence, j'avais choisi le MCP2515 pour une étude de cas dans un cours sur la modélisation et le model-checking (c'est juste parce que le composant est assez simple pour que le modèle soit court)
Concernant cette histoire de bufferisation, il faut souligner quelques petites choses (bus à 1Mb/s):
1) un message CAN nécessite de 47 à (trame standard, zéro octets de données, bit stuffing minimum) à 160 µs (trame étendue, 8 octets de données, bit stuffing maximum) pour être transmis sur le bus. Les tables ci-dessous donnent ces temps
Trame standard
Nb. d'octets de donnéesMinimumMaximum047551556526375371854799558710569511571031258111135
Trame étendue
Nb. d'octets de donnéesMinimumMaximum06780175902831003911104991205107130611514071231508131160
Il faut également ajouter les temps inter-messages qui est de 4 µs
2) récupérer un octet par le SPI à 8MHz nécessite 1µs et un message occupe de 5 à 13 octets selon le nombre d'octets de données. À cela il faut ajouter 2 octets pour connaître l'état des message buffer et un octet envoyé au MCP2515 pour demander la lecture du message buffer. On ne distingue pas les trames étendues et les trames standard car ceci demanderait plus de temps que de récupérer l'identifiant complet même si la partie étendue ne sert pas. Lire l'état et lire un message buffer prend donc de 8 à 16 µs.
Dans le pire cas, on vide un message buffer contenant une trame de 8 octets, soit 16µs pendant que le message le plus court possible est en cours de réception dans le MAB, soit 47µs + 4µs. Il faut évidemment ajouter le temps d'exécution des instructions de traitement du message mais je doute que ça atteigne les 35µs restantes.
Donc je pense que si on procède correctement on ne perd pas de message à ce niveau à condition de vider les message buffers dans l'ISR. On doit aussi prendre en compte le temps d'exécution des autres ISR (par défaut il y a seulement l'ISR du Timer0) et également le temps d'envoi d'un message vers le 2515 (14µs au pire) qui bloque le SPI et les IT quand on utilise les transactions. Dans certaines circonstances, ça commence à être tendu.
Toutefois, il faut aussi prendre en compte le système complet. Un nœud ne va pas recevoir des messages à n'importe quel moment et à n'importe quel rythme. Si on veut maîtriser ce qui se passe sur le bus, il faut définir pour chaque message une période d'émission. Par conséquent, au lieu d'envoyer un message quand la donnée correspondante est mise à jour, il faut envoyer la donnée périodiquement sur le bus avec une période compatible avec le procédé piloté. C'est à dire transmettre des états et non des événements. Ceci a deux avantages :
1) on connaît pas construction la périodicité des messages et le temps minimum d'inter-arrivée des messages sur un nœud. On est donc plus prédictible sur le comportement.
2) si suite à un bug ou un dysfonctionnement un message est perdu, ça n'a pas d'importance puisque le message est répété. On est donc plus robuste.
Dominique:
Grandiose ;D
A déguster sans modération !
Joyeux Noël à tous
Navigation
[#] Page suivante
[*] Page précédente
Utiliser la version classique