Как составить идентификатор can

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

CAN (Controller Area Network) — это промышленный стандарт, позволяющий осуществить объединение в единую сеть различных узлов, механизмов, датчиков и т. п. Протокол является широковещательным, это значит, что все устройства в CAN-сети принимают все передаваемые по шине сигналы. Режим передачи данных — последовательный, при этом байты сообщений формируют кадры определенного вида. Структуру этих кадров данных мы также обязательно разберем в этой статье.

Основные характеристики протокола CAN:

• очень высокая надежность и защищенность
• каждое сообщение имеет свой собственный приоритет
• реализован механизм обнаружения ошибок
• автоматическая повторная отправка сообщений, которые были доставлены с ошибкой
• уже упомянутый широковещательный характер передачи данных
• возможность присутствия нескольких ведущих (master) устройств в одной сети
• широкий диапазон скоростей работы
• высокая устойчивость интерфейса к помехам
• кроме того, есть механизм обнаружения «сбойных» узлов с последующим удалением таких узлов из сети.

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

Давайте перейдем к физическому уровню протокола. В интернете можно найти много противоречивой информации на этот счет, но истина тут одна ) Стандарт CAN компании Bosch не регламентирует физический уровень передачи данных, поэтому могут использоваться абсолютно разные варианты, например, оптоволокно. На практике же чаще всего используется соединение посредством двухпроводной дифференциальной линии (витой пары). Ориентировочная максимальная длина линии для разных скоростей передачи данных составляет:

Скорость	Длина линии
1 Мбит/с	50 м
500 кбит/с	100 м
125 кбит/с	500 м
10 кбит/с	5 км

Важным условием работоспособности шины является наличие на концах витой пары согласующих резисторов, которые также называют терминаторами, с сопротивлением 120 Ом:

В отличие от многих других протоколов в CAN не рекомендуется описание битов данных как «логического нуля» и «логической единицы». Здесь используются понятия доминантный и рецессивный бит.

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

Вспоминаем про важнейшее свойство передачи данных в сети. Пусть один узел выставляет на линии рецессивный бит, то есть «темноту». Второй узел, напротив, выставляет доминантный бит — «свет». В итоге на линии будет «свет», то есть доминантный бит, что в точности соответствует требованиям сети:

При использовании электрического сигнала устройство, желающее передать в линию доминантный бит, может подтянуть линию к земле. Это и приведет к тому, что на линии будет доминантный бит независимо от того, что выдают на линию другие участники коммуникации.

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

Продолжается это до того момента, когда значения станут различными. Если несколько устройств хотят передать рецессивный бит, а одно — доминантный, то в соответствии с правилом, которое мы обсудили выше, на линии окажется доминантный бит. В таком случае отправленные и считанные значения для устройств, пытающихся выдать на линию рецессивное состояние, не совпадут. В этом случае они должны прекратить передачу. А тот узел, который в этот момент передавал доминантный бит, продолжит свою работу. Доминирование в чистом виде )

Сигналы, которые передаются по витой паре, получили название CAN_H и CAN_L (High и Low). Доминантное состояние соответствует случаю, когда потенциал сигнала CAN_H выше потенциала CAN_L. Рецессивное — когда потенциалы равны (разница потенциалов не превышает допустимого отклонения, 0.5 В).

С этим вроде бы разобрались, давайте двигаться дальше! Пришло время определить, как биты объединяются в кадры. Протокол CAN определяет 4 вида кадров:

• Кадр данных (data frame)
• Кадр удаленного запроса (remote frame)
• Кадр перегрузки (overload frame)
• Кадр ошибки (error frame)

Для кадра данных возможны два варианта — базовый формат и расширенный. Вот так выглядит структура базового формата:

Поле	Длина	Описание
Начало кадра (SOF)	1 бит	Начало передачи кадра
Идентификатор (ID)	11 бит	Идентификатор сообщения
Запрос на передачу (RTR)	1 бит	Доминантный бит
Бит расширения идентификатора (IDE)	1 бит	Бит определяет длину идентификатора, для базового формата — доминантный бит
Зарезервированный бит	1 бит	Зарезервировано
Длина данных (DLC)	4 бита	Количество байт данных
Данные	0 — 8 байт	Данные
Контрольная сумма (CRC)	15 бит	Контрольная сумма
Разграничитель контрольной суммы	1 бит	Рецессивный бит
Промежуток подтверждения (ACK)	1 бит	Для приемника — доминантный бит, для передатчика — рецессивный
Разграничитель подтверждения	1 бит	Рецессивный бит
Конец кадра (EOF)	7 бит	Все биты рецессивные

А это структура расширенного:

Поле	Длина	Описание
Начало кадра (SOF)	1 бит	Начало передачи кадра
Идентификатор A (ID A)	11 бит	Первая часть идентификатора
Подмена запроса на передачу (SRR)	1 бит	Рецессивный бит
Бит расширения идентификатора (IDE)	1 бит	Бит определяет длину идентификатора, для расширенного формата — рецессивный бит
Идентификатор B (ID B)	18 бит	Вторая часть идентификатора
Запрос на передачу (RTR)	1 бит	Доминантный бит
Зарезервированные биты	2 бита	Зарезервировано
Длина данных (DLC)	4 бита	Количество байт данных
Данные	0 — 8 байт	Данные
Контрольная сумма (CRC)	15 бит	Контрольная сумма
Разграничитель контрольной суммы	1 бит	Рецессивный бит
Промежуток подтверждения (ACK)	1 бит	Для приемника — доминантный бит, для передатчика — рецессивный
Разграничитель подтверждения	1 бит	Рецессивный бит
Конец кадра (EOF)	7 бит	Все биты рецессивные

Результирующий идентификатор получается в результате объединения полей «Идентификатор A» и «Идентификатор B«.

Кадр удаленного запроса (remote frame) представляет из себя кадр данных, описанный выше, но без поля данных и с рецессивным битом RTR. Он используется в случае, когда один узел хочет запросить данные у другого узла.

Кадр ошибки (error frame) передает устройство, обнаружившее ошибку в сети. Фрейм ошибки имеет наивысший приоритет и принимается всеми устройствами сети в обязательном порядке.

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

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

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

Итак, что у нас на очереди теперь? Конечно же контроль ошибок — важнейший аспект работы протокола CAN. Стандарт предусматривает несколько механизмов:

• Во-первых, это контроль передачи битов — уровень сигнала в сети сравнивается с передаваемым для каждого бита.
• Второй механизм заключается в использовании дополнительных битов (stuffing bit). После передачи любых пяти одинаковых битов автоматически добавляется передача бита противоположного значения. Таким образом, при передаче шести одинаковых битов диагностируется ошибка stuffing’а. Этот механизм используется для кодирования всех полей фреймов данных и запроса. Исключением являются только поля промежутка подтверждения, разграничителя контрольной суммы и EOF.
• Стандартная процедура проверки контрольной суммы. Передатчик вычисляет контрольную сумму для текущего кадра и передает ее в линию. В свою очередь, приемник также вычисляет контрольную сумму для принимаемых данных и сравнивает ее с тем значением, которое было отправлено передатчиком. В случае не совпадения значений диагностируется ошибка CRC.
• Также выполняется контроль битов фрейма, которые должны иметь заранее определенное значение. В случае, если реальное значение не совпадает с тем, которое ожидается, возникает ошибка.

Благодаря всем этим механизмам, вероятность необнаружения ошибки является очень низкой, что, конечно же, не может не радовать 👍

Кроме того, если один из узлов обнаружил ошибку в сообщении, он сообщает об этом в сеть CAN при помощи фрейма ошибки. А поскольку сеть у нас широковещательная, то о возникновении ошибки становится известно всем участникам коммуникации. И если в сообщении была обнаружена ошибка, его передача будет осуществлена еще раз.

И на этом еще не все! Каждый узел может находиться в одном из трех состояний:

• Error Active
• Error Passive
• Bus Off

Протокол CAN предусматривает, что изначально, после старта, узел находится в первом из этих состояний — Error Active. Каждое устройство имеет два счетчика ошибок:

• Счетчик ошибок передачи
• Счетчик ошибок приема

Существуют определенные правила обслуживания этих счетчиков, которые сводятся к следующему. Передатчик, обнаруживший ошибку, увеличивает свой счетчик ошибок передачи быстрее, чем приемники увеличивают свои счетчики ошибок приема. Это связано с предположением, что при ошибке, вероятность того, что сбой произошел именно в передатчике, а не в приемнике, достаточно велика. На практике ошибка передачи увеличивает соответствующий счетчик на 8, а ошибка приема лишь на 1. При приеме или передаче корректного сообщения как счетчик ошибок передачи, так и счетчики ошибок приема уменьшаются на 1.

Если значение любого из этих двух счетчиков узла превысит значение 127, то узел переходит в состояние Error Passive. А если величина одного из счетчиков превысит 255, то узел перейдет в состояние Bus Off.

Разница между этими состояниями заключается в действиях узла при диагностировании ошибки:

• Узел в состоянии Error Active при обнаружении ошибки передает в шину Active Error Flags — 6 доминантных бит. Поскольку биты доминантные, то это сообщение нарушает обычную работу шины и поэтому все устройства сети также фиксируют возникновение ошибки.
• Узел в состоянии Error Passive при обнаружении ошибки передает в шину Passive Error Flags — 6 рецессивных бит, которые игнорируются всеми другими участниками обмена. Поэтому увеличивается только величина счетчика ошибок одного конкретного узла.
• И, наконец, узел в состоянии Bus Off ничего не передает в сеть — ни фреймы ошибок, ни фреймы данных, ни какие-либо другие.

Как видите, протокол CAN крайне интересен для изучения, надежен, безопасен, и удобен в использовании. И на этой позитивной ноте на сегодня заканчиваем, скоро займемся практической реализацией протокола, также поговорим о микросхемах и устройствах, обеспечивающих работу с CAN. Так что подписывайтесь на обновления, буду рад снова видеть вас на нашем сайте 🤝

Вернуться к статьям

По материалам компании Kvaser

Эта статья не претендует на полноту и абсолютную точность сведений, указанных в ней, и предназначена для ознакомления с протоколом CAN.

Содержание статьи

• Шина CAN – Введение.

• Сообщения CAN.

• Физические уровни CAN.

• Разъемы CAN.

• Тактовая синхронизация CAN.

• Обработка ошибок CAN.

Шина CAN – Введение

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

Стандарт CAN состоит из физического уровня и уровня передачи данных, определяющего несколько различных типов сообщений, правила разрешения конфликтов при доступе к шине и защиту от сбоев.

Протокол CAN

Протокол CAN описан в стандарте ISO 11898–1 и может быть кратко охарактеризован следующим образом:

• физический уровень использует дифференциальную передачу данных по витой паре;

• для управления доступом к шине используется неразрушающее bit–wise разрешение конфликтов;

• сообщения имеют малые размеры (по большей части 8 байт данных) и защищены контрольной суммой;

• в сообщениях отсутствуют явные адреса, вместо этого каждое сообщение содержит числовое значение, которое управляет его очередностью на шине, а также может служить идентификатором содержимого сообщения;

• продуманная схема обработки ошибок, обеспечивающая повторную передачу сообщений, если они не были получены должным образом;
• имеются эффективные средства для изоляции сбоев и удаления сбойных узлов с шины.

Протоколы более высоких уровней

Сам по себе протокол CAN определяет всего лишь, как малые пакеты данных можно безопасно переместить из точки A в точку B посредством коммуникационной среды. Он, как и следовало ожидать, ничего не говорит о том, как управлять потоком; передавать большое количество данных, нежели помещается в 8–байтное сообщение; ни об адресах узлов; установлении соединения и т.п. Эти пункты определяются протоколом более высокого уровня (Higher Layer Protocol, HLP). Термин HLP происходит из модели OSI и её семи уровней.

Протоколы более высокого уровня используются для:

• стандартизации процедуры запуска, включая выбор скорости передачи данных;

• распределения адресов среди взаимодействующих узлов или типов сообщений;

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

Пользовательские группы и т.п.

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

• Пользовательские группы и прочее из области CAN >>

Продукты CAN

На низком уровне принципиально различают два типа продуктов CAN, доступных на открытом рынке – микросхемы CAN и инструменты разработки CAN. На более высоком уровне – другие два типа продуктов: модули CAN и инструменты проектирования CAN. Широкий спектр данных продуктов доступен на открытом рынке в настоящее время.

• Ознакомьтесь с нашим перечнем продуктов CAN >>

Патенты в области CAN

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

Системы распределённого управления

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

Систему распределённого управления можно описать как систему, вычислительная мощность которой распределена между всеми узлами системы. Противоположный вариант – система с центральным процессором и локальными точками ввода–вывода.

Сообщения CAN

Шина CAN относится к широковещательным шинам. Это означает, что все узлы могут «слушать» все передачи. Не существует возможности послать сообщение конкретному узлу, все без исключения узлы будут принимать все сообщения. Оборудование CAN, однако, обеспечивает возможность локальной фильтрации, так что каждый модуль может реагировать только на интересующее его сообщение.

Адресация сообщений CAN

CAN использует относительно короткие сообщения – максимальная длина информационного поля составляет 94 бита. В сообщениях отсутствует явный адрес, их можно назвать контентно–адрессованными: содержимое сообщения имплицитно (неявным образом) определяет адресата.

Типы сообщений

Существует 4 типа сообщений (или кадров), передающихся по шине CAN:

• кадр данных (Data Frame);

• удаленный кадр (Remote Frame);

• кадр ошибки (Error Frame);

• кадр перегрузки (Overload Frame).

Кадр данных

Кратко: «Всем привет, есть данные с маркировкой X, надеюсь вам понравятся!»
Кадр данных – самый распространенный тип сообщения. Он содержит в себе следующие основные части (некоторые детали не рассматриваются для краткости):

• Поле арбитража (Arbitration Field), которое определяет очередность сообщения в том случае, когда за шину борятся два или более узла. Поле арбитража содержит:

• В случае CAN 2.0A, 11–битный идентификатор и один бит, бит RTR который является определяющим для кадров данных.

• В случае CAN 2.0B, 29–битный идентификатор (который также содержит два рецессивных бита: SRR и IDE) и бит RTR.

• Поле данных (Data Field), которое содержит от 0 до 8 байт данных.

• Поле CRC (CRC Field), содержащее 15–битную контрольную сумму, посчитанную для большинства частей сообщения. Эта контрольная сумма используется для обнаружения ошибок.

• Слот распознавания (Acknowledgement Slot). Каждый контроллер CAN, способный корректно получить сообщение, посылает бит распознавания (Acknowledgement bit) в конце каждого сообщения. Приемопередатчик проверяет наличие бита распознавания и, если таковой не обнаруживается, высылает сообщение повторно.

Примечание 1: Присутствие на шине бита распознавания не значит ничего, кроме того, что каждый запланированный адресат получил сообщение. Единственное, что становится известно, это факт корректного получения сообщения одним или несколькими узлами шины.

Примечание 2: Идентификатор в поле арбитража, несмотря на свое название, необязательно идентифицирует содержимое сообщения.

Кадр данных CAN 2.0B («cтандартный CAN»).

Кадр данных CAN 2.0B («расширенный CAN»).

Удаленный кадр

Кратко: «Всем привет, кто–нибудь может произвести данные с маркировкой X?»
Удаленный кадр очень похож на кадр данных, но с двумя важными отличиями:

• он явно помечен как удаленный кадр (бит RTR в поле арбитража является рецессивным), и

• отсутствует поле данных.

Основной задачей удаленного кадра является запрос на передачу надлежащего кадра данных. Если, скажем, узел A пересылает удаленный кадр с параметром поля арбитража равным 234, то узел B, если он должным образом инициализирован, должен выслать в ответ кадр данных с параметром поля арбитража также равным 234.

Удаленные кадры можно использовать для реализации управления трафиком шины типа «запрос–ответ». На практике, однако, удаленный кадр используется мало. Это не так важно, поскольку стандарт CAN не предписывает действовать именно так, как здесь обозначено. Большинство контроллеров CAN можно запрограммировать так, что они будут автоматически отвечать на удаленный кадр, или же вместо этого извещать локальный процессор.

Есть одна уловка, связанная с удаленным кадром: код длины данных (Data Length Code) должен быть установлен длине ожидаемого ответного сообщения. В противном случае разрешение конфликтов работать не будет.

Иногда требуется чтобы узел, отвечающий на удаленный кадр, начинал свою передачу как только распознавал идентификатор, таким образом «заполняя» пустой удаленный кадр. Это другой случай.

Кадр ошибки (Error Frame)

Кратко (все вместе, громко): «О, ДОРОГОЙ, ДАВАЙ ПОПРОБУЕМ ЕЩЁ РАЗОК»
Кадр ошибки (Error Frame) – это специальное сообщение, нарушающее правила формирования кадров сообщения CAN. Он посылается, когда узел обнаруживает сбой и помогает остальным узлам обнаружить сбой – и они тоже будут отправлять кадры ошибок. Передатчик автоматически попробует послать сообщение повторно. Наличествует продуманная схема счетчиков ошибок, гарантирующая, что узел не сможет нарушить передачу данных по шине путём повторяющейся отсылки кадров ошибки.

Кадр ошибки содержит флаг ошибки (Error Flag), который состоит из 6 бит одинакового значения (таким образом нарушая правило вставки битов) и разграничителя ошибки (Error Delimiter), состоящего из 8 рецессивных бит. Разраничитель ошибки предоставляет некоторое пространство, в котором другие узлы шины могут отправлять свои флаги ошибки после того, как сами обнаружат первый флаг ошибки.

Вот флаг ошибки:

Кадр перегрузки (Overload Frame)

Кратко: «Я очень занятой 82526 маленький, не могли бы вы подождать минуточку?»
Кадр перегрузки упоминается здесь лишь для полноты картины. По формату он очень похож на кадр ошибки и передается занятым узлом. Кадр перегрузки используется нечасто, т.к. современные контроллеры CAN достаточно производительны, чтобы его не использовать. Фактически, единственный контроллер, который будет генерировать кадры перегрузки – это ныне устаревший 82526.

Стандартный и расширенный CAN

Изначально стандарт CAN установил длину идентификатора в поле арбитража равной 11 битам. Позже, по требованию покупателей стандарт был расширен. Новый формат часто называют расширенным CAN (Extended CAN), он позволяет использовать не менее 29 бит в идентификаторе. Для различения двух типов кадров используется зарезервированный бит в поле управления Control Field.

Формально стандарты именуются следующим образом –

• 2.0A – только с 11–битными идентификаторами;
• 2.0B – расширенная версия с 29–битными или 11–битными идентификаторами (их можно смешивать). Узел 2.0B может быть

• 2.0B active (активным), т.е. способным передавать и получать расширенные кадры, или

• 2.0B passive (пассивным), т.е. он будет молча сбрасывать полученные расширенные кадры (но, смотрите ниже).

• 1.x – относится к оргинальной спецификации и её ревизиям.

В настоящее время новые контроллеры CAN обычно относятся к типу 2.0B. Контроллер типа 1.x или 2.0A прибудет в замешательство, получив сообщения с 29 битами арбитража. Контроллер 2.0B пассивного типа примет их, опознает, если они верны и, затем – сбросит; a контроллер 2.0B активного типа сможет и передавать, и получать такие сообщения.

Контроллеры 2.0B и 2.0A (равно, как и 1.x) совместимы. Можно использовать их все на одной шине до тех пор, пока контроллеры 2.0B будут воздерживаться от рассылки расширенных кадров.

Иногда люди заявляют, что стандартный CAN «лучше» расширенного CAN, потому что в сообщениях расширенного CAN больше служебных данных. Это необязательно так. Если вы используете поле арбитража для передачи данных, то кадр расширенного CAN может содержать меньше служебных данных, чем кадр стандартного CAN.

Основной CAN (Basic CAN) и полный CAN (Full CAN)

Термины Basic CAN и Full CAN берут начало в «детстве» CAN. Когда–то существовал CAN–контроллер Intel 82526, предоставлявший программисту интерфейс в стиле DPRAM. Потом появился Philips с моделью 82C200, в котором применялась FIFO–ориентированная модель программирования и ограниченные возможности фильтрации. Для обозначения различия между двумя моделями программирования, люди стали называть способ Intel – Full CAN, а способ Philips – Basic CAN. Сегодня большинство контроллеров CAN поддерживают обе модели программирования, поэтому нет смысла в использовании терминов Full CAN и Basic CAN – фактически, эти термины могут вызвать неразбериху и стоит воздержаться от их употребления.

В действительности, контроллер Full CAN может взаимодействовать с контроллером Basic CAN и наоборот. Проблемы с совместимостью отсутствуют.

Разрешение конфликтов на шине и приоритет сообщения

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

Любой контроллер CAN может начать передачу, когда обнаружит, что шина простаивает. Это может привести к тому, что два или более контроллеров начнут передачу сообщения (почти) одновременно. Конфликт решается следующим образом. Передающие узлы осуществляют мониторинг шины в процессе отправки сообщения. Если узел обнаруживает доминантный уровень в то время, как сам он отправляет рецессивный уровень, он незамедлительно устранится от процесса разрешения конфликта и станет приемником. Разрешение конфликтов осуществляется по всему полю арбитража, и после того, как это поле отсылается, на шине остается только один передатчик. Данный узел продолжит передачу, если ничего не случится. Остальные потенциальные передатчики попытаются передать свои сообщения позже, когда шина освободится. В процессе разрешения конфликта время не теряется.

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

Поскольку, CAN–шина является шиной с подсоединением устройств по типу «монтажное И» (wired–AND) и доминантный бит (Dominant bit) является логическим 0, следовательно сообщение с самым низким в численном выражении полем арбитража выиграет в разрешении конфликта.

Вопрос: Что произойдет в случае, если единственный узел шины попытается отослать сообщение?

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

Адресация и идентификация сообщения

Повторимся, нет ничего страшного в том, что в сообщениях CAN нет точных адресов. Каждый контроллер CAN будет получать весь траффик шины, и при помощи комбинации аппаратных фильтров и ПО, определять – «интересует» его это сообщение, или нет.

Фактически, в протоколе CAN отсутствует понятие адреса сообщения. Вместо этого содержимое сообщения определяется идентификатором, который находится где–то в сообщении. Сообщения CAN можно назвать «контентно–адрессовнными».

Определённый адрес работает так: «Это сообщение для узла X». Контентно–адресованное сообщение можно описать так: «Это сообщение содержит данные с маркировкой X». Разница между этими двумя концепциями мала, но существенна.

Содержимое поле арбитража используется, в соответствии со стандартом, для определения очередности сообщения на шине. Все контроллеры CAN будут также использовать всё (некоторые – только часть) поле арбитража в качестве ключа в процессе аппаратной фильтрации.

Стандарт не говорит, что поле арбитража непременно должно использоваться в качестве идентификатора сообщения. Тем не менее, это очень распространенный вариант использования.

Примечание о значениях идентификатора

Мы говорили, что идентификатору доступны 11 (CAN 2.0A) или 29 (CAN 2.0B) бит. Это не совсем верно. Для совместимости с определенным старым контроллером CAN (угадайте каким?), идентификаторы не должны иметь 7 старших бит установленных в логическую единицу, поэтому 11–битным идентификаторам доступны значения 0..2031, а пользователи 29–битных идентификаторов могут использовать 532676608 различных значений.

Заметьте, что все остальные контроллеры CAN принимают «неправильные» идентификаторы, поэтому в современных системах CAN идентификаторы 2032..2047 могут использоваться без ограничений.

Физические уровни CAN

Шина CAN

Шина CAN использует код без возвращения к нулю (NRZ) с вставкой битов. Существуют два разных состояния сигнала: доминантное (логический 0) и рецессивное (логическая 1). Они соответствуют определенным электрическим уровням, зависящим от используемого физического уровня (их несколько). Модули подключены к шине по схеме «монтажное И» (wired–AND): если хотя бы один узел переводит шину в доминантное состояние, то вся шина находится в этом состоянии, вне зависмости от того, сколько узлов передают рецессивное состояние.

Различные физические уровни

Физический уровень определяет электрические уровни и схему передачи сигналов по шине, полное сопротивление кабеля и т.п.

Существует несколько различных версий физических уровней: • Наиболее распространенным является вариант, определенный стандартом CAN, часть ISO 11898–2, и представляющий собой двухпроводную сбалансированную сигнальную схему. Он также иногда называется high–speed CAN.

• Другая часть того же стандарта ISO 11898–3 описывает другую двухпроводную сбалансированную сигнальную схему – для менее скоростной шины. Она устойчива к сбоям, поэтому передача сигналов может продолжаться даже в том случае, когда один из проводов будет перерезан, замкнут на «землю» или в состоянии Vbat. Иногда такая схема называется low–speed CAN.

• SAE J2411 описывает однопроводной (плюс «земля», разумеется) физический уровень. Он используется в основном в автомобилях – например GM–LAN.

• Существуют несколько проприетарных физических уровней.

• В былые времена, когда драйверов CAN не существовало, использовались модификации RS485.

• Несколько изображений с осциллографа поясняющие сообщения в деталях >>.

Различные физические уровни как правило не могут взаимодействовать между собой. Некоторые комбинации могут работать (или будет казаться, что они работают) в хороших условиях. Например, приемопередатчики high–speed и low–speed могут работать на одной шине лишь иногда.

Абсолютное большинство микросхем приемопередатчиков CAN произведено компанией Philips; в число других производителей входят Bosch, Infineon, Siliconix и Unitrode.

Наиболее распространен приемопередатчик 82C250, в котором реализован физический уровень, описываемый стандартом ISO 11898. Усовершенствованная версия – 82C251.

Распространенный приемопередатчик для «low–speed CAN» – Philips TJA1054.

Максимальная скорость передачи данных по шине

Максимальная скорость передачи данных по шине CAN, в соответствии со стандартом, равна 1 Мбит/с. Однако некоторые контроллеры CAN поддерживают скорости выше 1 Мбит/с и могут быть использованы в специализированных приложениях.

Low–speed CAN (ISO 11898–3, см. выше) работает на скоростях до 125 кбит/с.

Однопроводная шина CAN в стандартном режиме может передавать данные со скоростью порядка 50 кбит/с, а в специальном высокоскоростном режиме, например для программирования ЭБУ (ECU), около 100 кбит/с.

Минимальная скорость передачи данных по шине

Имейте в виду, что некоторые приемопередатчики не позволят вам выбрать скорость ниже определенного значения. Например, при использовании 82C250 или 82C251 вы можете без проблем установить скорость 10 кбит/с, но если вы используете TJA1050, то не сможете установить скорость ниже 50 кбит/с. Сверяйтесь со спецификацией.

Максимальная длина кабеля

При скорости передачи данных 1 Мбит/с, максимальная длина используемого кабеля может составлять порядка 40 метров. Это связано с требованием схемы разрешения конфликтов, согласно которому фронт волны сигнала должен иметь возможность дойти до самого дальнего узла и вернуться назад прежде чем бит будет считан. Иными словами, длина кабеля ограничена скоростью света. Предложения по увеличению скорости света рассматривались, но были отвергнуты в связи с межгалактическими проблемами.

Другие максимальные длины кабеля (значения приблизительные):

• 100 метров при 500 кбит/с;

• 200 метров при 250 кбит/с;

• 500 метров при 125 кбит/с;
• 6 километров при 10 кбит/с.

Если для обеспечения гальванической изоляции используются оптопары, максимальная длина шины соответственно сокращается. Совет: используйте быстрые оптопары, и смотрите на задержку сигнала в устройстве, а не на максимальную скорость передачи данных в спецификации.

Оконечное прерывание шины

Шина CAN стандарта ISO 11898 должна заканчиваться терминатором. Это достигается путем установки резистора сопротивлением 120 Ом на каждом конце шины. Терминирование служит двум целям:

1. Убрать отражения сигнала на конце шины.

2. Убедиться, что получает корректные уровни постоянного тока (DC).

Шина CAN стандарта ISO 11898 обязательно должна терминироваться вне зависимости от её скорости. Я повторю: шина CAN стандарта ISO 11898 обязательно должна терминироваться вне зависимости от её скорости. Для лабораторной работы может хватить и одного терминатора. Если ваша шина CAN работает даже при отсутствии терминаторов – вы просто счастливчик.

Заметьте, что другие физические уровни, такие как low–speed CAN, однопроводная шина CAN и другие, могут требовать, а могут и не требовать наличия оконечного терминатора шины. Но ваша высокоскоростная шина CAN стандарта ISO 11898 всегда будет требовать наличия хотя бы одного терминатора.

Кабель

Стандарт ISO 11898 предписывает, что волновое сопротивление кабеля номинально должно равнятся 120 Ом, однако допускается интервал значений сопротивления [108..132] Ом.

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

ISO 11898 описывает витую пару, экранированную или неэкранированную. Идёт работа над стандартом однопроводного кабеля SAE J2411.

Продолжение статьи читать во II части .

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

Каждый узел состоит из двух составляющих. Это собственно CAN контроллер, который обеспечивает взаимодействие с сетью и реализует протокол, и микропроцессор (CPU).

Рис. 1. Топология сети CAN.

CAN контроллеры соединяются с помощью дифференциальной шины, которая имеет две линии — CAN_H (can-high) и CAN_L (can-low), по которым передаются сигналы. Логический ноль регистрируется, когда на линии CAN_H сигнал выше, чем на линии CAN_L. Логическая единица — в случае когда сигналы CAN_H и CAN_L одинаковы (отличаются менее чем на 0.5 В). Использование такой дифференциальной схемы передачи делает возможным работу CAN сети в очень сложных внешних условиях. Логический ноль — называется доминантным битом, а логическая единица — рецессивным. Эти названия отражают приоритет логической единицы и нуля на шине CAN. При одновременной передаче в шину лог. нуля и единицы, на шине будет зарегестрирован только логический ноль (доминантный сигнал), а логическая единица будет подавлена (рецессивный сигнал).

Типы сообщений сети CAN.

Данные в CAN передаются короткими сообщениями-кадрами стандартного формата. В CAN существуют четыре типа сообщений:

• Data Frame
• Remote Frame
• Error Frame
• Overload Frame

Data Frame — это наиболее часто используемый тип сообщения. Он состоит из следующих основных частей:

• поле арбитража (arbitration field) определяет приоритет сообщения в случае, когда два или более узлов одновременно пытаются передать данные в сеть. Поле арбитража состоит в свою очередь из:
  • для стандарта CAN-2.0A, 11-битного идентификатора + 1 бит RTR (retransmit)
  • для стандарта CAN-2.0B, 29-битного идентификатора + 1 бит RTR (retransmit)

  Следует отметить, что поле идентификатора, несмотря на свое название никак не идентифицирует само по себе ни узел в сети, ни содержимое поля данных. Для Data кадра бит RTR всегда выставлен в логический ноль (доминантный сигнал).

• поле данных (data field) содержит от 0 до 8 байт данных
• поле CRC (CRC field) содержит 15-битную контрольную сумму сообщения, которая используется для обнаружения ошибок
• слот подтверждения (Acknowledgement Slot) (1 бит), каждый CAN-контроллер, который правильно принял сообщение посылает бит подтверждения в сеть. Узел, который послал сообщение слушает этот бит, и в случае если подтверждение не пришло, повторяет передачу. В случае приема слота подтверждения передающий узел может быть уверен лишь в том, что хотя бы один из узлов в сети правльно принял его сообщение.

Рис. 2. Data frame стандарта CAN 2.0A.

Remote Frame — это Data Frame без поля данных и с выставленным битом RTR (1 — рецессивные бит). Основное предназначение Remote кадра — это инициация одним из узлов сети передачи в сеть данных другим узлом. Такая схема позволяет уменьшить суммарный трафик сети. Однако, на практике Remote Frame сейчас используется редко (например, в DeviceNet Remote Frame вовсе не используется).

Error Frame — это сообщение которое явно нарушает формат солобщения CAN. Передача такого сообщения приводит к тому, что все узлы сети регистрируют ошибку формата CAN-кадра, и в свою очередь автоматически передают в сеть Error Frame. Результатом этого процесса является автоматическая повторная передача данных в сеть передающим узлом. Error Frame состоит из поля Error Flag, которое состоит из 6 бит одинакового значения (и таким образом Error frame нарушает проверку Bit Stuffing, см. ниже), и поля Error Delimiter, состоящее из 8 рецессивных битов. Error Delimiter дает возможность другим узлам сети обнаружив Error Frame послать в сеть свой Error Flag.

Overload Frame — повторяет структуру и логику работы Error кадра, с той разницей, что он используется перегруженным узлом, который в данный момент не может обработать поступающее сообщение, и поэтому просит при помощи Overload-кадра о повторной передаче данных. В настоящее время Overload-кадр практически не используется.

Контроль доступа к среде передачи (побитовый арбитраж).

Поле арбитража CAN-кадра используется в CAN для разрешения коллизий доступа к шине методом не деструктивного арбитража. Суть метода не деструктивного арбитража заключается в следующем. В случае, когда несколько контроллеров начинают одновременную передачу CAN кадра в сеть, каждый из них сравнивает, бит, который собирается передать на шину с битом, который пытается передать на шину конкурирующий контроллер. Если значения этих битов равны, оба контроллера передают следующий бит. И так происходит до тех пор, пока значения передаваемых битов не окажутся различными. Теперь контроллер, который передавал логический ноль (более приоритетный сигнал) будет продолжать передачу, а другой (другие) контроллер прервёт свою передачу до того времени, пока шина вновь не освободится. Конечно, если шина в данный момент занята, то контроллер не начнет передачу до момента её освобождения.

Рис. 3. Побитовый арбитраж на шине CAN.

Методы обнаружения ошибок.

CAN протокол определяет пять способов обнаружения ошибок в сети:

• Bit monitoring
• Bit stuffing
• Frame check
• ACKnowledgement Check
• CRC Check

Bit monitoring — каждый узел во время передачи битов в сеть сравнивает значение передаваемого им бита со значением бита которое появляется на шине. Если эти значения не совпадают, то узел генерирует ошибку Bit Error. Естественно, что во время арбитража на шине (передача поля арбитража в шину) этот механизм проверки ошибок отключается.

Bit stuffing — когда узел передает последовательно в шину 5 бит с одинаковым значением, то он добавляет шестой бит с противоположным значением. Принимающие узлы этот дополнительный бит удаляют. Если узел обнаруживает на шине больше 5 последовательных бит с одинаковым значением, то он генерирует ошибку Stuff Error.

Frame Check — некоторые части CAN-сообщения имеют одинаковое значение во всех типах сообщений. Т.е. протокол CAN точно определяет какие уровни напряжения и когда должны появляться на шине. Если формат сообщений нарушается, то узлы генерируют ошибку Form Error.

ACKnowledgement Check — каждый узел получив правильное сообщение по сети посылает в сеть доминантный (0) бит. Если же этого не происходит, то передающий узел регистрирует ошибку Acknowledgement Error.

CRC Check — каждое сообщение CAN содержит CRC сумму, и каждый принимающий узел подсчитывает значение CRC для каждого полученного сообщения. Если подсчитанное значение CRC суммы, не совпадает со значением CRC в теле сообщения, принимающий узел генерирует ошибку CRC Error.

Механизм ограничения ошибок (Error confinement).

Каждый узел сети CAN, во время работы пытается обнаружить одну из пяти возможных ошибок. Если ошибка обнаружена, узел передает в сеть Error Frame, разрушая тем самым весь текущий трафик сети (передачу и прием текущего сообщения). Все остальные узлы обнаруживают Error Frame и принимают соответствующие действия (сбрасывают принятое сообщение). Кроме того, каждый узел ведет два счетчика ошибок: Transmit Error Counter (счетчик ошибок передачи) и Receive Error Counter (счетчик ошибок приема). Эти счетчики увеличиваются или уменьшаются в соответствие с несколькими правилами. Сами правила управления счетчиками ошибок достаточно сложны, но сводятся к простому принципу, ошибка передачи приводит к увеличению Transmit Error счетчика на 8, ошибка приема увеличивает счетчик Receive Error на 1, любая корректная передача/прием сообщения уменшают соответствующий счетчик на 1. Эти правила приводят к тому, что счетчик ошибок передачи передающего узла увеличивается быстрее, чем счетчик ошибок приема принимающих узлов. Это правило соответствует предположению о большой вероятности того, что источником ошибок является передающий узел.

Каждый узел CAN сети может находится в одном из трех состояний. Когда узел стартует он находится в состоянии Error Active. Когда, значение хотя бы одного из двух счетчиков ошибок превышает предел 127, узел переходит в состояние Error Passive. Когда значение хотя бы одного из двух счетчиков превышает предел 255, узел переходит в состояние Bus Off.

Узел находящийся в состоянии Error Active в случае обнаружения ошибки на шине передает в сеть Active Error Flags. Active Error Flags сотстоит из 6 доминантных бит, поэтому все узлы его регистрируют. Узел в состоянии Passive Error передает в сеть Passive Error Flags при обнаружении ошибки в сети. Passive Error Flags состоит из 6 рецессивных бит, поэтому остальные узлы сети его не замечают, и Passive Error Flags лишь приводит к увеличению Error счетчика узла. Узел в состоянии Bus Off ничего не передает в сеть (не только Error кадры, но вообще никакие другие).

Адресация и протоколы высокого уровня

В CAN не существует явной адресации сообщений и узлов. Протокол CAN нигде не указывает что поле арбитража (Identification field + RTR) должно использоваться как идентификатор сообщения или узла. Таким образом, идентификаторы сообщений и адреса узлов могут находится в любом поле сообщения (в поле арбитража или в поле данных, или присутствовать и там, и там). Точно также протокол не запрещает использовать поле арбитража для передачи данных.

Утилизация поля арбитража и поля данных, и распределение адресов узлов, идентификаторов сообщений и приоритетов в сети является предметом рассмотрений так называемых протоколов высокого уровня (HLP — Higher Layer Protocols). Название HLP отражает тот факт, что протокол CAN описывает только два нижних уровня эталонной сетевой модели ISO/OSI, а остальные уровни описываются протоколами HLP.

Рис. 4. Логическая структура протокола CAN.

Существует множество таких высокоуровневых протоколов. Наиболее распространенные из них это:

• DeviceNet
• CAL/CANopen
• SDS
• CanKingdom

Физичекий уровень протокола CAN

Физический уровень (Physical Layer) протокола CAN определяет сопротивление кабеля, уровень электрических сигналов в сети и т.п. Существует несколько физических уровней протокола CAN (ISO 11898, ISO 11519, SAE J2411).

В подавляющем большинстве случаев используется физический уровень CAN определенный в стандарте ISO 11898. ISO 11898 в качестве среды передачи определяет двухпроводную дифференциальную линию с импедансом (терминаторы) 120 Ом (допускается колебание импеданса в пределах от 108 Ом до 132 Ом. Физический уровень CAN реализован в специальных чипах — CAN приемо-передатчиках (transceivers), которые преобразуют обычные TTL уровни сигналов используемых CAN-контроллерами в уровни сигналов на шине CAN. Наиболее распространенный CAN приемо-передатчик — Phillips 82C250, который полностью соответствует стандарту ISO 11898.

Махимальная скорость сети CAN в соответствие с протоколом равна 1 Mbit/sec. При скорости в 1 Mbit/sec максимальная длина кабеля равна примерно 40 метрам. Ограничение на длину кабеля связано с конечной скоростью света и механизмом побитового арбитража (во время арбитража все узлы сети должны получать текущий бит передачи одновременно, те сигнал должен успеть распространится по всему кабелю за единичный отсчет времени в сети. Соотношение между скоростью передачи и максимальной длиной кабеля приведено в таблице:

скорость передачи	максимальная длина сети
1000 Кбит/сек	40 метров
500 Кбит/сек	100 метров
250 Кбит/сек	200 метров
125 Кбит/сек	500 метров
10 Кбит/сек	6 километров

Разъемы для сети CAN до сих пор НЕ СТАНДАРТИЗОВАНЫ. Каждый протокол высокого уровня обычно определяет свой тип разъемов для CAN-сети.

CAN— это протокол, ориентированный на
использование в условиях помех. Различные
сообщения, передающиеся по сети, имеют
идентификатор, и каждая станция решает,
основываясь на этом идентификаторе,
получать или нет это сообщение. Этот
идентификатор определен в поле
идентификатораCAN-фрейма.

При этом адрес
приемника устанавливается в самом
приемнике путем настройки входных
фильтров соответствующих микросхем.

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

Микросхемы,
поддерживающие CAN-протокол,
могут иметь одиночный фильтр или
многократные фильтры, в зависимости от
конкретной реализации. Существуют
следующие два типа входных фильтров:

• фиксированные — фильтры,
  которые требуют, чтобы биты соответствовали
  точно один к одному (one-for-one).

• Mask-and-Match(маскируемые) — фильтры, которые
  применяют маску к полю идентификатора,
  прежде чем он сравнивается с приемным
  регист ром кода.

Например, на
рис. 7 регистр маски сконфигурирован
так, что полученные биты 10-6 идентификатора
должны соответствовать битам 10-6 в
приемном регистре кода. В этом примере
биты 10-6 идентификатора должны быть
установлены в 11110, а остальные не имеют
значения. Если биты 10-6 установлены в
11110, то эти сообщения принимаются
независимо от значений битов 5-0.

Управление ошибками

CAN-протокол
обеспечивает механизмы обнаружения
следующих типов ошибок:

• Разрядная ошибка появляется,
  когда передатчик сравнивает уровень
  на шине с уровнем, который должен
  передаваться, и обнаруживает их
  неравенство. При этом обнаружение
  активного бита, когда передается
  пассивный бит, не выдает ошибку в течение
  передачи поля арбитража, поля ACKSlotили флажка пассивной
  ошибки.

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

• Ошибка заполнения появляется,
  когда узел обнаруживает шесть (6)
  последовательных битов одного и того
  же значения. В процессе нормальной
  работы, когда передатчик обнаруживает,
  что он послал пять (5) последовательных
  битов одного и того же значения, он
  заполняет следующий бит противоположным
  значением (это называется заполнением
  бита). Все приемники удаляют заполненные
  биты до вычисления CRC(контрольного кода). Таким образом,
  когда узел обнаруживает шесть (6)
  последовательных битов того же значения,
  возникает ошибка заполнения.

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

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

CANпозволяет минимизировать негативные
последствия наличия дефектного узла в
сети при помощи механизма определения
состояния узла. Узел может быть в одном
из трех состояний ошибки.

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

• Ошибка пассивная фиксируется,
  когда пассивный узел обнаруживает одну
  из упомянутых ошибок,— он передает
  фрейм пассивной ошибки, который состоит
  из шести (6) последовательных пассивных
  битов. Этот фрейм может быть наложен
  на передачу, которая ведется в то же
  самое время, при этом данные из передачи
  не теряются, если другие узлы не
  обнаруживают ошибку.

• Шина выключена — узел на
  шине в выключенном состоянии и не
  откликается на любое воздействие на
  шине. Это логическое отключение от
  сети.

Общий краткий
обзор действий, имеющихся в механизме
минимизации неисправностей, приведен
далее.

Узлы следят,
передают и получают значения счетчиков
ошибок.

Узел начинает
передачу в состоянии активной ошибки
со счетчиками ошибок, равными нулю (0).
Узел в этом состоянии «понимает», что
любая обнаруженная ошибка — не
неисправность.

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

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

Когда и передающий,
и приемный счетчики пассивной ошибки
узла декрементируются ниже определенного
порога, узел еще раз подтверждает
состояние активной ошибки.

Современные автомобили включают в себя несколько десятков разнообразных датчиков. И все эти датчики регулярно обмениваются информацией с другими датчиками/устройствами автомобиля. Причем автомобили с каждым годом становятся все «умнее» и поэтому количество датчиков в них все больше увеличивается. В автомобилях сегодняшнего дня находят широкое применение системы автономного вождения, системы безопасности с автоматически срабатывающими подушками безопасности, системы контроля давления в шинах, круиз-контроль и т.д. В большинстве случаев информация, поступающая от этих датчиков, является критически важной. Например, если сработает датчик столкновения, которому срочно нужно передать сигнал на раскрытие подушек безопасности, а ему это помешают сделать какие-либо сигналы/процессы в электронной системе автомобиля. В этом случае жизнь людей в автомобиле может оказаться под угрозой. Поэтому в автомобилях не используют такие широко распространенные в обычной электронике протоколы передачи данных как UART, SPI или I2C. Вместо них конструкторы автомобилей отдают предпочтение значительно более надежным протоколам передачи данных, таким как LIN, CAN, FlexRay и т.д.

Наибольшее распространение среди этих «надежных» протоколов получил стандарт (протокол) CAN. Этот стандарт широко применяется не только в электронных системах современных автомобилей, но и во многих других промышленных устройства, в которых критически важна надежная передача данных. Достаточно подробную информацию о стандарте CAN можно прочитать в соответствующей статье Википедии. Мы же в данной статье рассмотрим обмен данными между двумя платами Arduino с помощью протокола CAN.

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

CAN-сеть состоит из двух проводников (CAN High и CAN Low) и обеспечивает двунаправленную передачу данных. На практике под CAN-сетью обычно подразумевается сеть топологии «шина» с физическим уровнем в виде дифференциальной пары. Передача ведется кадрами, которые могут принимать все узлы сети. Для доступа к такой шине выпускаются специализированные микросхемы (модули) – драйверы CAN-шины.

Обычно скорость передачи по CAN-шине варьируется от 50 Кбит/с до 1 Мбит/с, а дальность связи лежит в диапазоне от 40 метров (на скорости 1 Мбит/с) до 1000 метров (на скорости 50 Кбит/с).

Формат CAN сообщений

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

Идентификатор (Identifier) – также известен под именами CAN ID и PGN (Parameter Group Number). Он используется для идентификации CAN устройств в CAN-сети. Длина идентификатора составляет 11 или 29 бит в зависимости от того какой тип протокола CAN используется:

• Standard (стандартный) CAN: 0-2047 (11-bit);
• Extended (расширенный) CAN: 0-2²⁹-1 (29-bit).

Data – это данные, которые необходимо передать от одного устройства другому. Длина данных может составлять от 0 до 8 байт.

Data Length Code (DLC) (длина поля данных): может принимать значения от 0 до 8 в зависимости от количества байт для передачи.

Проводники, используемые в CAN

CAN протокол работает по двум проводникам, именуемыми CAN_H и CAN_L, для передачи и приема информации. Оба проводника работают как дифференциальная линия, что означает что CAN сигнал (0 или 1) представляет собой разность потенциалов между CAN_L и CAN_H. Если эта разность положительна и больше определенного минимального уровня напряжения, то это 1, а если эта разность отрицательна – то это 0.

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

Сравнение CAN с SPI и I2C

На нашем сайте мы ранее уже рассматривали использование в платах Arduino протоколов SPI и I2C, поэтому давайте сравним данные протоколы с протоколом CAN.

Параметр	SPI	I2C	CAN
Скорость	3-10 Мбит/с	стандарт: 100 Кбит/с; быстрый: 400 Кбит/с; быстрый: 3,4 Мбит/с;	10 Кбит/с — 1 Мбит/с (зависит от длины используемых проводов)
Тип	синхронный	синхронный	асинхронный
Число проводов	3+ (MISO, MOSI, SCK, SS1, SS2…SS(n))
Дуплекс	полный дуплекс	полудуплекс	полудуплекс

По скорости стандарт CAN не в лидерах, но его главным «козырем» является высокая надежность связи.

Применения CAN протокола

1. В связи с чрезвычайно высокой надежностью и устойчивостью CAN протокола он широко применяется в автомобилях, промышленных механизмах, сельском хозяйстве, медицинском оборудовании и т.д.
2. В связи с небольшим количеством используемых проводников CAN протокол исключительно удобен для применения в автомобилях.
3. Устройства на основе CAN протокола отличаются низкой стоимостью.
4. В CAN-сеть (шину) легко добавлять и удалять новые устройства.

Использование протокола CAN в Arduino

Поскольку платы Arduino не имеют в своем составе встроенного CAN порта, то для реализации связи между ними по данному протоколу мы будем использовать внешние CAN модули MCP2515. Эти модули подключаются к плате Arduino по интерфейсу SPI.

CAN модуль (контроллер шины CAN) MCP2515

Модуль MCP2515 включает в себя CAN контроллер MCP2515, который представляет собой высокоскоростной CAN приемопередатчик. Соединение модуля MCP2515 с микроконтроллером осуществляется с помощью интерфейса SPI, поэтому его легко подключить ко всем микроконтроллерам с данным интерфейсом.

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

Основные технические характеристики модуля MCP2515:

• включает в себя высокоскоростной CAN приемопередатчик TJA1050;
• размеры модуля: 40×28mm;
• управление по интерфейсу SPI с возможностью подключения к CAN-шине нескольких устройств;
• кварцевый генератор на 8 МГц;
• сопротивление на концах 120 Ом;
• включает независимый ключ, светодиодный индикатор, индикатор мощности;
• поддерживает скорости передачи данных до 1 Мбит/с;
• низкий потребляемый ток в режиме ожидания;
• возможность подключения до 112 устройств (узлов).

Назначение контактов (распиновка) CAN модуля MCP2515 представлено в следующей таблице.

Наименование контакта	Назначение контакта
VCC	контакт питания 5 В
GND	общий провод (земля)
CS	SPI SLAVE select pin (Active low) (выбор ведомого)
SO	SPI master input slave output lead
SI	SPI master output slave input lead
SCLK	контакт синхронизации SPI
INT	контакт прерывания MCP2515

В данном проекте мы будем передавать данные, считываемые с датчика температуры и влажности DHT11 платой Arduino Nano, плате Arduino Uno с помощью CAN модуля MCP2515.

Необходимые компоненты

1. Плата Arduino Uno (купить на AliExpress).
2. Плата Arduino Nano (купить на AliExpress).
3. Датчик температуры и влажности DHT11 (купить на AliExpress).
4. ЖК дисплей 16х2 (купить на AliExpress).
5. MCP2515 CAN Module (контроллер шины CAN MCP2515) – 2 шт. (купить на AliExpress).
6. Потенциометр 10 кОм (купить на AliExpress).
7. Макетная плата.
8. Соединительные провода.

Схема проекта

Схема проекта для связи между двумя платами Arduino с помощью протокола CAN и модулей MCP2515 представлена на следующем рисунке.

Соединения на передающей стороне:

Компонент — контакт	Arduino Nano
MPC2515 — VCC	+5V
MPC2515 — GND	GND
MPC2515 — CS	D10 (SPI_SS)
MPC2515 — SO	D12 (SPI_MISO)
MPC2515 — S I	D11 (SPI_MOSI)
MPC2515­ — SCK	D13 (SPI_SCK)
MPC2515 — INT	D2
DHT11 — VCC	+5V
DHT11 — GND	GND
DHT11­ — OUT	A0

Соединения на приемной стороне:

Компонент — контакт	Arduino Uno
MPC2515 — VCC	+5V
MPC2515 — GND	GND
MPC2515 — CS	10 (SPI_SS)
MPC2515 — SO	12 (SPI_MISO)
MPC2515 — SI	11 (SPI_MOSI)
MPC2515 — SCK	13 (SPI_SCK)
MPC2515 — INT	2
LCD (ЖК дисплей) — VSS	GND
LCD — VDD	+5V
LCD — V0	к среднему контакту потенциометра 10 кОм
LCD — RS	3
LCD — RW	GND
LCD — E	4
LCD — D4	5
LCD — D5	6
LCD — D6	7
LCD — D7	8
LCD — A	+5V
LCD — K	GND

Соединения между двумя CAN модулями MCP2515:

H – CAN High
L – CAN Low

MCP2515 (Arduino Nano)	MCP2515 (Arduino UNO)
H	H
L	L

После сборки всей схемы на макетных платах у нас получилась следующая конструкция.

Объяснение программы для Arduino

Первым делом нам необходимо установить библиотеку для работы с протоколом CAN в Arduino IDE. Сначала скачайте ZIP файл библиотеки по следующей ссылке — Arduino CAN MCP2515 Library. Затем установите ее в Arduino IDE с помощью пункта меню Sketch -> Include Library -> Add .ZIP Library.

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

Инициализация CAN модуля MCP2515

Для установления соединения платы Arduino с модулем MCP2515 выполните следующую последовательность шагов. Но перед этим убедитесь в том, что указанная выше библиотека CAN MCP2515 установлена в вашу Arduino IDE.

Шаг 1. Установите номер контакта, к которому подключена линия CS интерфейса SPI (10 по умолчанию).

Шаг 2. Установите скорость передачи и частоту кварцевого генератора.

Доступные скорости передачи:
CAN_5KBPS, CAN_10KBPS, CAN_20KBPS, CAN_31K25BPS, CAN_33KBPS, CAN_40KBPS, CAN_50KBPS, CAN_80KBPS, CAN_83K3BPS, CAN_95KBPS, CAN_100KBPS, CAN_125KBPS, CAN_200KBPS, CAN_250KBPS, CAN_500KBPS, CAN_1000KBPS.

Доступные частоты кварцевого генератора:
MCP_20MHZ, MCP_16MHZ, MCP_8MHZ

Шаг 3. Установите режимы.

Объяснение программы для передающей части (Arduino Nano)

В передающей части к плате Arduino Nano подключен CAN модуль MCP2515 по интерфейсу SPI, а данные температуры и влажности, считываемые с датчика DHT11, передаются далее по CAN-шине.

Первым делом в программе подключим необходимые библиотеки: библиотеку SPI для использования интерфейса SPI, библиотеку MCP2515 для использования связи с помощью протокола CAN и библиотеку DHT для работы с датчиком DHT11. Ранее на нашем сайте мы уже рассматривали подключение датчика DHT11 к плате Arduino.

Дадим название контакту, к которому подключен датчик DHT11 – это контакт A0 платы Arduino Nano.

Также определим DHTTYPE как DHT11.

Определим переменную canMsg типа данных структура для хранения сообщений CAN формата.

Установим номер контакта, к которому подключена линия CS интерфейса SPI (10 по умолчанию).

Также создадим объект dht класса DHT с параметрами DHT pin и DHTTYPE.

В функции void setup():

Инициализируем связь по протоколу SPI.

Начнем считывание данных температуры и влажности с датчика DHT11.

Сбросим в исходное состояние (RESET) модуль MCP2515 с помощью следующей команды:

Установим для модуля MCP2515 скорость передачи 500 кбит/с и частоту кварцевого генератора 8 МГц.

Установим модуль MCP2525 в обычный режим (normal mode).

В функции void loop():

Считаем значения температуры и влажности с датчика DHT11 и сохраним их в переменных целого типа h и t.

Далее установим идентификатору (CAN ID) значение 0x036 (на ваш выбор), DLC (длина поля данных) присвоим значение 8 (8 байт), запишем значения температуры и влажности в поля данных data[0]  и data[1], в остальные поля данных запишем значения 0.

После всего этого передадим сообщение по CAN-шине с помощью команды:

После выполнения этой команды значения температуры и влажности передадутся в виде сообщения по CAN-шине.

Объяснение программы для приемной части (Arduino Uno)

В приемной части нашего проекта к плате Arduino Uno подключены модуль MCP2515 и ЖК дисплей 16х2. Здесь плата Arduino Uno принимает значения температуры и влажности по CAN шине и отображает их на экране ЖК дисплея 16х2.

Первым делом в программе подключим используемые библиотеки: библиотеку SPI для использования интерфейса SPI, библиотеку MCP2515 для использования связи с помощью протокола CAN и библиотеку LiquidCrsytal для работы с ЖК дисплеем 16х2.

Далее сообщим плате Arduino, к каким ее контактам подключен ЖК дисплей 16х2.

Определим переменную canMsg типа данных структура для хранения сообщений CAN формата.

Установим номер контакта, к которому подключена линия CS интерфейса SPI (10 по умолчанию).

В функции void setup ():

Установим ЖК дисплей в режим работы 16×2 и отобразим на его экране приветственное сообщение.

Инициализируем связь по протоколу SPI.

Сбросим в исходное состояние (RESET) модуль MCP2515 с помощью следующей команды:

Установим для модуля MCP2515 скорость передачи 500 кбит/с и частоту кварцевого генератора 8 МГц.

Установим модуль MCP2525 в обычный режим (normal mode).

В функции void loop():

Следующая команда (с использованием оператора условия If) используется для приема сообщения из CAN-шины.

Если записанное условие if выполняется, данные принимаются и сохраняются в переменной canMsg, поле data [0] этой переменной будет содержать значение влажности, а поле data [1] – значение температуры. Мы будем сохранять эти значения в переменных целого типа (integer) x и y.

После успешного приема значений температуры и влажности мы выводим их на экран ЖК дисплея.

Тестирование работы проекта

После того, как аппаратная часть проекта будет готова, загрузите коды программы в платы Arduino в передающей и приемной частях проекта. После этого при подаче питания на схемы вы должны увидеть, как значения температуры и влажности, считанные одной платой Arduino с датчика DHT11, передаются по CAN-шине другой плате Arduino, которая выводит эти принятые значения на экран ЖК дисплея. Мы для проверки правильности значений температуры использовали пульт от кондиционера, с помощью которого устанавливали температуру в комнате.

Исходный код программы (скетча)

Код программы для передающей части (Arduino Nano)

Код программы для приемной части (Arduino Uno)

Видео, демонстрирующее работу проекта

Загрузка…

26 988 просмотров