Протокол can

Протокол CAN (Controller Area Network) был разработан компанией Bosch несколько лет назад как сетевое решение для связи компьютерных систем, применяемых в автомобилях. В то время не существовало единого стандарта для связи цифровых устройств в автомобилях. До появления протокола CAN (или протокола J1850, который является аналогичным американским стандартом) автомобили содержали до трех миль проводов весом свыше 90 кг, которые связывали различные автомобильные электронные устройства. Протокол CAN был разработан, чтобы удовлетворять следующим требованиям:

1. Высокая скорость обмена (до I Мбит/с).

2. Нечувствительность к электромагнитным помехам.

3. Простота, небольшое количество разъемных контактов (для обеспечения механической надежности).

4. Легкость подключения и удаления устройств.

Протокол CAN подобен протоколу J 1850 и основывается на тех же первых двух уровнях семиуровневой модели OSI, однако эти два стандарта электрически несовместимы. Стандарт па протокол CAN появился раньше, поэтому данный стандарт реализуется практически но всех моделях европейских и японских автомобилей, а в настоящее время активно используется и американскими автомобильными компаниями.

Протокол CAN реализуется с использованием операции «монтажное И», которая используется также шиной I2C. Передача данных на физическом электрическом уровне реализуется с помощью драйверов, соответствующих стандарту RS-485, которые обеспечивают выдачу на линию связи дифференциального напряжения. Такая сеть будет работать даже если один из двух проводников закорочен иди оборван, что особенно важно для обеспечения надежности автомобильного оборудования. Использование соединения, реализующего "монтажное И", позволяет выполнять арбитраж между различными ведущими устройствами: когда выходные драйверы устройства активны, то шина CAN переводится в низкое состояние, аналогично 12С.

Рис. 16. Арбитраж при передаче по шине CAN

Пример реализации этого метода арбитража показан на рис. 16. Когда сигнал, выдаваемый драйвером, не совпадает с уровнем, установленным на линии передачи данных (например, при выдаче 1 на шине оказывается 0), то драйвер останавливает передачу данных до тех пор пока не завершится пересылка текущего сообщения. Этот простой и эффективным способ арбитража исключает необходимость повторной посылки сообщения при возникновении коллизий на шине.

Каждое сообщение представляет собой отдельный кадр в потоке пересылаемых данных. Кадр передается как фрагмент этого асинхронного последовательного потока, в котором пересылки данных не сопровождается посылкой синхросигнала. При этом приемник и передатчик должны работать на одной частоте: обычно скорость обмена устанавливается в пределах от 200 Кбит/с до I Мбит/с. Формат кадра передачи данных показан на рис. 17.

Рис. 17. Кадр передачи данных по шине CAN с использованием 11-битного идентификатора

В протоколе CAN устройствам не даются специфические имена или адреса, сообщение идентифицировано (используя 11-и или 19-и битный идентификатор сообщения). Этот метод адресации может обеспечить очень гибкий обмен сообщениями.

При использовании протокола CAN нулевое значение бита называется "доминантным", а единичное значение — «рецессивным» (по аналогии с генами в биологии).

Различные поля кадра имеют следующее назначение:

• SOF {Start Of Frame) - начало кадра, единичный доминантный бит.

• Идентификатор - 11-и или 19-битный идентификатор сообщения.

• RTR - Бит. указывающий, что ведущее устройство является передатчиком (при RTR=I) или приемником (при RTR=0) данных.

• rl/rO - Зарезервированные биты, которые должны быть доминантными.

• DLC - 4 бита, которые указывают количество передаваемых байт.

• Data - от 0 до 8 передаваемых байте данных, где старший бит идет первым.

• CRC - 15 битный код контрольной суммы, за которым следует рецессивный бит.

• Ack — 2-битное поле подтверждения готовности (доминантный и рецессивный биты).

• EOF (End Of Frame) - конец кадра (поле, содержащее не менее 7 рецессивных бит).

Кадр в протоколе CAN имеет сложный формат, что осложняет его обработку в процессе передачи и приема сообщения. Такая обработка может выполняться как аппаратно, так и программно, но рекомендуется использовать только аппаратную реализацию CAN. Ряд производителей встраивают CAN-интерфейс в выпускаемые ими микроконтроллеры. Также существует несколько серийно выпускаемых устройств (особенно популярна микросхема Intel 82527), которые эффективно и с минимальными дополнительными затратами выполняют функции CAN интерфейса.