Can fd что это

Вопрос про CAN FD

Читаю с интересом ваши статьи и хотел бы задать вопрос, как компетентным людям в автомобильной отрасли — периодически сталкиваюсь с шиной CAN и в процессе изучения встречал информацию о перспективах перехода на CAN FD. Википедия говорит о переходе на FD большинства производителей авто к 2020 году, однако реальных статей о применении в наши дни я не нашёл, как на ваш взгляд выглядит практика применения CAN FD на рынке сейчас?

Заранее благодарю, Алексей.

Ответ

Roman, automotive body SW development

1. цикл разработки электронных блоков управления довольно не маленький и составляет несколько лет в зависимости от сложности и добросовестности к подходу к процессу разработки
2. электронная элементная база, которая поддерживает CAN FD была выпущена относительно недавно и ещё до конца не испытана и не внедрена
3. современные протоколы передачи данных (CAN-матрицы и т.д.) современных автомобилей пока не адаптированы к новому длинному формату сообщений CAN FD, есть некоторые нюансы. Перевод сетевой электронной архитектуры автомобилей занимает большое количество времени и средств и обычно привязан к пункту номер 1
4. по ряду причин (как технических, так и финансовых) в протоколе CAN FD нуждаются лишь автомобили класса среднего и выше, у которых электронная архитектура широко развита. Какой смысл в CAN FD, высокопропускной шине, когда на борту всего 5 блоков управления? Лоукост до сих пор является лидером рынка.
5. экономическая ситуация на рынке личного транспорта, снижение спроса из-за переполненности рынка и замедления мировой экономики в целом.

С технической точки зрения, к протоколу тоже есть некоторые вопросы. Самый главный с моей точки зрения следующий: производители сетевого автомобильного оборудования заинтересованы в увеличении пропускной способности шины. Но по факту частота передачи сообщений при переходе с классического CAN на CAN FD не изменится никак, поскольку практически никаких изменений в структуре кадра не произошло. Фактически, лишь количество данных в одном кадре увеличилось. Но, учитывая, что сеть делится на сообщения по функциональному назначению, увеличение количества передаваемых данных в одном сообщении не столь важно, сколько важно увеличение пропускной способности шины (увеличение баудрейта) с целью увеличения количества блоков управления на одной шине, то есть именно ёмкости шины. При переходе на CAN FD ёмкость шины, конечно, увеличится, но косвенно. Тут уже будет спасать сегментация сети и использование других интерфейсов (LIN, Ethernet) в соответствии с их применением.

Надеюсь, я ответил на Ваш вопрос.

О компании ИТЭЛМА

Мы большая компания-разработчик automotive компонентов. В компании трудится около 2500 сотрудников, в том числе 650 инженеров.

Мы, пожалуй, самый сильный в России центр компетенций по разработке автомобильной электроники. Сейчас активно растем и открыли много вакансий (порядка 30, в том числе в регионах), таких как инженер-программист, инженер-конструктор, ведущий инженер-разработчик (DSP-программист) и др.

У нас много интересных задач от автопроизводителей и концернов, двигающих индустрию. Если хотите расти, как специалист, и учиться у лучших, будем рады видеть вас в нашей команде. Также мы готовы делиться экспертизой, самым важным что происходит в automotive. Задавайте нам любые вопросы, ответим, пообсуждаем.

Читать еще полезные статьи:

• [Прогноз] Транспорт будущего (краткосрочный, среднесрочный, долгосрочный горизонты)
• Лучшие материалы по взлому автомобилей с DEF CON 2018-2019 года
• [Прогноз] Motornet — сеть обмена данными для роботизированного транспорта
• Компании потратили 16 миллиардов долларов на беспилотные автомобили, чтобы захватить рынок в 8 триллионов
• Камеры или лазеры
• Автономные автомобили на open source
• McKinsey: переосмысляем софт и архитектуру электроники в automotive
• Очередная война операционок уже идет под капотом автомобилей
• Программный код в автомобиле
• В современном автомобиле строк кода больше чем…

• can
• automotive
• итэлма
• компоненты для автопроизводителей
• электроника для автотранспорта

FAQ Новый стандарт проrокола шины CAN. Применения шина CAN-FD, что это такое?

С Новым годом Вас и Ваши семьи! Здоровья Всем в новом году!
Может быть, кто то, в курсе?
Есть новостной дайджест!
В 2021 году фирма BOSCH, анонсировала новый стандарт протокола шины CAN, это CAN FD
Интересно мнение коллег, какое оборудование разрабатывается и внедрено, в решение и в работу с данным вопросом?
Кто, каким оборудованием пользуется, в работе с шиной CAN FD?

Что такое CAN FD

Шина CAN-FD – это следующий этап развития классической шины CAN. CAN-FD обеспечивает более высокую скорость передачи данных и больший объем передаваемых данных в одном кадре.
CAN FD — это протокол передачи данных, обычно используемый для широковещательной передачи данных датчиков и управляющей информации по двухпроводным соединениям между различными частями электронной аппаратуры и системы управления. Этот протокол используется в современных высокопроизводительных транспортных средствах.

Основные отличия CAN-FD от классической шины CAN​

• CAN-FD работает одновременно на двух скоростях. Поле арбитража или заголовок кадра передается со скоростью такой же как и в классическом варианте, например 500 кбит\с. А поле данных передается на скорости кратно превышающую скорость передачи заголовка, и может иметь значение вплоть до 12 Мбит\с.
• CAN-FD может передать до 64 байт данных в одном пакете. А классический CAN максимум 8 байт.
• CAN-FD контроллер способен принимать классические CAN пакеты, а классический CAN контроллер не способен принимать пакеты формата CAN-FD.
• Для шины CAN-FD необходимо применять специальные микросхемы-трансиверы с повышенным быстродействием.

Почему на шине CAN-FD используется передача на двух скоростях​

Скорость шины CAN ограничивает тот факт, что в определенные моменты времени в режиме передачи могут находится несколько узлов на шине. Это фазы арбитража и ожидания подтверждения приема пакета. Следовательно, каждый бит должен передаваться за время, которое не меньше чем то время, которое определяется уровнем напряжения на шине, достаточного для обмена данными между двумя узлами на шине.
Например: на шине CAN длиной 40 метров максимальная скорость передачи составляет около 1 Мбит\с для выполнения требуемого времени передачи в один бит. НО! Это ограничение действует только для обозначенных выше фаз Арбитража и ожидания подтверждения, а в фазе передачи данных, когда разрешена работа ТОЛЬКО ОДНОГО передатчика, это ограничение на скорость не действует. Этот факт и был взят за основу нового стандарта CAN FD.
Фирма BOSCH – разработчик стандарта CAN решила в новом стандарте CAN-FD поднять скорость обмена данными на участке передачи байт данных, между фазой арбитража, куда входит поле ID и DLC, и фазой ожидания подтверждения.

Совместимость CANFD и классической шины CAN​

Базовые форматы кадров CAN-FD и CAN имеют различия. Контрольное поле в формате FD длиннее и несет больше информации.

Пожалуйста, войдите или зарегистрируйтесь , чтобы просмотреть скрытый текст.

Кликните для увеличения

• FDF – признак того что кадр есть кадр CAN-FD
• BRS – признак того что используется переключение битрейта
• ESI – флаг того что счетчик ошибок узла полон

1. В классическом CAN формате с количеством байт данных до 8.
2. В формате CAN-FD с переключением скоростей и количеством байт данных до 64.
3. В формате CAN-FD без переключения скоростей и количеством байт данных до 64 .

А так же, эти же варианты но с 29-битным ID.
Таким образом из-за различий в базовом формате кадра между CAN-FD и CAN, отсутствует совместимость снизу вверх. Таким образом модуль CAN не может принимать кадры CAN-FD. Но модуль CAN-FD способен принимать и предавать кадры в классическом формате.

Количество передаваемых данных​

На шине CAN-FD в каждом кадре может передаваться до 64 байт данных, что существенно повышает пропускную способность классического варианта CAN . Количество передаваемых байт так же устанавливается в поле DLC, имеющее размер 4 бита. Поэтому соответствие между значением поля DLC и количеством передаваемых данных выглядит так:
DLC =0, количество байт = 0;
DLC =1, количество байт = 1;
DLC =2, количество байт = 2;
DLC =3, количество байт = 3;
DLC =4, количество байт = 4;
DLC =5, количество байт = 5;
DLC =6, количество байт = 6;
DLC =7, количество байт = 7;
DLC =8, количество байт = 8;
DLC =9, количество байт = 12;
DLC =10, количество байт = 16;
DLC =11, количество байт = 20;
DLC =12, количество байт = 24;
DLC =13, количество байт = 32;
DLC =14, количество байт = 48;
DLC =15, количество байт = 64;

Пакет с 64 байтами данных в окне анализатора шины CAN FD:

Сигнал на шине CAN-FD на экране осциллографа​

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

Где применяется CAN-FD​

По состоянию на декабрь 2020 года шина CAN FD применяется на автомобилях премиум класса производства: группы VAG, GM, Ford, BMW, KIA\HYUNDAI. При этом CAN-FD используется на критичных к скорости обмена участках сети CAN.
Например, на автомобилях KIA Sorento MQ4, KIA Carival KA4 2021,Hyundai Tucson NX4 2021 года выпуска по шине CAN FD происходит взаимодействие компонентов ADAS (радары, камеры), а так же по этой шине получает необходимые данные – панель приборов.

Пожалуйста, войдите или зарегистрируйтесь , чтобы просмотреть скрытый текст.

На автомобилях Mercedes Benz с мульти доменной архитектурой сети так же применяется шина CAN FD наряду с классической шиной CAN 2.0

Пожалуйста, войдите или зарегистрируйтесь , чтобы просмотреть скрытый текст.

Сегменты сети автомобилей Mercedes-Benz S-класс BR223 где применяется шина CAN FD​

Оборудование Launch-X431, для работы с шиной CANFD​

Данный адаптер совместим с диагностическим оборудованием:

Данное оборудование применимо к моделям автомобилей в расширяющейся базе протоколов.

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

FDCAN на STM32

Запускаем модуль flexible data rate can на STM32H743 на регистрах без HAL и cubemx.

Вступление.

Новый стандарт FDCAN был разработан компанией BOSCH в 2012 году. Стандарт обеспечивает больший объём передаваемых данных и скорости больше 1 мбит (для поля данных), скорость которого может достигать 12 мбит. Размер поля данных был увеличен до 64 байт. Что касается совместимости can и fdcan, то приёмники нового стандарта понимают старый вариант протокола, а старые приёмники не совместимы с новым стандартом. Углубляться в особенности протокола не будем, т.к. этой информации достаточно в интернете, а сразу перейдём к реализации fdcan от stm.

Инициализация модуля FDCAN.

Основное отличие FDCAN от BxCAN в микроконтроллерах stm32 заключается в реализации выделенной памяти для фильтров и буферов. В мк stm32h743 для fdcan выделено ровно 10 кбайт общей памяти (для fdcan1 и fdcan2). Эта область памяти гибко настраивается под любые нужны.

Адресация этой памяти идёт по 4 байта (слово): младшие два бита адреса не используются и адрес битовых полей xxSA (стартовый адрес каждого раздела) сдвинут на два бита вправо. Начальный стартовый адрес этой области памяти в мк stm32h743 = 0x4000AC00.

Далее последовательность настройки:

1) Выбираем источник тактирования модулей fdcan:

• 00: hse_ck clock is selected as FDCAN kernel clock (default after reset)
• 01: pll1_q_ck clock is selected as FDCAN kernel clock
• 10: pll2_q_ck clock is selected as FDCAN

RCC->D2CCIP1R |= RCC_D2CCIP1R_FDCANSEL_1;

2) Настраиваем пины GPIO на нужную нам функцию:

Если используем стандартный CAN, то ищем пины FDCANxTX / FDCANxRX. Если используем FDCAN, то пины соответственно FDCANx_TXFD_MODE / FDCANxRXFDMODE. В моём примере я использовал обычный CAN на пинах PA11 (RX) и PA12 (TX), альтернативная функция #9. Использую свою инициализацию. Библиотека есть на github`e.

gpio_init (PORT_A, 11, MODE_ALT_F, TYPE_PUSH_PULL, SPEED_MAX, PULL_NO, ALTF_9); // RX gpio_init (PORT_A, 12, MODE_ALT_F, TYPE_PUSH_PULL, SPEED_MAX, PULL_NO, ALTF_9); // TX

3) Включаем FDCAN модули:

RCC->APB1HENR |= RCC_APB1HENR_FDCANEN;

4) Входим в процесс инициализации:

FDCAN1->CCCR |= FDCAN_CCCR_INIT; while ((FDCAN1->CCCR & FDCAN_CCCR_INIT) == 0) <>;

5) Разрешаем запись в регистры настройки:

FDCAN1->CCCR |= FDCAN_CCCR_CCE;

6) Включаем классический CAN и выключаем автоматическую ретрансляцию:

FDCAN1->CCCR &= ~(FDCAN_CCCR_FDOE); FDCAN1->CCCR |= FDCAN_CCCR_DAR; // RETR OFF

7) При необходимости можно включить Loopback режим для отладки:

FDCAN1->CCCR |= FDCAN_CCCR_TEST; FDCAN1->TEST |= FDCAN_TEST_LBCK;

8) Очищаем область памяти:

#define FDCAN_MEM_START_ADDR 0x4000AC00UL #define FDCAN_MEM_END_ADDR 0x4000D3FFUL unsigned long *i; for (i = (unsigned long*)FDCAN_MEM_START_ADDR; i < (unsigned long*)FDCAN_MEM_END_ADDR; i++) *i = 0;

9) Настраиваем номинальные time quanta сегменты и при необходимости time quanta сегменты для переменного битрейта :

#define CAN_PRESCALER 6 #define CAN_SYNC_JW 2 #define CAN_SYNC_SEG 1 #define CAN_PHASE_SEG1 11 #define CAN_PHASE_SEG2 4 // nominal time quanta segments FDCAN1->NBTP = (CAN_SYNC_JW - 1) NBTP |= (CAN_PRESCALER - 1) NBTP |= (CAN_PHASE_SEG1 - 1) NBTP |= (CAN_PHASE_SEG2 - 1) DBTP = (CAN_SYNC_JW - 1) DBTP |= (CAN_PRESCALER - 1) DBTP |= (CAN_PHASE_SEG1 - 1) DBTP |= (CAN_PHASE_SEG2 - 1) 

FDCAN1->GFC |= FDCAN_GFC_ANFS; // Reject non-matching frames standard FDCAN1->GFC |= FDCAN_GFC_ANFE; // Reject non-matching frames extended FDCAN1->GFC |= FDCAN_GFC_RRFS; // Reject all remote frames with 11-bit standard ID FDCAN1->GFC |= FDCAN_GFC_RRFE; // Reject all remote frames with 29-bit standard ID

// 11-bit filters #define FDCAN_11B_FILTER_EL_CNT 0UL #define FDCAN_11B_FILTER_EL_SIZE 4UL #define FDCAN_11B_FILTER_EL_W_SIZE (FDCAN_11B_FILTER_EL_SIZE / 4) #define FCCAN_11B_FILTER_START_ADDR (FDCAN_MEM_START_ADDR) #define FDCAN_11B_FILTER_OFFSET 0UL // 29-bit filters #define FDCAN_29B_FILTER_EL_CNT 4UL #define FDCAN_29B_FILTER_EL_SIZE 8UL #define FDCAN_29B_FILTER_EL_W_SIZE (FDCAN_29B_FILTER_EL_SIZE / 4) #define FCCAN_29B_FILTER_START_ADDR (FCCAN_11B_FILTER_START_ADDR + FDCAN_11B_FILTER_EL_CNT * FDCAN_11B_FILTER_EL_SIZE) #define FDCAN_29B_FILTER_OFFSET (FDCAN_11B_FILTER_OFFSET + FDCAN_11B_FILTER_EL_CNT * FDCAN_11B_FILTER_EL_W_SIZE) FDCAN1->SIDFC = (FDCAN_11B_FILTER_EL_CNT XIDFC = (FDCAN_29B_FILTER_EL_CNT SIDFC |= (FDCAN_11B_FILTER_OFFSET XIDFC |= (FDCAN_29B_FILTER_OFFSET  

#define CAN_TEST_ID_0 0x01 #define CAN_TEST_ID_1 0x02 // FILTER TYPE #define FILTER_TYPE_RANGE 0UL #define FILTER_TYPE_DUAL 1UL #define FILTER_TYPE_CLASSIC 2UL #define FILTER_TYPE_DISABLE 3UL /* FILTER CONFIG */ #define FILTER_CFG_DISABLED 0UL #define FILTER_CFG_STORE_FIFO_0 1UL #define FILTER_CFG_STORE_FIFO_1 2UL #define FILTER_CFG_REJECT 3UL unsigned long *ptr = (unsigned long*)FCCAN_29B_FILTER_START_ADDR; *ptr++ = (FILTER_CFG_STORE_FIFO_0 

// Rx FIFO 0 #define FDCAN_RX_FIFO_0_EL_CNT 10 #define FDCAN_RX_FIFO_0_HEAD_SIZE 8UL #define FDCAN_RX_FIFO_0_DATA_SIZE 8UL #define FDCAN_RX_FIFO_0_EL_SIZE (FDCAN_RX_FIFO_0_HEAD_SIZE + FDCAN_RX_FIFO_0_DATA_SIZE) #define FDCAN_RX_FIFO_0_EL_W_SIZE (FDCAN_RX_FIFO_0_EL_SIZE / 4) #define FDCAN_RX_FIFO_0_START_ADDR (FCCAN_29B_FILTER_START_ADDR + FDCAN_29B_FILTER_EL_CNT * FDCAN_29B_FILTER_EL_SIZE) #define FDCAN_RX_FIFO_0_OFFSET (FDCAN_29B_FILTER_OFFSET + FDCAN_29B_FILTER_EL_CNT * FDCAN_29B_FILTER_EL_W_SIZE) FDCAN1->RXF0C = FDCAN_RX_FIFO_0_OFFSET RXF0C |= FDCAN_RX_FIFO_0_EL_CNT 

// TX buffers (FIFO) #define FDCAN_TX_FIFO_EL_CNT 10UL #define FDCAN_TX_FIFO_HEAD_SIZE 8UL #define FDCAN_TX_FIFO_DATA_SIZE 8UL #define FDCAN_TX_FIFO_EL_SIZE (FDCAN_TX_FIFO_HEAD_SIZE + FDCAN_TX_FIFO_DATA_SIZE) #define FDCAN_TX_FIFO_EL_W_SIZE (FDCAN_TX_FIFO_EL_SIZE / 4) #define FDCAN_TX_FIFO_START_ADDR (FDCAN_TX_EVENT_START_ADDR + FDCAN_TX_EVENT_FIFO_EL_CNT * FDCAN_TX_EVENT_FIFO_EL_SIZE) #define FDCAN_TX_FIFO_OFFSET (FDCAN_TX_EVENT_OFFSET + FDCAN_TX_EVENT_FIFO_EL_CNT * FDCAN_TX_EVENT_FIFO_EL_W_SIZE) FDCAN1->TXBC &= ~(FDCAN_TXBC_TFQM); // FIFO operation FDCAN1->TXBC |= FDCAN_TX_FIFO_EL_CNT TXBC |= FDCAN_TX_FIFO_OFFSET 

FDCAN1->IE |= FDCAN_IE_RF0NE; FDCAN1->ILE |= FDCAN_ILE_EINT0;

FDCAN1->CCCR &= ~(FDCAN_CCCR_INIT); while ((FDCAN1->CCCR & FDCAN_CCCR_INIT) == 1) <>; NVIC_EnableIRQ(FDCAN1_IT0_IRQn); __enable_irq();

struct can_message < unsigned char error; unsigned long id; unsigned char data[8]; unsigned char length; unsigned char format; unsigned char type; >; struct can_fifo_element < unsigned long word0; unsigned long word1; unsigned long word2; unsigned long word3; >;

#define CAN_STANDARD_FORMAT 0UL #define CAN_EXTENDED_FORMAT 1UL #define DATA_FRAME 0UL #define REMOTE_FRAME 1UL struct can_message can_rx_message; struct can_message can_tx_message; void FDCAN1_read_msg (struct can_message* msg, unsigned char idx) < struct can_fifo_element *fifo; // присваиваем адрес нашей структуре fifo = (struct can_fifo_element*)(FDCAN_RX_FIFO_0_START_ADDR + idx * FDCAN_RX_FIFO_0_EL_SIZE); // парсим поля msg->error = (unsigned char)((fifo->word0 >> 31) & 0x01); msg->format = (unsigned char)((fifo->word0 >> 30) & 0x01); msg->type = (unsigned char)((fifo->word0 >> 29) & 0x01); // тип идентификатора if (msg->format == CAN_EXTENDED_FORMAT) < msg->id = fifo->word0 & 0x1FFFFFFF; > else < msg->id = (fifo->word0 >> 18) & 0x7FF; > // длина данных msg->length = (unsigned char)((fifo->word1 >> 16) & 0x0F); // данные msg->data[0] = (unsigned char)((fifo->word2 >> 0) & 0xFF); msg->data[1] = (unsigned char)((fifo->word2 >> 8) & 0xFF); msg->data[2] = (unsigned char)((fifo->word2 >> 16) & 0xFF); msg->data[3] = (unsigned char)((fifo->word2 >> 24) & 0xFF); msg->data[4] = (unsigned char)((fifo->word3 >> 0) & 0xFF); msg->data[5] = (unsigned char)((fifo->word3 >> 8) & 0xFF); msg->data[6] = (unsigned char)((fifo->word3 >> 16) & 0xFF); msg->data[7] = (unsigned char)((fifo->word3 >> 24) & 0xFF); >

void FDCAN1_IT0_IRQHandler(void) < unsigned char rx_fifo_get_index; // новое сообщение получено if((FDCAN1->IR & FDCAN_IR_RF0N) != 0) < // очищаем флаг FDCAN1->IR = FDCAN_IR_RF0N; // берём индекс нового пакета в буфере rx_fifo_get_index = (unsigned char)((FDCAN1->RXF0S >> 8) & 0x3F); // читаем пакет FDCAN1_read_msg (&can_rx_message, rx_fifo_get_index); // обновляем индекс прочитанных пакетов FDCAN1->RXF0A = rx_fifo_get_index; >; // сообщение потеряно в случае переполнения if((FDCAN1->IR & FDCAN_IR_RF0L) != 0) < // очищаем флаг FDCAN1->IR = FDCAN_IR_RF0L; >; // буфер RX FIFO переполнен if((FDCAN1->IR & FDCAN_IR_RF0F) != 0) < // do something >; >

#define CAN_STANDARD_FORMAT 0UL #define CAN_EXTENDED_FORMAT 1UL #define DATA_FRAME 0UL #define REMOTE_FRAME 1UL // Заполняем поля пакета can_tx_message.id = 1; can_tx_message.format = CAN_EXTENDED_FORMAT; can_tx_message.type = DATA_FRAME; can_tx_message.length = 10; can_tx_message.data[0] = 20; can_tx_message.data[1] = 30; can_tx_message.data[2] = 40; can_tx_message.data[3] = 50; can_tx_message.data[4] = 60; can_tx_message.data[5] = 70; can_tx_message.data[6] = 80; can_tx_message.data[7] = 90; void FDCAN1_send_msg (struct can_message *msg) < struct can_fifo_element *fifo; unsigned char tx_index; // проверка буфера if ((FDCAN1->TXFQS & FDCAN_TXFQS_TFQF) != 0) < // буфер переполнен >// берём следующий свободный индекс tx_index = (FDCAN1->TXFQS >> 16) & 0xF; // присваиваем нашей fifo структуре адрес в буфере fifo = (struct can_fifo_element *)(FDCAN_TX_FIFO_START_ADDR + tx_index * FDCAN_TX_FIFO_EL_SIZE); //идентификатор пакета STD или EXT if (msg->format == CAN_STANDARD_FORMAT) < fifo->word0 = (msg->id else < fifo->word0 = msg->id; fifo->word0 |= 1UL // кадр удалённого запроса if (msg->type == REMOTE_FRAME) fifo->word0 |= 1UL word1 = (8UL word2 = (msg->data[3] data[2] data[1] data[0]; fifo->word3 = (msg->data[7] data[6] data[5] data[4]; // увеличиваем индекс и запускаем передачу пакета FDCAN1->TXBAR |= (1UL