CAN FD, вопросы совместимости Опции

[Doka]

Вопрос такой (больше относится наверное к тестовому покрытию):
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 плюшки).
Ссылку не укажу, читал в каком то обзоре.

[Doka]

Да вот я тоже не найду где читал - там же есть какой-то хитрый режим - голова передается на стандартной скорости (совместимость с 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 не сможет разобрать эти данные (скорость передачи другая) и выдаст в условленное время бит ошибки. Пакет не принят.

[Doka]

По времени - да, может совпадут, а по содержимому 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-ти рецессивных бит

[Arlleex]

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

[редактор]

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

[Doka]

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

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