Moja magistrala CAN działa z prędkością 125 kbit / si używa wyłącznie rozszerzonego formatu ramki. Chciałbym wiedzieć, jaka jest maksymalna szybkość ramki CAN, którą mogę wysłać. Załóżmy, że długość danych wynosi zawsze osiem bajtów.
Według tej strony Wikipedii każda ramka ma maksymalną długość (1+11+1+1+18+1+2+4+64+15+1+1+1+7) = 128bitów:
Biorąc pod uwagę odstęp między ramkami wynoszący co najmniej trzy bity , maksymalna szybkość pakietów poniżej 125 kbit / s powinna wynosić:
125000 / ( 128 + 3) = 954klatki na sekundę.
Ale w moim teście nie mogłem dostać tak wysoko. Maksymalna częstotliwość klatek, jaką mogę osiągnąć (przy wszystkich ośmiu bajtach danych) wynosi około 850 klatek na sekundę.
Co tu jest nie tak - moje obliczenia lub metoda testowa?
źródło
Odpowiedzi:
Zgodnie z sugestią Olin Lathrop zajmę się nadziewaniem bitów.
CAN używa kodowania NRZ i dlatego nie jest zadowolony z długich ciągów zer lub jedynek (traci to, gdzie powinny być krawędzie zegara). Rozwiązuje ten potencjalny problem poprzez upychanie bitów. Podczas transmisji, jeśli napotka ciąg 5 kolejnych zer lub zer, wstawi nieco innej polaryzacji, a podczas odbierania, jeśli napotka 5 kolejnych zer lub zer, zignoruje kolejny bit (chyba że bit jest taki sam jak poprzedni bitów, w którym to przypadku generuje flagę błędu).
Jeśli wysyłasz wszystkie zera lub wszystkie zera dla danych testowych, ciąg 64 identycznych bitów spowoduje wstawienie 12 wypchanych bitów. Zwiększy to całkowitą długość ramki do 140 bitów, przy najlepszej liczbie klatek na sekundę 874 klatek / s. Jeśli bity danych są takie same jak MSB CRC, dostaniesz tam kolejny wypchany bit, a szybkość klatek spadnie do 868 klatek / s. Jeśli CRC ma długi ciąg zer lub jedynek, to jeszcze bardziej zmniejszy częstotliwość klatek. To samo dotyczy twoich identyfikatorów.
Łącznie 16 wypchanych bitów zapewni idealną szybkość klatek wynoszącą 850,3 klatek / s, więc powinieneś to rozważyć. Szybki test polegałby na wykorzystaniu danych testowych z naprzemiennymi bitami i sprawdzeniu, co stanie się z częstotliwością klatek.
źródło
Olin ma rację, przedstawiając opis wypychania bitów i tego, jak może to negatywnie wpłynąć na teoretyczną przepustowość CAN. Inną rzeczą, która może dodatkowo zmniejszyć rzeczywistą przepustowość teoretyczną, jest opóźnienie. Nawet jeśli kontroler CAN jest w stanie osiągnąć 100% wykorzystanie magistrali, procesor hosta może nie być w stanie obsłużyć Tx i / lub Rx z tą szybkością. Może to być wynikiem wolnego procesora i / lub niewydajnego oprogramowania układowego, które implementuje stos CAN.
źródło
Najmniejsza ramka 2.0a (standardowa), którą można zbudować, to 47 bitów ... Najmniejsza ramka 2.0b (rozszerzona), którą można zbudować, to 67 bitów ... Obejmuje 3 bity odstępów między ramkami i wyklucza wypychanie bitów ... Teoretycznie możemy zbudować ramę, która nigdy się nie zapełni; W rzeczywistości upychanie bitów zdarza się całkiem często!
Maksymalna prędkość transmisji dla CANBus 2.0a / b wynosi 1 Mb.
Przy 1 Mb / s pojedynczy bit (dominujący / recesywny) ma długość 1uS, tj. 0,000'001 S
Tak więc 67-bitowa ramka [najmniejsza teoretyczna ramka 2,0b] zajmie 67uS do przesłania - zanim inna (67-bitowa) ramka może zostać przesłana.
1'000'000 / 67 daje 14 925 kompletnych ramek (+ 25 bitów następnej ramki)
Ponieważ
biegasz z 1/8 tej prędkości, możesz uzyskać maksymalnie 1/8 pakietów 14'925 / 8 = 1'865 klatek / sekundę przy 125Kb
Do czasu użycia wszystkich 64-bitowych (8 bajtów) danych i PRZYWRÓCENIE nie wywołałeś „błędów” wypychania bitów, mając ciągi następujących po sobie 1 lub 0
cyfr 1'000'000 / (67 + 64) = 7'633
7 ' 633/8 = 954
I to również przy założeniu, że twoje okablowanie jest idealne. Czy Twoja magistrala Can wykonana jest z kabla 120 Um UTP i jest odłączona pojemnościowo na obu końcach? A może jakiś losowy drut z rezystorem 120 omów na jednym końcu?
Ogólnie rzecz biorąc, powiedziałbym, że masz się całkiem dobrze, aby uzyskać 90% teoretycznej maksymalnej przepustowości.
źródło