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

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 :

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?

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.

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.

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.