Какова максимальная скорость передачи кадров (сообщений) по шине CAN при 125 кбит / с?

18

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

Согласно этой странице Википедии , каждый кадр имеет максимальную длину кадра в (1+11+1+1+18+1+2+4+64+15+1+1+1+7) = 128битах:

Введите описание изображения здесь

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

Но в моем тесте я не мог получить это высоко. Максимальная частота кадров, которую я могу достичь (со всеми данными из восьми байтов), составляет около 850 кадров в секунду.

Что здесь не так - мой расчет или мой метод испытаний?

Пенге Гэн
источник
Посмотрите на это с точки зрения и посмотрите, что вы на самом деле получаете. Возможно, ваше оборудование не готово к передаче нового кадра сразу после его отправки. Кроме того, вы принимаете во внимание время ACK? Ваша немеченая сумма битов не помогает нам сказать, что именно вы рассчитываете.
Олин Латроп
На практике трудно получить 100% -ное использование шины в течение любого продолжительного времени по шине CAN из-за необходимости времени ACK и межкадрового интервала. Ваш CAN-контроллер может не поддерживать 100% использование шины в течение длительного времени.
Тристан Сейфер
2
В зависимости от того, какие именно данные вы отправляете, битовая вставка может увеличить размер вашего кадра до 10%.
WhatRoughBeast
1
@xiaobai - Нет, длина поля данных изменяется. Что касается ссылки, то вы ее уже предоставили. Прочитайте всю страницу. Если ваши тесты отправляют все нули или все нули, это многое объясняет.
WhatRoughBeast
1
ACK может повлиять на время передачи, если вы не учитываете его. Опять же, ваш непомеченный беспорядок суммированных чисел не говорит нам, что вы на самом деле складываете, и, следовательно, что вы можете упустить.
Олин Латроп

Ответы:

18

Согласно предложению Олина Латропа, я остановлюсь на чепухах.

CAN использует NRZ-кодирование и поэтому недоволен долгим запуском единиц или нулей (он теряет направление на то, какими должны быть тактовые частоты). Это решает эту потенциальную проблему путаницей. При передаче, если он встречает серию из 5 последовательных единиц или нулей, он вставляет бит другой полярности, а при получении, если он встречает 5 последовательных единиц или нули, он игнорирует последующий бит (если только бит не совпадает с предыдущим биты, в этом случае он выдает флаг ошибки).

Если вы отправляете все нули или все единицы для ваших тестовых данных, строка из 64 идентичных битов приведет к вставке 12 заполненных битов. Это увеличит общую длину кадра до 140 битов, с наилучшей частотой кадров 874 кадра / сек. Если биты данных совпадают с MSB CRC, вы получите еще один бит, и частота кадров упадет до 868 кадров / сек. Если CRC имеет длительные последовательности единиц или нулей, это приведет к еще большему снижению частоты кадров. То же самое относится и к вашим идентификаторам.

В общей сложности 16 заполненных битов обеспечат идеальную частоту кадров 850,3 кадра / с, поэтому вы должны учитывать это. Быстрый тест будет состоять в том, чтобы использовать тестовые данные с чередующимися битами и посмотреть, что происходит с вашей частотой кадров.

WhatRoughBeast
источник
3
Да, в моем первоначальном тесте действительно много нулей в полезной нагрузке и идентификаторе. После того, как я убедился, что в данных или идентификаторе нет 5 последовательных нулей, теперь я могу получить 940 кадров / сек, очень близко к расчетному пределу. Большое спасибо за отличный ответ.
Пенге Гэн
1

Олин прав в своем описании битовой начинки и того, как это может отрицательно повлиять на теоретическую пропускную способность CAN. Еще одна вещь, которая может еще больше ухудшить фактическую пропускную способность по сравнению с теоретической, - это задержка. Даже если ваш CAN-контроллер способен достичь 100% использования шины, хост-процессор может не справиться с Tx и / или Rx с такой скоростью. Это может быть результатом медленного процессора и / или неэффективной прошивки, которая реализует стек CAN.

Трент Уивер
источник
1

Самый маленький 2.0a (стандартный) фрейм, который вы можете построить, составляет 47 битов ... Самый маленький 2.0b (расширенный) фрейм, который вы можете построить, составляет 67 битов ... Это включает 3 бита между кадрами и исключает вставку битов ... В теории мы можем построить каркас, который никогда не будет наполнен; На самом деле, битовая начинка будет происходить довольно часто!

Максимальный бод для CANBus 2.0a / b составляет 1 Мбит.
При скорости 1 Мбит / с один (доминирующий / рецессивный) бит имеет длину 1 мкс, т.е. 0,000'001 S
Таким образом, 67-битный кадр [самый маленький теоретический 2,0-битный кадр] будет передавать 67 мксек, прежде чем может быть передан другой (67-битный) кадр.
1'000'000 / 67 дает 14 925 полных кадров (+ 25 бит следующего кадра)

Поскольку вы работаете на 1/8 от этой скорости, вы можете получить не более 1/8 от количества пакетов
14 925/8 = 1 865 кадров / сек @ 125 КБ

К тому времени, когда вы используете все 64-битные (8-байтовые) данные, и ПРИНИМАЯ, что вы не вызвали "ошибки"
вставки битов, имея строки из последовательных 1 или 0 1'000'000 / (67 + 64) = 7'633
7 ' 633/8 = 954

И это также предполагает, что ваша проводка идеальна. Ваша шина может изготовлена ​​из 120-омного UTP-кабеля и емкостно развязана на обоих концах? Или какой-нибудь случайный провод с резистором 120 Ом на одном конце?

В целом, я бы сказал, что у вас неплохо получается получить 90% от теоретической максимальной пропускной способности.

Голубых фишек
источник