Перейти к содержанию
    

Вопрос такой (больше относится наверное к тестовому покрытию):

CAN Conformance test готовит о том, что СФ-блок CAN 2.0 должен работать при любом сочетании резервных полей в кадре.

 

Это было до эпохи CAN FD.

Интересует в частности режим сосуществования на шине CAN 2.0 и CAN FD

 

Как должно/нужно/можно:

1. Обрабатывать ли DUTом CAN 2.0 кадры CAN FD? Т.е. как минимум видится необходимость мониторить конец кадра чтобы значть когда начинается арбитраж на передачу нового кадра; и сюда же - чтобы кадры CAN FD не вызывали в DUTе CAN 2.0 инкремент счетчика ошибок приема.

2. Выдавать ли ACK DUTом CAN 2.0 после кадра CAN FD?

 

Может эти вещи где-то описаны, а я невнимательно читал - тогда, поржалуйста, укажите источник.

 

PS: неполная спека:

http://can-newsletter.org/uploads/media/ra...fcc2b93edf8.pdf

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Если мне не изменяет память, CAN FD совместим с CAN 2.0, но не наоборот.

Модуль CAN FD может работать в сетях 2.0 (исключаются плюшки FD), Модуль CAN 2.0 не может работать в сетях CAN FD (если используются те самые FD плюшки).

Ссылку не укажу, читал в каком то обзоре.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Да вот я тоже не найду где читал - там же есть какой-то хитрый режим - голова передается на стандартной скорости (совместимость с CAN 2.0), а поле данных передается на повышенной скорости, т.о. внутри стандартной для CAN 2.0 времянки передачи 8байт можно набить 64байта CAN FD (на скорости 8х) и пакеты по таймингам совпадут.

Обратите внимание, что даже поле DLC для CAN FD задаётся кратным 8: 16, 32, 48, 64

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

внутри стандартной для CAN 2.0 времянки передачи 8байт можно набить 64байта CAN FD (на скорости 8х) и пакеты по таймингам совпадут

По времени - да, может совпадут, а по содержимому CAN2.0 не сможет разобрать эти данные (скорость передачи другая) и выдаст в условленное время бит ошибки. Пакет не принят.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

По времени - да, может совпадут, а по содержимому CAN2.0 не сможет разобрать эти данные (скорость передачи другая) и выдаст в условленное время бит ошибки. Пакет не принят.

 

Ну, это конечно неприемлемо выдавать бит ошибки: FD-абоненты не смогут видеть друг друга. Что характерно, во всяких апликейшен на FD пишут, что согласно стандарта r0 в CAN 2.0 передается таки-доминантным:

 

The Control Field in standard CAN frames contains reserved bits which are specified to be transmitted dominant. In a CAN FD frame, the reserved bit after the IDE bit (11-bit Identifier) or after the RTR bit (29-bit Identifier) is redefined as Extended Data Length (EDL) bit and is transmitted recessive. This sets the receiving BSP and BTL FSMs into CAN FD decoding mode.

 

 

в итоге решил сделать так:

 

прикрутить ручку в виде конфиг бита, меняющего поведение приемного FSM следующим манером: если поле r0=1 (рецессив) в принимаемом кадре, то:

 

* не производить дальнейший приём кадра

* не выставлять на шину ни АСК, ни NACK

* не инкрементировать счётчики ошибок

* момент разрешения передачи собственных сообщений определять по факту приёма 11-ти рецессивных бит

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Сам с FD не работал, но не вижу причин для запрета.

обоснование:

Драйвера (выходные микросхемы) только для согласования уровня (перевода в доминантное/рецессивное состояние)

Основным отличием FD должна быть более высокая частота сигнала (поскольку FD может поднимать скорость в фазе передачи данных).Остальное - это логика CAN контроллера/

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

А возможно ли ставить драйвер шины CAN FD для работы с CAN 2.0B?

да. такое возможно.

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

On 5/31/2018 at 7:35 PM, Arlleex said:

А возможно ли ставить драйвер шины CAN FD для работы с CAN 2.0B?

Предпочтительнее будет использовать драйверы CAN FD ready, если предполагается использовать расширение FD, скорость всё же выше.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

11 hours ago, spf said:

Предпочтительнее будет использовать драйверы CAN FD ready, если предполагается использовать расширение FD, скорость всё же выше.

Спасибо за ответ!

Скорость там все-таки будет не более 125кбит/с, но драйверы были выбраны жестко и не мной. Поэтому и интересовала совместимость.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Есть вопрос.

В CAN 2.0B, насколько я знаю, длина кабеля на определенной скорости ограничивается тем фактором, что выставляемый бит должен быть виден всеми абонентами сети в течение битового интервала. Иначе невозможно будет провести арбитраж, как минимум. Кроме того, механизм сверки выставляемого бита передатчиком и его же, зафиксированным приемником, работает не только в фазе арбитража. Данные проверяются тоже. Если в данных возникнет коллизия бита, передатчик прекратит передачу, сформирует Error Frame, а также увеличит счетчик ошибок передачи и уведомит о Bit Error.

В CAN FD сверка битов в фазе передачи данных тоже осуществляется? Если да, то получается, что максимальная длина кабеля будет зависеть от скорости передачи поля данных. Т.е. например, для стандартного CAN 125кбит/с длина сегмента 500м, а для FD я должен в первую очередь посмотреть на скорость передачи битов поля данных? Например, если она 250кбит/с, я должен обкусить в 2 раза длину кабеля, верно?

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

04.02.2022 в 17:37, Arlleex сказал:

Если в данных возникнет коллизия бита

Насколько я помню - арбитраж идет на фазе ID, следовательно после стадии арбитража на линии остается один передатчик (до фазы подтверждения). Соответсвенно коллизии быть не должно, достоверность контролируется CRC. Это должно одинаково работать и в CAN2.0 и в CAN FD.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Это да, только вот стандарт говорит о том, что при передаче битов всегда происходит их же контроль в линии. Более того, контроллер устанавливает различное поведение отдельного флага ошибки Bit Error во время фазы арбитража и передачи данных. Во время арбитража, если передатчик отправлял рецессивный уровень, а увидел на линии доминантный, Bit Error выставлен не будет, вместо этого контроллер отключится от линии, не передавая туда ничего более. А вот если это будет в фазе данных или некоторых битах управления - установится Bit Error. И еще, к тому же, при обнаружении любой из 5 регистрируемых CAN-контроллером ошибок, контроллер отправляет разрушающий текущий кадр Error Frame, соответственно, нельзя просто так взять и "отключить" обнаружение битовых ошибок во время фазы данных. Все это указывает на то, что CAN 2.0B реализует механизм сравнения передаваемого/принимаемого бита в течение всего кадра (за исключением всяких Arbitration/ACK и некоторых других). В описании CAN FD все, что касается Bit Error и механизмов его активизации совпадает с CAN 2.0B. Соответственно, я выдвигаю гипотезу, что при расчете миксимальной длины шины (пусть это будет точка-точка) должен учитываться минимальный битовый интервал в кадре. А поскольку в CAN FD им может выступать только битовый интервал в фазе данных, то именно скорость передачи в фазе данных ограничивает длину кабеля. Вне зависимости от скорости арбитража и управляющих битов (стандартом называется "номинальная скорость"). Соответственно, я думаю, что все эти лозунги типа "скорость 10Мбит/с при той же длине кабеля, что в CAN 2.0B" - рекламная утка. Потому как "максимальная длина кабеля для данной скорости" и "вот у нас кабель метровый, раньше гоняли CAN 2.0B на 1Мбит/с, теперь тут CAN FD на 10Мбит/с" - вещи разные совершенно.

И еще: я не нашел явного запрета в стандарте на то, могут ли несколько передатчиков на шине иметь одинаковые CAN-ID. Соответственно, гипотеза о "после арбитража на шине активен только один передатчик" ставится под сомнение. Естественно, в жизни так делать не нужно (я про одинаковые ID), но и исключать возможность такого рода событий не правильно. Иначе, вдогонку, Bit Error во флагах статуса был бы и не нужен вовсе.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Цитата

И еще: я не нашел явного запрета в стандарте на то, могут ли несколько передатчиков на шине иметь одинаковые CAN-ID.

CAN-ID - это часть сообщения, а не узла. И да, любой узел может генерировать сообщение с любым CAN-ID.

Подобное обсуждение было на форуме в рамках одновременной передачи двумя узлами сообщения с одинаковым ID.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

1 час назад, Edit2007 сказал:

И да, любой узел может генерировать сообщение с любым CAN-ID.

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Присоединяйтесь к обсуждению

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

Гость
Ответить в этой теме...

×   Вставлено с форматированием.   Вставить как обычный текст

  Разрешено использовать не более 75 эмодзи.

×   Ваша ссылка была автоматически встроена.   Отображать как обычную ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

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

×
×
  • Создать...