Оглавление

1. Кадр данных CAN

1.1. Начало кадра

1.2. Арбитражный раздел.

1.2.1. Стандартный кадр данных.

1.2.2. Расширенный фрейм данных.

1.3. Раздел управления

1.4. Сегмент данных.

1.5, сегмент CRC

1.6, сегмент ACK

1.7. Конец кадра.

2. Стандартный кадр данных CAN и расширенный кадр данных.

2.1. Стандартный кадр данных.

2.2. Расширенный фрейм данных.

2.3. Характеристики стандартных и расширенных кадров данных.

3. Рамка дистанционного управления CAN

3.1. Формат кадра дистанционного управления.

3.2. Разница между кадрами данных и кадрами дистанционного управления.

4. Кадр ошибки CAN

4.1. Формат кадра ошибки.

4.2. Активные флаги ошибок и пассивные флаги ошибок.

4.3. Типы кадров ошибок.

5. Рамка перегрузки CAN

6. Интервал кадров CAN

7. Почему появляется CAN FD?

8. Что такое CAN FD?

9. Сходства и различия между кадрами протокола CAN FD и CAN-шины

10. Анализ структуры кадра CAN FD

10.1. Начало кадра.

10.2. Арбитражный раздел.

10.3. Раздел управления.

10.4. Сегмент данных.

10.5, сегмент CRC

10.6, сегмент ACK

10.7. Конец кадра.

11. Улучшение CAN FD

12. Как перейти с традиционного CAN на CAN FD

Эта статья будетПознакомьтесь с форматом кадра протокола CAN-шины в одной статьеиПознакомьтесь с форматом кадра протокола шины CAN FD в одной статье.две статьииз Интегрировать,Всем друзьям удобно учиться и проверять.

Интересуюсь технологиями автомобильной электроникииз Друзья, пожалуйстаСледите за паблик-аккаунтом: Красивый мужчина, играющий в программирование.,Официальные аккаунты отдают приоритет публикации сообщений в блогах о новейших технологиях.,Творить непросто,Друзья, пожалуйста, поставьте мне лайк、собирать、сосредоточиться наподдержку~

Информация, передаваемая по шине CAN, называется сообщением, и любое подключенное устройство может начать отправлять новые сообщения, когда шина простаивает.

Связь CAN осуществляется посредством следующих 5 типов кадров:

• фрейм данных
• Рамка дистанционного управления
• кадр ошибки
• перегрузка кадра
• интервал кадров

Кроме того, кадры данных и кадры дистанционного управления имеют два формата: стандартный формат и расширенный формат. Стандартный формат имеет 11-битный идентификатор (идентификатор: в дальнейшем именуется идентификатором), а расширенный формат имеет 29-битный идентификатор.

Использование различных фреймов показано в следующей таблице:

Фрейм данных состоит из 7 сегментов, иллюстрация выглядит следующим образом:

• Начало кадра: сегмент, указывающий начало кадра данных;
• Сегмент арбитража: сегмент, указывающий приоритет кадра. В зависимости от длины кода идентификатора арбитражного сегмента он делится на стандартный кадр (CAN 2.0A) и расширенный кадр (CAN 2.0B);
• Сегмент управления: сегмент, который представляет количество байтов данных и зарезервированных битов;
• Сегмент данных: содержимое данных, можно отправить 0–8 байт данных;
• Сегмент CRC: сегмент, который проверяет кадр на наличие ошибок передачи;
• Сегмент ACK: указывает сегмент, подтверждающий нормальный прием;
• Конец кадра: сегмент, указывающий конец кадра данных.

1. Кадр данных CAN

1.1. Начало кадра

Начало кадра состоит из 1 доминантного бита. Когда шина простаивает, отправляющий узел отправляет бит начала кадра, а другие принимающие узлы синхронизируются с битом начала кадра.

На шине есть два типа уровней: доминантные уровни и рецессивные уровни.

Когда на шине выполняется логическое И, логическое значение доминантного уровня равно «0», а рецессивного уровня — «1».

«Доминантный» означает «приоритетный». Пока одно устройство выдает доминирующий уровень, шина будет доминирующим уровнем. Более того, «рецессивный» означает «включающий». Только когда все устройства выдают рецессивные уровни, шина будет рецессивной. (Доминантные уровни сильнее рецессивных уровней.)

1.2. Арбитражный раздел.

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

Секция арбитража различается между кадрами стандартного формата и кадрами расширенного формата. Раздел арбитража кадра стандартного формата состоит из 11-битного идентификатора и бита запроса удаленной передачи RTR, а поле арбитража кадра расширенного формата состоит из 29-битного идентификатора и бита запроса удаленной передачи RTR.

1.2.1. Стандартный кадр данных.

Стандартный кадр данных основан на ранней спецификации CAN (версии 1.0 и 2.0A) и использует 11-битное идентификационное поле.

Информация о кадре стандарта CAN составляет 11 байт, включая дескриптор кадра и данные кадра. Как указано в таблице ниже:

Первые 3 байта представляют собой часть описания кадра. Байт 1 представляет собой информацию о кадре, бит 7 (FF) указывает формат кадра, в стандартном кадре FF=0, бит 6 (RTR) указывает тип кадра, RTR=0 указывает кадр данных, RTR=1 указывает удаленный кадр. DLC представляет фактическую длину данных в кадре данных.

Идентификатор стандартного кадра данных имеет 11 бит. Отправляется последовательно от ID10 к ID0. Запрещено, чтобы все старшие 7 бит были рецессивными (запрещенная настройка: ID=1111111XXXX).

Байты 2–3 представляют собой идентификационный код сообщения, а старшие 11 бит действительны.

Байты 4–11 представляют собой фактические данные кадра данных, которые недопустимы для удаленных кадров.

1.2.2. Расширенный фрейм данных.

Информация о кадре расширенного кадра CAN составляет 13 байтов, включая дескриптор кадра и данные кадра, как показано в следующей таблице:

Первые 5 байтов представляют собой часть описания кадра. Байт 1 представляет собой информацию о кадре, бит 7 (FF) указывает формат кадра, в расширенном кадре FF=1, бит 6 (RTR) указывает тип кадра, RTR=0 указывает кадр данных, RTR=1 указывает удаленный кадр. DLC представляет фактическую длину данных в кадре данных.

Идентификатор расширенного формата имеет 29 бит. Базовые идентификаторы представлены от ID28 до ID18, а расширенные идентификаторы представлены от ID17 до ID0. Базовый идентификатор и идентификатор стандартного формата одинаковы. Запрещено, чтобы все старшие 7 бит были рецессивными (запрещенная настройка: базовый ID=1111111XXXX).

Байты 2–5 представляют собой идентификационный код сообщения, а старшие 28 бит являются действительными.

Байты 6–13 — это фактические данные кадра данных, которые недопустимы для удаленных кадров.

1.3. Раздел управления

Сегмент управления состоит из 6 бит, включая код длины данных и два зарезервированных бита для будущего расширения. Состав стандартного формата и расширенного формата различен.

Код длины данных указывает количество байтов в сегменте данных. Код длины данных составляет 4 бита и отправляется в сегменте управления. Количество байтов, разрешенных для длины кадра данных, составляет 0, 1, 2, 3, 4, 5, 6, 7 и 8. Другие значения: незаконно.

Все зарезервированные биты (r0, r1) должны отправляться с доминирующим уровнем. Однако приемник может получать явные, рецессивные и любые комбинации уровней.

Соответствующая связь между кодом длины данных (DLC) и количеством байтов данных показана в следующей таблице:

Количество байтов данных должно составлять 0–8 байт, но получатель не расценивает случай DLC = 9–15 как ошибку.

1.4. Сегмент данных.

Сегмент данных состоит из отправленных данных в кадре данных. Он может иметь размер от 0 до 8 байт. Каждый байт содержит 8 бит. Сначала отправляется старший бит, за которым следует младший бит.

1.5, сегмент CRC

Сегмент CRC — это кадр, используемый для проверки ошибок передачи кадра, включая: 15-битную ПОСЛЕДОВАТЕЛЬНОСТЬ CRC и 1-битный разделитель CRC.

Последовательность CRC представляет собой значение CRC, сгенерированное на основе полинома. Диапазон расчета CRC включает в себя: начало кадра, сегмент арбитража, сегмент управления и сегмент данных. Приемник использует тот же алгоритм для расчета значения CRC и сравнивает его. Если оно противоречиво, будет сообщено об ошибке.

1.6, сегмент ACK

Сегмент ACK используется для подтверждения того, был ли он получен нормально. Он состоит из двух битов: ACK SLOT и ACK DELIMITER.

Отправляющее устройство отправляет 2 рецессивных бита в сегменте ACK. Когда получатель правильно принимает действительное сообщение, получатель отправит «доминантный» бит отправителю во время паузы ответа (ACK SLOT) (отправка сигнала ACK), чтобы указать ответ, уведомляя отправляющее устройство об окончании нормального приема. это называется «отправить подтверждение» или «вернуть подтверждение».

Отправка ACK/возврат ACK — это устройство, которое получает обычное сообщение среди всех принимающих устройств, которые не находятся ни в состоянии отключения шины, ни в состоянии сна (отправяющее устройство не отправляет ACK). Так называемое нормальное сообщение относится к сообщению, которое не содержит ошибок заполнения, ошибок формата или ошибок CRC.

1.7. Конец кадра.

Конец кадра определяется последовательностью флагов для каждого кадра данных и удаленного кадра. Эта последовательность флагов состоит из 7 «рецессивных» битов.

2. Стандартный кадр данных CAN и расширенный кадр данных.

Протокол CAN может принимать и отправлять 11-битные стандартные кадры данных и 29-битные расширенные кадры данных. Стандартные кадры данных CAN и расширенные кадры данных имеют только разную длину идентификатора кадра, поэтому можно расширить больше узлов CAN.

2.1. Стандартный кадр данных.

Стандартный кадр данных основан на ранней спецификации CAN (версии 1.0 и 2.0A) и использует 11-битное идентификационное поле.

Информация о кадре стандарта CAN составляет 11 байт, включая дескриптор кадра и данные кадра. Как указано в таблице ниже:

Первые 3 байта представляют собой часть описания кадра. Байт 1 представляет собой информацию о кадре, бит 7 (FF) указывает формат кадра, в стандартном кадре FF=0, бит 6 (RTR) указывает тип кадра, RTR=0 указывает кадр данных, RTR=1 указывает удаленный кадр. DLC представляет фактическую длину данных в кадре данных.

Идентификатор стандартного кадра данных имеет 11 бит. При последовательной отправке от ID10 до ID0 могут появиться сообщения 2^11. ​​Диапазон идентификаторов кадра: 000-7FF. Старшие 7 бит не могут быть рецессивными (запрещенная настройка: ID=1111111XXXX).

Байты 2–3 представляют собой идентификационный код сообщения, а старшие 11 бит действительны.

Байты 4–11 представляют собой фактические данные кадра данных, которые недопустимы для удаленных кадров.

2.2. Расширенный фрейм данных.

Информация о кадре расширенного кадра CAN составляет 13 байтов, включая дескриптор кадра и данные кадра, как показано в следующей таблице:

Первые 5 байтов представляют собой часть описания кадра. Байт 1 представляет собой информацию о кадре, бит 7 (FF) указывает формат кадра, в расширенном кадре FF=1, бит 6 (RTR) указывает тип кадра, RTR=0 указывает кадр данных, RTR=1 указывает удаленный кадр. DLC представляет фактическую длину данных в кадре данных.

Идентификатор в расширенном формате состоит из 29 цифр. Базовый идентификатор — от ID28 до ID18, а расширенный идентификатор — от ID17 до ID0. Базовый идентификатор такой же, как идентификатор в стандартном формате 2^29. может появиться, и есть Прерывистые (прозрачные для оператора), диапазон идентификаторов кадров 0000 0000-1FFF FFFF, а старшие 7 бит все рецессивные (запрещенная настройка: базовая ID=1111111XXXX).

Байты 2–5 представляют собой идентификационный код сообщения, а старшие 28 бит являются действительными.

Байты 6–13 — это фактические данные кадра данных, которые недопустимы для удаленных кадров.

2.3. Характеристики стандартных и расширенных кадров данных.

Стандартные кадры данных CAN и расширенные кадры данных имеют разную длину идентификатора кадра, но функционально одинаковы. У них есть общая характеристика: чем меньше значение идентификатора кадра, тем выше приоритет.

3. Рамка дистанционного управления CAN

3.1. Формат кадра дистанционного управления.

Кадр дистанционного управления — это кадр, используемый принимающим устройством для запроса передающего устройства на отправку данных. Кадр дистанционного управления состоит из 6 сегментов, и кадр дистанционного управления не имеет сегмента данных.

Состав кадра дистанционного управления следующий:

• Начало кадра (SOF): сегмент, указывающий начало кадра;
• Сегмент арбитража: сегмент, указывающий приоритет кадра. Могут быть запрошены кадры данных с тем же идентификатором;
• Сегмент управления: сегмент, который представляет количество байтов данных и зарезервированных битов;
• Сегмент CRC: сегмент, который проверяет кадр на наличие ошибок передачи;
• Сегмент ACK: указывает сегмент, подтверждающий нормальный прием;
• Конец кадра: сегмент, указывающий конец кадра дистанционного управления.

Формат кадра дистанционного управления показан ниже:

3.2. Разница между кадрами данных и кадрами дистанционного управления.

Есть два основных различия между кадрами данных и кадрами дистанционного управления:

• Кадр удаленного управления не имеет сегмента данных кадра данных;
• Бит RTR кадра дистанционного управления является рецессивным, а полярность бита RTR указывает, является ли отправляемый кадр кадром данных (бит RTR «доминирующий») или кадром удаленного управления (бит RTR «рецессивный»). Следовательно, кадры данных без сегментов данных и кадры удаленного управления можно отличить по биту RTR.

4. Кадр ошибки CAN

4.1. Формат кадра ошибки.

Кадр ошибки состоит из флага ошибки (Error Flag) и разделителя ошибки (Error Delimiter).

Когда принимающий узел обнаруживает ошибку в сообщении на шине, он автоматически отправляет активный флаг ошибки, который представляет собой 6 последовательных доминантных битов. Другие узлы отправляют флаги распознавания ошибок после обнаружения активных флагов ошибок, которые состоят из 6 последовательных рецессивных битов. Поскольку время, когда каждый приемный узел обнаруживает ошибку, может быть разным, фактический флаг ошибки на шине может состоять из 6–12 доминантных битов.

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

Как показано ниже:

4.2. Активные флаги ошибок и пассивные флаги ошибок.

Флаги ошибок включают активные флаги ошибок и пассивные флаги ошибок.

• Флаг активной ошибки: Флаг ошибки выводится, когда устройство в состоянии активной ошибки обнаруживает ошибку, 6 доминантных битов;
• Флаг пассивной ошибки: Флаг ошибки выводится, когда устройство в состоянии пассивной ошибки обнаруживает ошибку, 6 рецессивных битов.

4.3. Типы кадров ошибок.

Общее количество кадров ошибок 5 виды, одновременно может произойти несколько ошибок, виды Как показано ниже:

• битовая ошибка
• ошибка заполнения
• Ошибка CRC
• Ошибка формата
• Ошибка подтверждения

Тип ошибки, содержание ошибки, рамка обнаружения ошибки и блок обнаружения указаны в следующей таблице:

Давайте сосредоточимся на битовых ошибках и ошибках формата.

битовая ошибкахарактеристика Как показано ниже:

• битовая ошибка Зависит от кадра вывода на шину данных、рамка дистанционного управления、кадр ошибки、перегрузка блок кадраиз и вывод ACK Блоки и блоки, в которых обнаружены ошибки вывода;
• Выходной рецессивный уровень в разделе арбитража,Но когда обнаруживается доминирующий уровень,будет считаться неудачей в арбитраже,вместо битовой ошибки;
• Когда секция арбитража выводит рецессивный уровень в качестве бита заполнения,Но когда обнаруживается доминирующий уровень,Не будет считаться битовой ошибкой.,Скорееошибка заполнения；
• Отправитель находится в ACK сегмент выдает рецессивный уровень, но при обнаружении доминантного уровня он будет расценен как уровень других единиц. ACK Ответить, не битовая ошибка；
• Выходной пассивный флаг ошибки (6 бит единицы (рецессивный бит)) но при обнаружении доминирующего уровня будет следовать конечное условие флага ошибки, ожидая обнаружения последовательных идентичных 6 значение цифры (явное или неявное), не считающееся битовой ошибка。

Ошибка форматахарактеристика Как показано ниже:

• Даже если принимающее устройство обнаружит EOF（7 рецессивная цифра единицы) последняя цифра (th 8 цифра единиц) является доминирующим уровнем и не рассматривается как ошибка. формата；
• Даже если принимающее устройство Применение Код длины данных (DLC) 9∼15 Когда значение равно из, оно не рассматривается как ошибка. формата。

После того как отправляющее устройство отправит кадр ошибки, оно снова отправит кадр данных или кадр дистанционного управления. Время вывода флага ошибки показано в следующей таблице:

5. Рамка перегрузки CAN

Кадр перегрузки — это кадр, используемый принимающим устройством для уведомления о том, что он не завершил подготовку к приему. Кадр перегрузки состоит из флага перегрузки и разделителя перегрузки.

• Флаг перегрузки состоит из 6 доминантных битов. Состав флага перегрузки такой же, как и у активного флага ошибки. Форма флага перегрузки разрушает фиксированный формат прерывистого поля. В результате все остальные узлы также обнаруживают состояние ошибки, и каждый из них отправляет флаг перегрузки.

• Разделитель перегрузки состоит из 8 рецессивных битов, а состав разделителя перегрузки такой же, как и разделителя ошибок. После отправки флага перегрузки каждый узел контролирует шину до тех пор, пока не будет обнаружен рецессивный бит. В это время каждый узел завершил отправку своего собственного флага перегрузки, а затем все узлы начнут отправлять 7 рецессивных бит одновременно, чтобы завершить 8-битный разделитель перегрузки.

Состав кадра перегрузки показан на рисунке ниже:

6. Интервал кадров CAN

Интервал кадра — это кадр, используемый для разделения кадров данных и кадров удаленного управления. Кадры данных и кадры дистанционного управления могут отделять этот кадр от любого предыдущего кадра (кадра данных, кадра дистанционного управления, кадра ошибки, кадра перегрузки) путем вставки интервала кадра. Интервал кадра не может быть вставлен перед кадрами перегрузки и кадрами ошибки.

Состав интервала кадра показан на рисунке ниже:

интервал кадров Зависит от Он состоит из сегмента интервала, сегмента ожидания шины и сегмента задержки передачи, подробное описание Как показано ниже:

• Интервальный сегмент: Интервал состоит из 3 рецессивных битов. В течение периода паузы ни одному узлу не разрешается отправлять кадры данных или удаленные кадры. Единственное действие, которое можно выполнить, — это сообщить о состоянии перегрузки;
• Сегмент простоя шины: продолжительность простоя шины не ограничена. Как только будет подтверждено, что шина простаивает, любой узел может получить доступ к шине для передачи информации. Кадры, задерживающиеся из-за передачи другого кадра, отправляются, начиная с первого бита после паузы. При обнаружении шины доминирующий бит, который появляется в период простоя шины, будет считаться началом кадра;
• Сегмент отложенной передачи: после того, как узел в состоянии распознавания ошибок завершает действие по отправке, он должен отправить 8 рецессивных битов после паузы, прежде чем ему будет разрешено отправить следующий кадр. Если во время паузы выполняется действие отправки (вызванное другим узлом), этот узел станет получателем отправляемого кадра.

7. Почему появляется CAN FD?

Поскольку шинная технология становится все более широко и глубоко используемой в области автомобильной электроники, особенно в связи с быстрым развитием технологий автономного вождения, автомобильная электроника предъявляет все более высокие требования к ширине шины и скорости передачи данных по традиционному CAN (1 Мбит/с, полезная нагрузка 8 байт). ) не смог удовлетворить растущий спрос.

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

30 июня 2015 года Международная организация по стандартизации (ISO) официально признала CAN FD и без каких-либо возражений приняла ISO 11898-1 в качестве проекта международного стандарта.

8. Что такое CAN FD?

Протокол CAN FD был предварительно исследован и разработан компанией Bosch и отраслевыми экспертами и выпущен в 2012 году. Он был улучшен посредством стандартизации и теперь включен в ISO 11898-1:2015. Первоначальная версия Bosch CAN FD (не ISO CAN FD) несовместима с ISO CAN FD.

CAN FD имеет следующие 4 основных преимущества:

1. Увеличенная длина данных

CAN FD поддерживает до 64 байтов данных на кадр данных, тогда как традиционный CAN поддерживает до 8 байтов данных. Это снижает накладные расходы протокола и повышает эффективность протокола.

2. Увеличьте скорость передачи.

CAN FD поддерживает двойную скорость передачи данных: как и в традиционной CAN, номинальная (арбитражная) скорость передачи данных ограничена 1 Мбит/с, тогда как скорость передачи данных зависит от топологии сети/приемопередатчика. Фактически может быть достигнута скорость передачи данных до 5 Мбит/с.

3. Повышенная надежность

CAN FD использует улучшенную проверку циклическим избыточным кодом (CRC) и «защищенный счетчик битов», что снижает риск необнаруженных ошибок. Это имеет решающее значение в критически важных для безопасности приложениях, таких как автомобильная и промышленная автоматизация.

4. Плавный переход

В некоторых конкретных случаях CAN FD можно использовать в ЭБУ, использующих только традиционный CAN, чтобы можно было постепенно внедрять узлы CAN FD, тем самым упрощая процедуры и снижая затраты для OEM-производителей.

Фактически, CAN FD может увеличить пропускную способность сети в 3–8 раз по сравнению с традиционным CAN, обеспечивая простое решение проблемы роста объема данных.

9. Сходства и различия между кадрами протокола CAN FD и CAN-шины

CAN Формат кадра протокола шины FDиCAN Как показано ниже:

CAN Различия в кадрах протокола шины FDиCANКак показано ниже:

1. Разные скорости передачи

Скорость CAN FD является переменной: от бита BRS в поле управления до поля ACK (включая разделитель CRC), скорость является переменной, максимальная скорость может достигать 8 Мбит/с, а другие части такие же, как у CAN.

2. Разная длина данных

Максимальная длина данных, поддерживаемая CAN FD, составляет 64 байта, а максимальная длина данных, поддерживаемая CAN, — 8 байт.

3. Различные форматы кадров

CAN FD добавляет биты FDF, BRS и ESI:

• Бит FDF (формат гибкой скорости передачи данных): зарезервированный бит r в исходном кадре данных CAN. Указывает, используется ли сообщение CAN или сообщение CAN-FD. Бит FDF всегда рецессивный (1), что указывает на сообщение CAN FD;
• Бит BRS (переключатель скорости передачи данных): указывает на преобразование скорости передачи данных. Когда BRS является доминантным битом (0), скорость передачи данных сегмента соответствует скорости передачи данных арбитражного сегмента (постоянная скорость), когда BRS является рецессивным. бит (1) Переменная скорость (т. е. BSR в CRC использует передачу со скоростью преобразования);
• Бит ESI (индикатор состояния ошибки): отправляет индикацию состояния ошибки узла. Доминантный бит (0) отправляется при возникновении активной ошибки, а рецессивный бит (1) отправляется при возникновении пассивной ошибки.

4. Длина идентификаторов разная.

Длина стандартного идентификатора кадра CAN FD может быть увеличена до 12 бит, а стандартный идентификатор кадра CAN составляет 11 бит.

10. Анализ структуры кадра CAN FD

Узлы CAN FD могут нормально получать и отправлять сообщения CAN, но узлы CAN не могут правильно получать и отправлять сообщения CAN FD, поскольку форматы их кадров несовместимы.

Как и CAN, CAN FD состоит из 7 частей: начало кадра, секция арбитража, секция управления, секция данных, секция CRC, секция ACK и конец кадра.

10.1. Начало кадра.

CAN и CANFD используют один и тот же флаг SOF для обозначения начала сообщения. Начало кадра состоит из доминантного бита, обозначающего начало сообщения и играющего синхронизирующую роль на шине.

10.2. Арбитражный раздел.

Отличие от CAN,CAN FD удаляет поддержку удаленных кадров,Заменен бит RTR на бит RRS.,Зачастую оно является доминирующим. IDE используется для различения стандартных и расширенных фреймов.

10.3. Раздел управления.

CAN FD имеет те же биты IDE, res и DLC, что и CAN, но добавляет еще три бита: FDF, BRS и ESI.

• Бит FDF (формат гибкой скорости передачи данных): зарезервированный бит r в исходном кадре данных CAN. Указывает, используется ли сообщение CAN или сообщение CAN-FD. Бит FDF всегда рецессивный (1), что указывает на сообщение CAN FD;
• Бит BRS (переключатель скорости передачи данных): указывает на преобразование скорости передачи данных. Когда BRS является доминантным битом (0), скорость передачи данных сегмента соответствует скорости передачи данных арбитражного сегмента (постоянная скорость), когда BRS является рецессивным. бит (1) Переменная скорость (т. е. BSR в CRC использует передачу со скоростью преобразования);
• Бит ESI (индикатор состояния ошибки): отправляет индикацию состояния ошибки узла. Доминантный бит (0) отправляется при возникновении активной ошибки, а рецессивный бит (1) отправляется при возникновении пассивной ошибки.

10.4. Сегмент данных.

CAN FD совместим с форматом данных CAN, а также может поддерживать до: 12, 16, 20, 24, 32, 48 и 64 байта.

Как и в традиционном CAN, DLC CAN FD имеет длину 4 бита и представляет количество байтов данных в кадре. Для поддержки 4-битного DLC CAN FD использует оставшиеся 7 значений от 9 до 15 для представления количества используемых байтов данных (12, 16, 20, 24, 32, 48, 64). 

10.5, сегмент CRC

Циклический избыточный код (CRC) в традиционном CAN составляет 15 бит, а в CAN FD — 17 бит (до 16 байт данных) или 21 бит (20–64 байта данных). В традиционном CAN в CRC могут быть включены от 0 до 3 битов заполнения, тогда как в CAN FD всегда имеется четыре фиксированных бита заполнения для повышения надежности связи.

10.6, сегмент ACK

За подтверждением следует флаг завершения CRC. Разница в том, что CAN FD поддерживает идентификацию 2-битного ACK.

10.7. Конец кадра.

Как и CAN, кадр CAN FD заканчивается 7 последовательными рецессивными битами.

11. Улучшение CAN FD

CAN FD использует два метода повышения эффективности связи: один метод заключается в сокращении времени передачи данных и увеличении скорости передачи данных; другой метод заключается в увеличении длины поля данных, уменьшении количества сообщений и уменьшении скорости загрузки шины.

CAN FD использует три полинома в разделе проверки CRC, чтобы обеспечить надежность данных при высокоскоростной связи.

1. Сократите время передачи данных и увеличьте скорость передачи данных.

CAN FD поддерживает двойную скорость передачи данных, и, как и в традиционной CAN, номинальная (арбитражная) скорость передачи данных ограничена 1 Мбит/с, тогда как скорость передачи данных зависит от топологии сети/приемопередатчика. Фактически может быть достигнута скорость передачи данных до 5 Мбит/с.

из раздела управления BRS на месте ACK перед абзацем (включая CRC разделитель) для переменной скорости,Остальное оригинал CAN Скорость, которую использует автобус. Каждая из двух скоростей имеет набор регистров определения времени бита. Помимо использования различных единиц времени бита, TQ Кроме того, коэффициент выделения каждого сегмента битового времени также может быть разным.

2. Увеличьте длину сегмента данных, чтобы уменьшить количество сообщений и снизить скорость загрузки шины.

CAN FD поддерживает до 64 байтов данных на кадр данных, тогда как традиционный CAN поддерживает до 8 байтов данных, что снижает накладные расходы протокола и повышает эффективность протокола.

DLC поддерживает максимум 64 байта. Когда DLC меньше или равно 8, это то же самое, что и исходная шина CAN. Когда оно больше 8, максимальная длина поля данных может достигать. 64 байта. Как показано ниже, это нелинейная соответствующая зависимость между значением DLC и номером байта.

3. Раздел проверки CRC

CAN FD использует улучшенную проверку циклическим избыточным кодом (CRC) и «защищенный счетчик битов заполнения». Из-за различной длины DLC CAN FD выбирает два новых полинома CRC типа BCH, когда DLC больше 8 байтов, тем самым уменьшая. риск необнаруженных ошибок.

12. Как перейти с традиционного CAN на CAN FD

Хотя CANFD унаследовал большинство характеристик традиционного CAN, нам еще предстоит проделать большую работу по переходу с традиционного CAN на CANFD.

1. Что касается аппаратного обеспечения и инструментов, для использования CANFD необходимо сначала выбрать контроллер CAN и приемопередатчик, поддерживающие CANFD, а также выбрать новые инструменты отладки и мониторинга сети.

2. С точки зрения совместимости сети особое внимание следует уделить ситуации, когда некоторые узлы в традиционном сегменте сети CAN необходимо обновить до CANFD. Из-за несовместимых форматов кадров узлы CANFD обычно могут отправлять и получать сообщения традиционных узлов CAN. но традиционные узлы CAN не могут нормально отправлять и получать сообщения от узлов CANFD.

Протокол CAN FD является последним обновлением протокола CAN-BUS. Он увеличивает размер 8-байтовых данных на кадр CAN до 64 байтов и увеличивает скорость передачи данных с максимального 1 Мбит/с до 8-15 Мбит/с, что значительно повышает эффективность связи. Повышение эффективности связи автомобиля более чем в 8 раз. Эта технология была монополизирована европейскими и американскими компаниями до 2016 года. Guangzhou Zhiyuan Electronics Co., Ltd., лидер китайской CAN-BUS, разработала первую в Китае интерфейсную карту CAN FD на основе основного кода CAN FD IP с полными правами интеллектуальной собственности. . Синхронизировать уровень автобусных технологий Китая с самым высоким мировым уровнем.

Подробное объяснение шины CAN: Что такое шина CAN?

Подробное объяснение шины CAN: характеристики высокоскоростной шины CAN и низкоскоростной шины CAN.

Подробное объяснение шины CAN: многоуровневая структура и функции протокола CAN.

Подробное объяснение CAN-шины: Схема аппаратного состава узла CAN

Подробное объяснение шины CAN: как использовать часто используемые разъемы CAN.

Подробное объяснение шины CAN: Формат сообщения шины CAN — кадр данных.

Подробное объяснение CAN-шины: стандартный кадр данных и расширенный кадр данных​​​​​

Подробное объяснение шины CAN: Формат сообщения шины CAN — кадр дистанционного управления.

Подробное объяснение шины CAN: Формат сообщения шины CAN — кадр ошибки.

Подробное объяснение шины CAN: Формат сообщения шины CAN — кадр перегрузки.

Подробное объяснение шины CAN: Формат сообщения шины CAN — интервал кадров.