Моя шина 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 Мбит / с один (доминирующий / рецессивный) бит имеет длину 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% от теоретической максимальной пропускной способности.
источник