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 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-ти рецессивных бит