Qual è la velocità massima del frame (messaggio) del bus CAN a 125 kbit / s?


18

Il mio bus CAN funziona a 125 kbit / se utilizza esclusivamente il formato frame esteso. Vorrei sapere qual è la velocità massima di frame CAN che posso inviare. Supponiamo che la lunghezza dei dati sia sempre di otto byte.

Secondo questa pagina di Wikipedia , ogni frame ha una lunghezza massima di (1+11+1+1+18+1+2+4+64+15+1+1+1+7) = 128bit di frame :

Inserisci qui la descrizione dell'immagine

Tenendo conto di una spaziatura tra frame minimo di tre bit , la velocità massima dei pacchetti inferiore a 125 kbit / s dovrebbe essere: 125000 / ( 128 + 3) = 954frame al secondo.

Ma nel mio test, non sono riuscito ad arrivare così in alto. Il frame rate massimo che posso ottenere (con tutti i dati di otto byte) è di circa 850 frame al secondo.

Cosa c'è che non va qui: il mio calcolo o il mio metodo di prova?


Guardalo con uno scopo e vedi cosa stai effettivamente ottenendo. Forse il tuo hardware non è pronto per trasmettere un nuovo frame dopo averlo immediatamente inviato. Inoltre, stai prendendo in considerazione il tempo ACK? La tua somma senza etichetta di bit non è utile per dirci che cosa stai contando esattamente.
Olin Lathrop,

In pratica, è difficile ottenere il 100% di utilizzo del bus per un periodo di tempo prolungato su un bus CAN, a causa della necessità di tempi ACK e spaziatura tra i frame. Il controller CAN potrebbe non essere in grado di supportare l'utilizzo del bus al 100% per un periodo di tempo prolungato.
Tristan Seifert,

2
A seconda esattamente di quali dati stai inviando, il bit stuffing può aumentare le dimensioni del frame fino al 10%.
WhatRoughBeast,

1
@xiaobai - No, la lunghezza del campo dati cambia. Per quanto riguarda un link, l'hai già fornito. Leggi l'intera pagina. Se i tuoi test inviano tutti gli zero o tutti, ciò spiegherebbe molto.
WhatRoughBeast

1
ACK può influire sul tempo di trasmissione se non lo si tiene conto. Ancora una volta, il tuo disordine senza etichetta di numeri sommati non ci dice cosa stai davvero sommando, e quindi cosa potresti perdere.
Olin Lathrop,

Risposte:


18

Per il suggerimento di Olin Lathrop, mi occuperò del ripieno.

CAN utilizza la codifica NRZ e non è quindi soddisfatto di lunghe tirature di uno o zero (perde traccia di dove dovrebbero essere i bordi dell'orologio). Risolve questo potenziale problema con il bit-stuffing. Durante la trasmissione, se incontra una sequenza di 5 o zeri successivi inserisce un po 'dell'altra polarità, e quando riceve, se incontra 5 o successivi zero, ignora il bit successivo (a meno che il bit sia uguale al precedente bit, nel qual caso viene emesso un flag di errore).

Se si inviano tutti gli zero o tutti quelli per i dati di test, una stringa di 64 bit identici comporterà l'inserimento di 12 bit imbottiti. Ciò aumenterà la lunghezza totale dei fotogrammi a 140 bit, con una frequenza dei fotogrammi migliore di 874 fotogrammi / sec. Se i bit di dati sono gli stessi dell'MSB del CRC, otterrai un altro bit imbottito e la frequenza dei fotogrammi scenderà a 868 frame / sec. Se il CRC ha lunghe tirature di uno o zero, ciò ridurrà ulteriormente il frame rate. La stessa considerazione vale per i tuoi identificatori.

Un totale di 16 bit farciti produrrà un frame rate ideale di 850.3 frame / sec, quindi dovresti considerarlo. Un test rapido sarebbe quello di utilizzare i dati di test con bit alternati e vedere cosa succede al frame rate.


3
Sì, nel mio test originale ci sono davvero molti zeri nel payload e nell'ID. Dopo essermi accertato che non ci siano 5 zero successivi nei dati o nell'ID, ora posso ottenere 940 frame / sec, molto vicino al limite calcolato. Grazie mille per l'ottima risposta.
Penghe Geng,

1

Olin ha ragione con la sua descrizione del bit stuffing e di come ciò possa influenzare negativamente il throughput CAN teorico. Un'altra cosa che può ulteriormente degradare il throughput effettivo da quello teorico è la latenza. Anche se il controller CAN è in grado di ottenere il 100% di utilizzo del bus, il processore host potrebbe non essere in grado di gestire Tx e / o Rx a tale velocità. Questo potrebbe essere il risultato di un processore lento e / o firmware inefficiente che implementa lo stack CAN.


1

Il frame 2.0a (standard) più piccolo che puoi costruire è di 47 bit ... Il frame 2.0b (esteso) più piccolo che puoi costruire è di 67 bit ... Ciò include 3 bit di spaziatura tra i frame ed ESCLUDE il bit stuffing ... In teoria possiamo costruire un telaio che non riempirà mai; In realtà, un po 'di ripieno sta per succedere parecchio!

Il baud massimo per CANBus 2.0a / b è 1Mbit.
A 1 Mb / S, un singolo bit (dominante / recessivo) è lungo 1 uS, ovvero. 0.000'001 S
Quindi un frame a 67 bit [il più piccolo frame teorico 2.0b] richiederà 67 uS per trasmettere - prima che possa essere trasmesso un altro frame (67 bit).
1'000'000 / 67 fornisce 14.925 frame completi (+ 25 bit del frame successivo)

Mentre
corri a 1/8 di quella velocità, puoi ottenere al massimo 1/8 dei pacchetti 14'925 / 8 = 1'865 frame / Second @ 125Kb

Quando usi tutti i 64 bit (8byte) di dati e ASSUMING non hai attivato "errori" di riempimento bit avendo stringhe di
1'000'000 / (0 + +) di 1 o 0 consecutivi = 7'633
7 ' 633/8 = 954

E questo presuppone anche che il cablaggio sia perfetto. Il bus può essere realizzato con un cavo UTP da 120ohm e disaccoppiato in modo capacitivo su entrambe le estremità? O qualche filo casuale con una resistenza da 120ohm su un'estremità?

Nel complesso, direi che stai andando abbastanza bene per ottenere il 90% della produttività massima teorica.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.