9.3.1. Протокол can

Протокол CAN был первоначально создан для автомобильных прикладных решений. Но вскоре концепции и преимущества CAN привлекли внимание разработчиков из других областей промышленности, и этот протокол стал одним из самых распространенных методов работы с сетями для небольших распределенных систем реального времени. Мы проведем здесь лишь краткое рассмотрение этого протокола; более подробную информацию читатели могут найти в дополнительной литературе, приведенной в конце этой главы.

Последняя редакция протокола CAN (версия 2.0) состоит из двух частей: части A (стандартный формат) и В (расширенный формат). Часть A представлена следующими тремя уровнями: объектным, уровнем передачи и физическим уровнем. Объектный уровень является связующим звеном между уровнем передачи и прикладной программой, выполняемой центральным процессором МК. На этом уровне происходят все программные обработки CAN-сообщений. Уровень передачи обеспечивает полное соответствие сообщения стандартному протоколу обмена, в то время, как на физическом уровне происходит реальная передача сигналов сообщения.

Часть В версии 2.0 протокола касается уровня передачи данных и физического уровня. Уровень передачи данных в свою очередь включает в себя подуровень управления логическими связями LLC (Logical Link Control) и подуровень управления доступом к среде MAC (Medium Access Control). Совокупность функций, выполняемых подуровнями LLC, MAC и физическим уровнем, соответствует функциям объектного уровня, уровня передачи и физического уровня для части A протокола CAN 2.0. На рис. 9.2 показаны части A и B протокола CAN 2.0. В дальнейшем мы будем в равной степени использовать термины из частей A и B протокола CAN 2.0.

Рис. 9.2. Соответствие терминов модели ISO/OSI для протоколов CAN 2.0 A/B

Уникальным свойством протокола CAN является то, что при работе с сообщениями не указываются адреса узла отправителя и узла получателя. Вместо этого, в каждое сообщение вставляется идентификатор, который позволяет этому сообщению быть принятым любым узлом сети CAN без всякого изменения содержимого передаваемых кадров. Это также означает, что одно и то же сообщение может быть одновременно принято несколькими узлами, позволяя осуществлять так называемый широковещательный режим или мультикастинг. Протокол CAN содержит прямую методику арбитража и сложные механизмы обнаружения ошибок. Он поддерживает также энергосберегающие режимы для узлов: спящий режим и режим пробуждения.

Данные в CAN передаются короткими сообщениями — кадрами стандартного формата. В CAN существуют четыре типа сообщений: кадр данных, кадр удаленного запроса, кадр ошибки и кадр перегрузки. Проведем короткий обзор этих типов кадров.

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

Рис. 9.3. Кадр данных CAN

Идентификатор содержит 11 для стандартного формата и 29 бит расширенного формата кадра данных. Поле арбитража также содержит бит удаленного запроса передачи (RTR), который используется, чтобы отличить кадр данных от кадра удаленного запроса. Для кадра данных этот бит должен быть доминантным (логический нуль), для кадра удаленного запроса — рецессивным (логическая 1).

Поле управления содержит четыре бита, которые определяют длину данных в байтах. Длина данных определяется четырьмя отдельными битами, позволяя устанавливать значение от одного до восьми байт. Поскольку рецессивный бит соответствует передаче логической 1, то четыре активных бита в этом поле информируют о длине поля данных, равной 0. Поле данных содержит фактическое сообщение кадра передачи. Старший бит каждого байта передается первым. Поле проверки данных содержит контрольное число, которое используется принимающим узлом для проверки отсутствия ошибок в принятом кадре. Контрольное число формируется по специальным правилам (CRC код), с которыми читатель может подробно ознакомиться в литературе, приведенной в конце главы. Поле подтверждения (ACK) содержит два бита. Передающий узел в поле подтверждения выставляет две 1. Если прием данных завершился успешно, то принимающий узел в первом бите выставляет на шину 0. Передающий узел в процессе передачи осуществляет считывание состояния шины. Поэтому наличие доминантного уровня 0 в первом бите поля подтверждения будет воспринято им как подтверждение приема данных. Первый бит поля подтверждения называется ACK-Slot, второй ACK-Delimiter. Поле конца кадра представляет собой последовательность из семи единичных битов, которые свидетельствуют об окончании кадра.

Кадр удаленного запроса используется принимающими узлами, чтобы запросить повторную передачу кадра данных. Кадр удаленного запроса идентичен кадру данных за исключением того, что он не содержит поля данных. Для того, чтобы принимающий узел мог отличить кадр удаленного запроса от кадра данных, в поле арбитража предусмотрен специальный бит RTR. Рецессивное состояние бита RTR (логическая 1) обозначает кадр удаленного запроса, а доминантное состояние (логический 0) — кадр данных.

Кадр ошибки, представленный на рис. 9.4, информирует узлы сети о том, что на шине CAN произошла ошибка. Каждый кадр ошибки состоит из поля признака ошибки и поля разделителя ошибки. Поле признака ошибки содержит либо активные флаги ошибки (шесть доминантных бит), либо пассивные флаги ошибки (шесть рецессивных бит). Мы дадим определение понятиям активных и пассивных ошибок в разделе обработки ошибок. Следует заметить, что в системах с многочисленными узлами на шине CAN число доминантных бит в признаке ошибки может увеличиваться до 12. Это необходимо, чтобы все компоненты системы могли использовать флаги ошибки. Поле разделителя ошибки состоит из восьми рецессивных бит.

Рис. 9.4. Кадр ошибки CAN

Кадр перегрузки, как показано в рис. 9.5, имеет тот же формат, что и кадр ошибки. Флаг перегрузки составлен из шести доминантных бит. Биты флага перегрузки устанавливаются, когда:

• принимающий узел не может обработать корректные кадры за выделенное время, и требует задержки;

• на интервале паузы появился доминантный бит.

Рис. 9.5. Кадр перегрузки CAN

Кадры данных и удаленного запроса на шине CAN отделяются от других кадров интервалами паузы, которые состоят, по крайней мере, из трех рецессивных бит. Разделитель перегрузки составлен из восьми рецессивных бит.

Обработка ошибок. Во время передачи сообщения по CAN шине могут происходить ошибки. Когда активным (передающим сообщение) или пассивным (принимающим) узлом системы обнаружена ошибка, соответствующий узел выставляет на шину кадр ошибки, рассмотренный выше. Если активный узел передает кадр ошибки, флаг ошибки называется активным флагом ошибки; если ошибка зафиксирована в пассивном узле, то и флаг называется пассивным. Имеются пять типов ошибок, которые могут вызывать передачу кадра ошибки: ошибка разряда (1), ошибка заполнения (2), ошибка избыточности (3), ошибка формы (4) и ошибка подтверждения (5).

Ошибка разряда происходит, когда передающий узел обнаруживает несоответствие выставляемого на шину бита и реального состояния шины в тот же момент времени. Флаг ошибки заполнения устанавливается, когда контроллер CAN обнаруживает в передаваемом кадре шесть последовательных доминантных или шесть последовательных рецессивных бит. Ошибка контроля происходит, когда значение контрольного числа CRC, вычисленное приемником, не соответствует контрольному числу CRC, полученному в конце передачи. Ошибка формы фиксируется, когда в одном из полей кадра содержатся недопустимые биты. И наконец, ошибка подтверждения происходит, когда отсутствует доминантный бит в поле ACK-Slot.

Синхронизация бита. На рис. 9.6 показано, что интервал времени передачи одного бита по шине CAN разбивается на четыре временных сегмента: сегмент синхронизации, сегмент распространения, сегмент буфера фазы 1 и сегмент буфера фазы 2. На интервале первого сегмента появляется фронт, который используется, чтобы синхронизировать узлы, подключенные к шине. Выборка логического состояния бита производится после окончания сегмента буфера фазы 1 (точка выборки). Сегмент времени распространения учитывает задержку передатчика и приемника и время распространения сигнала по шине. Сегменты фазы 1 и 2 могут увеличиваться или уменьшаться по длительности посредством программных уставок при инициализации. Такое решение позволяет увеличить надежность передачи данных по шине.

Рис. 9.6. Номинальные сегменты времени передачи бита