Версия для печати темы

Автор: Doka Oct 25 2016, 08:18

Вопрос такой (больше относится наверное к тестовому покрытию):
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://electronix.ru/redirect.php?http://can-newsletter.org/uploads/media/raw/e5740b7b5781b8960f55efcc2b93edf8.pdf

Автор: редактор Oct 25 2016, 11:29

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

Автор: Doka Oct 25 2016, 12:02

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

Автор: редактор Oct 26 2016, 13:09

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

Автор: Doka Nov 29 2016, 07:32

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




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

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

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

Автор: Arlleex May 31 2018, 14:35

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

Автор: редактор May 31 2018, 16:50

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

Автор: Doka May 31 2018, 16:57

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