Цитата(редактор @ Oct 26 2016, 16:09)
По времени - да, может совпадут, а по содержимому 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-ти рецессивных бит