Я знаю, как шина CAN выполняет арбитраж. Вкратце, идентификатор узла CAN, имеющий больше «0» в идентификаторе, побеждает в обряде для передачи по шине, и остальные конкурирующие узлы отключаются.
Но я не нахожу никаких подробностей о how long отказавшем узле, ожидающем перед повторной попыткой вернуть шину. Я проконсультировался с несколькими источниками, но все еще не могу найти ответ. Есть ли экспериментальные доказательства этого?
Можно попробовать еще раз после того, как выигравший кадр был передан и в «поле перерыва» в конце кадра CAN не было найдено ни одного доминирующего бита. Вы, вероятно, найдете формальное определение этого, если будете искать в спецификации «поле перерыва», см., Например, 3.1.5 старой (устаревшей) спецификации Bosch, которую вы связали.
Здесь важно понимать, что каждый контроллер CAN прослушивает каждый кадр, даже если он ему не интересен. Таким образом достигается предотвращение столкновений, а не их обнаружение.
Как упоминалось в документе спецификации Bosch CAN, все узлы CAN могут начать отправку ожидающих кадров при возникновении состояния бездействия шины (на шине не обнаружено доминирующего бита). В течение периода перерыва в интервале между кадрами ни один узел не может передавать (кадры перегрузки могут передаваться, но не кадры данных или удаленных кадров). Узлы CAN должны ждать 3 рецессивных бита в течение этого периода. Все узлы могут начать передачу сразу после этого перерыва.
Если несколько узлов запускаются одновременно после периода перерыва, то в арбитраже будет выигран самый низкий кадр идентификатора. Если удаленный фрейм и фрейм данных (оба имеют одинаковый идентификатор) с разных узлов начинаются, то фрейм данных выиграет арбитраж.
Я согласен с ответами выше, но я искал более математический анализ таймингов CAN-шины. Я нашел эти отличные записи лекции: Анализ времени сообщений CAN . Глава 3
