Яка максимальна швидкість кадру шини (повідомлення) CAN при 125 кбіт / с?

Моя шина CAN працює зі швидкістю 125 кбіт / с і використовує виключно розширений формат кадру. Я хотів би знати, яка максимальна швидкість кадру CAN я можу надсилати. Припустимо, довжина даних завжди становить вісім байт.

Відповідно до цієї сторінки Вікіпедії , кожен кадр має максимальну довжину кадру (1+11+1+1+18+1+2+4+64+15+1+1+1+7) = 128:

Беручи до уваги мінімум три біт міжфреймового інтервалу , максимальна швидкість пакету при 125 кбіт / с повинна становити: 125000 / ( 128 + 3) = 954кадри в секунду.

Але в моєму тесті я не міг досягти такого високого рівня. Максимальна швидкість кадру, яку я можу досягти (з усіма даними восьми байтів), становить близько 850 кадрів в секунду.

Що тут не так - мій розрахунок чи метод мого тестування?

За пропозицією Оліна Летропа, я розгорнуся щодо набивання бітів.

CAN використовує кодування NRZ, і для цього не задоволений довгими пробілами одиниць або нулів (він втрачає місце, де повинні бути краї годин). Він вирішує цю потенційну проблему шляхом набивання бітів. При передачі, якщо він стикається з запуском 5 послідовних або нулів, він вставляє трохи іншої полярності, а при отриманні, якщо він стикається з 5 послідовними або нулями, він ігнорує наступний біт (якщо біт не такий, як попередній біти; у цьому випадку він видає прапор помилки).

Якщо ви надсилаєте всі нулі або всі для своїх тестових даних, рядок з 64 однакових бітів призведе до вставки 12 набивних біт. Це збільшить загальну довжину кадру до 140 біт, найкраща частота кадрів - 874 кадрів / сек. Якщо біти даних такі ж, як і MSB CRC, ви отримаєте ще один набитий біт, і частота кадрів падає до 868 кадрів / сек. Якщо CRC має тривалі прогони одиниць або нулів, це ще більше знизить частоту кадрів. Те ж саме стосується і ваших ідентифікаторів.

Всього 16 набивних біт дасть ідеальну частоту кадрів у 850,3 кадрів / с, тож вам слід це врахувати. Швидким тестом було б використання даних тесту з змінними бітами, і подивитися, що відбувається з вашою частотою кадрів.

Олін вірно описує начинки бітів і як це може негативно вплинути на теоретичну пропускну здатність CAN. Ще одна річ, яка може ще більше погіршити фактичну пропускну здатність від теоретичної, - це затримка. Навіть якщо ваш контролер CAN може досягти 100% використання шини, хост-процесор може не мати можливості обробляти Tx та / або Rx з цією швидкістю. Це може бути результатом повільного процесора та / або неефективної прошивки, яка реалізує стек CAN.

Найменший кадр 2.0a (стандартний), який ви можете скласти, становить 47 біт ... Найменший 2.0b (розширений) кадр, який ви можете створити, становить 67 біт ... Це включає 3 біт міжкадрового інтервалу і виключає набивання бітів ... Теоретично ми можемо побудувати кадр, який ніколи не заповниться; Насправді, набивання бітів відбудеться досить багато!

Максимальна бод для CANBus 2.0a / b - 1 Мбіт.
При 1 Мбіт / S один біт (домінантний / рецесивний) довжиною становить 1uS, тобто. 0.000'001 S
Отже, 67-бітний кадр [найменший теоретичний кадр 2.0b] потребуватиме 67uS для передачі - перш ніж може бути переданий інший (67bit) кадр.
1'000'000 / 67 дає 14 925 повних кадрів (+ 25 біт наступного кадру)

Коли ви працюєте на 1/8 такої швидкості, ви можете отримати максимум 1/8 з пакетів
14'925 / 8 = 1'865 кадрів / секунду @ 125Kb

На той час, коли ви використовуєте всі 64 біти (8 байт) даних і ВИМОГА, ви не запускали бітові "помилки",
заповнюючи рядки послідовних 1-х або 0-х 1'000'000 / (67 + 64) = 7'633
7 ' 633/8 = 954

І це також, якщо припустити, що проводка ідеальна. Чи є ваша автобусна шина виготовлена ​​з UTP-кабелю 120ohm та ємнісно відокремлена на обох кінцях? Або якийсь випадковий провід з резистором 120 Ом на одному кінці?

В цілому, я б сказав, що ви робите досить добре, щоб отримати 90% теоретичної максимальної пропускної здатності.