Стивен Барретт - Встраиваемые системы. Проектирование приложений на микроконтроллерах семейства 68HC12/HCS12 с применением языка С

Протокол 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. Поле конца кадра представляет собой последовательность из семи единичных битов, которые свидетельствуют об окончании кадра.