Какова максимальная скорость кадра (сообщения) шины 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 кадров в секунду.

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

Посмотрите на это с помощью прицела и посмотрите, что вы на самом деле получаете. Возможно, ваше оборудование не готово к передаче нового кадра сразу после его отправки. Кроме того, вы принимаете во внимание время ACK? Ваша непомеченная сумма битов не помогает нам сказать, что именно вы считаете.
На практике трудно получить 100% использование шины в течение длительного времени по шине CAN из-за необходимости времени ACK и интервала между кадрами. Ваш CAN-контроллер может быть не в состоянии поддерживать 100% использование шины в течение длительного периода времени.
В зависимости от того, какие именно данные вы отправляете, вставка битов может увеличить размер кадра до 10%.
@WhatRoughBeast Вы имеете в виду, что межкадровый интервал изменяется в зависимости от содержимого пакета? У вас есть ссылка на некоторые подробности?
@OlinLathrop \@TristanSerifert - Поскольку ACK — это просто битовое поле поля кадра CAN, как оно может повлиять на время передачи?
@xiaobai - Нет, длина поля данных меняется. Что касается ссылки, то вы ее уже дали. Прочитайте всю страницу. Если ваши тесты отправляют все нули или все единицы, это многое объясняет.
ACK может повлиять на время передачи, если вы его не учитываете. Опять же, ваш неразмеченный беспорядок суммированных чисел не говорит нам, что вы на самом деле складываете, и, следовательно, что вы можете упустить.
@Что: Хороший вопрос. Вы должны сделать это ответом, возможно, с некоторыми знаниями о битовой начинке. Кажется, ОП даже не знает, что он существует, и я признаю, что забыл об этом.
@WhatRoughBeast Насколько я понимаю, если отправляется серия из четырех последовательных битов одного и того же значения, добавляется дополнительный бит противоположной полярности, чтобы создать перепад, который контроллеры могут использовать для синхронизации битов. Применяется ли эта битовая набивка только к данным или ко всему кадру? Вы говорите 10%, но если вставка применяется ко всему кадру, то не будет ли увеличение до 20% (поскольку можно вставить до 1 из 5 бит). Хотя я бы ожидал, что в среднем будет намного меньше.
@ user4574 - Для CAN это 5 бит, а не 4. И это применимо ко всем битам. Таким образом, в принципе вы можете увеличить размер пакета почти на 20%. И это тоже не совсем случайно, поскольку вы можете выбрать свои шаблоны идентификаторов, чтобы избежать проблемы, и это может предотвратить заполнение 31-битного раздела.

Ответы (4)

По предложению Олина Латропа я расширю битовую начинку.

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

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

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

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

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

Максимальная скорость передачи для CANBus 2.0a/b составляет 1 Мбит.
При скорости 1 Мбит/с один (доминантный/рецессивный) бит имеет длину 1 мкс, т.е. 0,000'001 S
Таким образом, для передачи 67-битного кадра [наименьший теоретический кадр 2.0b] потребуется 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

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

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

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

Еще один интересный вопрос с точки зрения получателя:

Какова максимальная частота передачи кадров в худшем случае?

В этом случае биты заполнения, вероятно, можно игнорировать, поскольку они снижают частоту.

.

Глядя только на стандартные кадры идентификатора:

Для длины данных 1 вам нужно будет рассчитать с помощью

55 бит (минимальные служебные данные + 8 бит данных + 3 межфамильного пространства)

--> максимальная частота кадров для 1 Мбит составляет около 18181,8/с (1/0,000055)

Для длины данных 0 (может быть также информация) вам придется рассчитывать с

47 бит (минимальные служебные данные + 3 межфамильного пространства)

--> максимальная частота кадров для 1 Мбит составляет около 21276,6/с (1/0,000047)

Какова максимальная скорость кадра (сообщения) шины CAN при 125 кбит/с?
СпросиСетьПолитика конфиденциальности1y, 0v