Quel est le débit maximal de trame (message) du bus CAN à 125 kbit / s?

Mon bus CAN fonctionne à 125 kbit / s et utilise exclusivement le format de trame étendu. Je voudrais savoir quel est le taux maximum de trame CAN que je peux envoyer. Supposons que la longueur des données soit toujours de huit octets.

Selon cette page Wikipedia , chaque trame a une longueur de trame maximale de (1+11+1+1+18+1+2+4+64+15+1+1+1+7) = 128bits:

Entrez la description de l'image ici

Compte tenu d'un espacement intertrame d'au moins trois bits , le débit maximal de paquets inférieur à 125 kbit / s devrait être: 125000 / ( 128 + 3) = 954trames par seconde.

Mais dans mon test, je n'ai pas pu atteindre ce niveau. La fréquence d'images maximale que je peux atteindre (avec les huit octets de données) est d'environ 850 images par seconde.

Quel est le problème ici - mon calcul ou ma méthode de test?

communication can speed

— Penghe Geng
source

Regardez-le avec une portée et voyez ce que vous obtenez réellement. Votre matériel n'est peut-être pas prêt à transmettre une nouvelle trame immédiatement après en avoir envoyé une. De plus, tenez-vous compte du temps ACK? Votre somme de bits sans étiquette n'est pas utile pour nous dire exactement ce que vous comptez.

— Olin Lathrop du

En pratique, il est difficile d'obtenir une utilisation à 100% du bus pendant une période prolongée sur un bus CAN, en raison de la nécessité de temps ACK et d'espacement intertrames. Votre contrôleur CAN peut ne pas être en mesure de prendre en charge l'utilisation du bus à 100% pendant une période prolongée.

— Tristan Seifert

Selon exactement les données que vous envoyez, le bourrage de bits peut augmenter la taille de votre cadre jusqu'à 10%.

— WhatRoughBeast

@xiaobai - Non, la longueur du champ de données change. Quant au lien, vous l'avez déjà fourni. Lisez la page entière. Si vos tests envoient tous des zéros ou tous, cela expliquerait beaucoup.

— WhatRoughBeast

ACK peut affecter le temps de transmission si vous n'en tenez pas compte. Encore une fois, votre désordre sans étiquette de nombres sommés ne nous dit pas ce que vous additionnez vraiment, et donc ce que vous pourriez manquer.

— Olin Lathrop

Réponses:

Selon la suggestion d'Olin Lathrop, je développerai le bourrage de bits.

CAN utilise le codage NRZ et n'est donc pas satisfait des longues séries de uns ou de zéros (il perd la trace de l'endroit où les fronts d'horloge devraient être). Il résout ce problème potentiel par bourrage de bits. Lors de la transmission, s'il rencontre une série de 5 zéros ou successifs, il insère un peu de l'autre polarité, et lors de la réception, s'il rencontre 5 zéros ou successifs, il ignore le bit suivant (sauf si le bit est le même que le précédent) bits, auquel cas il émet un drapeau d'erreur).

Si vous envoyez tous les zéros ou tous ceux pour vos données de test, une chaîne de 64 bits identiques entraînera l'insertion de 12 bits bourrés. Cela augmentera la longueur totale de trame à 140 bits, avec une meilleure fréquence de trame de 874 trames / s. Si les bits de données sont les mêmes que le MSB du CRC, vous obtiendrez un autre bit bourré là-bas, et la fréquence d'images chute à 868 images / s. Si le CRC a de longues séries de uns ou de zéros, cela réduira encore plus la fréquence d'images. La même considération s'applique à vos identifiants.

Un total de 16 bits farcis produira une fréquence d'images idéale de 850,3 images / s, vous devez donc en tenir compte. Un test rapide serait d'utiliser des données de test avec des bits alternés et de voir ce qui arrive à votre fréquence d'images.

— WhatRoughBeast
source

Oui, dans mon test d'origine, il y a en effet beaucoup de zéros dans la charge utile et l'ID. Après m'être assuré qu'il n'y a pas 5 zéros successifs dans les données ou l'ID, maintenant je peux obtenir 940 images / sec, très près de la limite calculée. Merci beaucoup pour la bonne réponse.

— Penghe Geng

Olin a raison avec sa description du bourrage de bits et comment cela peut affecter négativement le débit CAN théorique. Une autre chose qui peut dégrader davantage le débit réel par rapport à la théorie est la latence. Même si votre contrôleur CAN est capable d'atteindre 100% d'utilisation du bus, le processeur hôte peut ne pas être en mesure de gérer Tx et / ou Rx à ce rythme. Cela pourrait être le résultat d'un processeur lent et / ou d'un micrologiciel inefficace qui implémente la pile CAN.

— Trent Weaver
source

Le plus petit cadre 2.0a (standard) que vous pouvez créer est de 47 bits ... Le plus petit cadre 2.0b (étendu) que vous pouvez créer est de 67 bits ... Cela COMPREND 3 bits d'espacement entre les trames et EXCLUT le bourrage de bits ... En théorie nous pouvons construire un cadre qui ne se remplira jamais; En réalité, le bourrage de bits va se produire beaucoup!

La vitesse de transmission maximale pour CANBus 2.0a / b est de 1Mbit.
À 1 Mo / s, un seul bit (dominant / récessif) a une longueur de 1 uS, c'est-à-dire. 0,000'001 S
Ainsi, une trame 67 bits [la plus petite trame théorique 2,0 b] mettra 67 uS à transmettre - avant qu'une autre trame (67 bits) puisse être transmise.
1'000'000 / 67 donne 14925 images complètes (+ 25 bits de l'image suivante)

Comme vous exécutez à
1/8 de cette vitesse, vous pouvez obtenir au plus 1/8 des paquets 14'925 / 8 = 1'865 images / seconde à 125 Ko

Au moment où vous utilisez les 64 bits (8 octets) de données, et en supposant que vous n'avez pas déclenché des "erreurs" de bourrage de bits en ayant des chaînes de 1 ou 0
consécutifs 1'000'000 / (67 + 64) = 7'633
7 ' 633/8 = 954

Et cela suppose également que votre câblage est parfait. Votre bus peut-il être fabriqué à partir d'un câble UTP de 120 ohms et découplé capacitivement aux deux extrémités? Ou un fil aléatoire avec une résistance de 120 ohms à une extrémité?

Dans l'ensemble, je dirais que vous réussissez assez bien pour obtenir 90% du débit maximal théorique.

— Bateau bleu
source