Структура сети can и как проходит информация по шине

CAN – шина, CAN – интерфейс

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

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

Канальный и физический уровни CAN

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

Структура узла сети CAN

Рассматриваемый нами узел сети CAN состоит из микроконтроллера, CAN контроллера и приемопередатчика (рисунок 1). Чаще всего мы используем микроконтроллеры с встроенным CAN контроллером для упрощения схемы, но иногда используется автономный контроллер CAN с интерфейсом SPI (MCP2510). Далее приемопередатчик подключается к витой паре, на концах которой размещены согласующие резисторы (терминатор) с сопротивлением 120 Ом.

Рисунок 1 – Узел сети CAN

Для формирования логической единицы в витой паре, или свободной шине, на оба провода подается напряжение, равное половине разности напряжения между 0 или Vcc. Логическому нулю соответствует подача на провода линии дифференциального напряжения (рисунок 2).

Рисунок 2 – Логические уровни на CAN-шине

Шина CAN позволяет передавать данные со скоростью 1 Мбит/c при длине кабеля не более 40 м. В обучающей литературе написано, что при снижении скорости передачи до 10кбит/с можно добиться длины сети в 1.5км.

Пакет сообщения CAN

Формат сообщения CAN показан на рисунке 3.

Рисунок 3 – Пакет сообщения CAN

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

Идентификатор (11 – битный )

Или идентификатор (29 – битный)

от 0 до 8 байт данных в пакете

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

Арбитраж на шине CAN

Если без подробностей, то первым по шине CAN всегда передается сообщение с наименьшим идентификатором.

Настройка скорости передачи данных по шине CAN

Скорость передачи данных по CAN шине настраивается за счет формирования квантов времени, а не как во многих других протоколах последовательной передачи данных за счет делителя скорости. В большинстве случаев используются скорости 10Кбит/c, 20Кбит/c, 50Кбит/c, 100Кбит/c, 125Кбит/c, 500Кбит/c, 800Кбит/c, 1MBaud и настройки для этих скоростей уже посчитаны. На рисунке 4 изображено окно выбора скорости в программе PcanView.

Рисунок 4 – Выбор скорости передачи данных в программе PcanView

Как мы видим при установке стандартной скорости настройки проставляются автоматически, но бывают случаи когда необходимо использовать другую скорость передачи данных. Например бортовой CAN автомобиля может работать со скоростью 83Кбит/c. В этом случае придется провести расчет настроек самостоятельно или поискать специализированный калькулятор скорости в интернете. Для самостоятельного расчета скорости необходимо понимать, что для передачи одного бита сообщения используется несколько квантов, а интервал передачи состоит из трех сегментов (рисунок 5).

Рисунок 5 – Время передачи одного бита

Первый сегмент всегда фиксирован и равняется одному кванту. Далее идет два сегмента Tseg1 и Tseg2 и количество квантов в каждом сегменте определяется пользователем и может быть равно от 8 до 25. Точка выборки находится между Tseg1 и Tseg2, т.е. в конце первого и в начале второго сегмента. Так же пользователь может определить ширину скачка синхронизации (Synchronization Jump Width — SJW) для подстройки битовой скорости принимающего устройства, который может быть в диапазоне 1 – 4 квантов времени.

Теперь приведем формулу расчета скорости (Пример расчета скорости для CAN контроллера SJA1000):

BTR = Pclk/(BRP * (1 + Tseg1 + Tseg2))

BTR – скорость передачи данных,

Pclk – частота работы CAN контроллера,

BRP – значение предделителя частоты генератора скорости передачи

Tseg1 – первый сегмент

Tseg2 – Второй сегмент

Для проверки возьмем уже посчитанную скорость 125Кбит/c и попробуем получить настройки вручную. Pclk возьмем 16 МГц.

BRP = 16МГц /(125K * (1 + Tseg1 + Tseg2))

Затем подбираем интервал передачи бита находящийся в диапазоне от 8 до 25 квантов времени, так что бы получилось целое значение BRP. В нашем случае если взять (1 + Tseg1 + Tseg2) = 16, то BRP будет равен 30.

Далее нужно подобрать соотношение между Tseg1 и Tseg2, которое даст нам желаемое положение точки выборки (Sample Point – SP).

SP = ((1 + Tseg1 + Tseg2) * 70)/100

Подставляем значения и получаем 16 * 0.7 = 11.2, что соответствует соотношению Tseg1 = 10, Tseg2 = 5, т.е. 1 + 10 + 5 = 16. Далее смотрим если Tseg2 >= 5, то SJW = 4, если Tseg2
Рисунок 6 – Настройка CAN фильтра

Если все сделано правильно, то мы увидим сообщения от кресел (рисунок 7), а при нажатии кнопки наклона спинки на пульте управления мы увидим еще одно сообщение с адресом 1F4 идущее от пульта к креслу (рисунок 8).

Рисунок 7 – CAN сообщения от кресла с электроприводом

Рисунок 8 – CAN сообщения от кресла с электроприводом и сообщение от пульта управления к креслу

Теперь мы знаем какие должны быть адрес, длина и данные в CAN пакете для имитации нажатия кнопки изменения положения спинки. Во вкладке Transmit нажимаем NEW и в открывшемся окне создаем копию пакета 1F4, т.е. Length = 3, Data = 40 80 00. Period можно оставить 0 ms, тогда сообщения будут отправляться по факту нажатия кнопки пробел (рисунок 9).

Рисунок 9 – Создание CAN сообщения

На рисунке 10 отображено поле Transmit главного окна содержащее все отправляемые сообщения в CAN и информацию о них. При выделении сообщения и нажатии кнопки пробел произойдет отправка пакета в CAN сеть и кресло немного сдвинется в нужном направлении.

Рисунок 10 – Поле Transmit

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

Итог

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

Источник: www.embeddedsystem.ru

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

Однажды передо мной встала задача разработать встраиваемую систему, в которой бы данные могли передаваться между узлами c максимальной надежностью. Тогда то я впервые и узнал о CAN.

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

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

Далее я хочу поверхностно описать стандарт и рассказать об использовании такой сети на практике.

Стандарт

Стандарт описывает канальный уровень и базовые требования к физическому уровню.
Главное в физическом уровне — это требование возможности передачи бита как «доминантного» и «рецессивного«. Доминантный сигнал считается единицей, а рецессивный — нулем. Основное требование — при передаче доминантного и рецессивного сигнала одновременно, всем узлам должен прийти доминантный сигнал. На этом принципе основан механизм арбитража. Из этого следует, что для передачи могут использоваться разные среды, однако на практике чаще всего используют дифференциальную пару.

Передача в сети происходит кадрами. В стандарте существуют два типа кадров: базовый и расширенный.
Базовый кадр содержит 11 битовый идентификатор, а расширенный — 29 битовый. Кадр так же содержит бит запроса на передачу, информацию о длине передаваемых данных и сами данные. Они могут занимать от 0 до 8 байт в кадре. Так же кадр содержит некоторую служебную информацию, но для программиста она не принципиальна, поскольку её добавление реализовано аппаратно в контроллере сети.
Изначально идентификаторы не привязаны к какому либо узлу и характеризуют именно сообщение, а не отправителя и получателя. Идентификаторы так же показывают приоритетность сообщения. Приоритет определяется доминантными битами в идентификаторе. Так 10000000000 приоритетнее чем 01000000000.

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

Помимо этого используются механизмы обнаружения ошибок, такие как контроль передачи, дополняющие биты, использование контрольной суммы и проверка значений полей. Разработчики оценивают вероятность невыявления ошибки передачи как 4,7×10-11.

Данный стандарт не описывает протоколы верхнего уровня, поэтому было создано несколько реализаций, как коммерческих, так и открытых.
Наиболее известные из них:
— CANopen
— DeviceNet
— CAN Kingdom

Эту и даже более подробную информацию о стандарте легко найти в интернете, поэтому я наконец приступаю к описанию CANopen.

CANopen

Как я уже писал, однажды мне потребовалось создать надежную сеть из микроконтроллеров. После рассмотрения возможных вариантов было решено остановиться на сети CAN. В качестве протокола верхнего уровня был выбран CANopen и его реализация — CANopenNode, поскольку она является открытой и простой в портировании на нужное мне устройство. CANopenNode лицензирован под LGPL.

Основные моменты протокола CANopen:
— протокол работает со стандартными идентификаторами. Сеть может содержать до 127 узлов.
— каждому узлу выдается уникальный номер в сети.
— протокол не требует обязательного наличия мастера сети (однако существуют возможности, которые доступны только одному узлу в сети, который условно можно назвать мастером)
— OD (Object Dictionary ) — словарь объектов. Содержит отсортированный список переменных, доступ к которым можно получить по сети с помощью SDO.
— SDO (Service Data Objects) — механизм доступа к словарю объектов. Для доступа к объектам узла сети на этом узле должен быть запущен так называемый SDO-сервер. В сети может быть только один SDO-клиент, условно называемый мастером, который может получать данные от любого из серверов.
— PDO (Process Data Objects) — объекты для быстрого взаимодействия между узлами. Могут содержать до 8 байт данных и передаются в одном кадре. Для каждого PDO выделяется свой идентификатор (в определенном диапозоне). PDO условно делятся на входящие (RPDO) и исходящие (TPDO). Изначально предполагается, что каждый узел будет иметь по 4 RPDO и 4 TPDO, однако их можно перераспределить между узлами вплоть до того, что один узел будет иметь возможность принимать и передавать до 512 PDO. Однако в этом случае на другие узлы идентификаторов не хватит.
PDO могут посылаться по таймеру, по наступлению определенного события либо по прямому запросу на посылку из управляющей программы.
— NMT (Network Management) — менеджер сети. Сообщения этого типа могут переводить узлы в разные состояния (инициализация, рабочее, предрабочее, остановленное), а так же с их помощью обеспечивается контроль работы сети — механизм heartbeat.
— Heartbeat — переводится как сердцебиение. Суть механизма заключается в том, что каждый узел передает в сеть определенное сообщение, уникальное для каждого узла (ID получается путем прибавления номера узла в сети к определенному числу). Любой узел, который хочет узнать, по прежнему ли ему доступны узлы с определенными id должен просто принимать и обрабатывать эти сообщения. Сообщения от неинтересных для него узлов могут игнорироваться.
— Emergency message — в протоколе предусмотрена посылка сообщений об аварийных ситуациях.
— EDS (Electronic Data Sheets) — специальные текстовые файлы, позволяющие настроить словарь объектов. Существуют программы, помогающие в генерации таких файлов.

CANopenNode

CANopenNode — открытая реализация протокола CANopen, написанная на чистом С для использования в микроконтроллерах.

Теперь я опишу особенности, с которыми мне пришлось столкнуться при работе с CANopenNode.
1. Я использовал 32-битный контроллер, а CANopenNode изначально написан для 8/16 битных. Из-за этого в одном месте таймер сходил с ума, поскольку вместо того, чтобы переполниться и, как следствие, обнулиться, он продолжал расти и в механизме хартбита выдавалась ошибка о том, что поголовно все узлы превысили время ожидания нового хартбита.
2. Моя задача предполагала, что я могу передавать большие объемы данных. При этом несколько контроллеров могли передавать эти данные, а остальные — получать. Пришлось отказаться от механизма SDO (поскольку в нем только один контроллер имел бы возможность посылать данные с размером больше чем 8 байт) и написать свою собтвенную надстройку, которая использовала первые два байта PDO в виде управляющей информации.
3. Решение из пункта два привело к тому, что мне потребовалось однозначно определять участников взаимодействия, что возможно сделать только с помощью идентификаторов.
Это был, пожалуй, самый тонкий момент в работе. Было решено ограничить количество «мастеров» четырьмя штуками. Эти четыре узла получали 127 PDO на вход и на выход. А остальные узлы работали с 4 входящими и исходящими PDO. При чем, идентификаторы PDO были распределены так, что узлы-«ведомые» имели по одному исходящему сообщению, каждое из которых читал только определенный «мастер» и по одному входящему сообщению от каждого «мастера». Мастера же соответственно имели по одному каналу для обращения лично к любому из «ведомых» и точно знали, кто из них обращается к нему.
Эта концепция была сложнее всего, так как даже на форумах, где люди работают с CAN, бытует мнение, будто CANopen нельзя настроить подобным образом.
4. Настройка идентификаторов в данном протоколе происходит в коде. Более того, от неё зависят id узлов, которые будет читать и принимать конкретный узел. Поэтому смена id на ходу представляется сложной для данного протокола и требует дополнительных усилий.

В виде заключения

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

Я с удовольствием отвечу на любые вопросы, принимаю критику и дополнения, а так же могу подробнее остановиться на каких-либо моментах, если кому-нибудь это будет интересно.
Спасибо Вам за внимание!

Ссылки на некоторые ресурсы, связанные с CAN

www.can-cia.org — (англ.) международная организация CAN in Automation.
sourceforge.net/projects/canopennode — (англ.) проект CANopenNode

UPD:
Забыл добавить еще один интересный момент, который некоторое время вводил меня в заблуждение. Я отлаживал свою сеть на двух контроллерах, которые я соединил напрямую.
1. Когда я перепрошивал один из контроллеров, сеть на втором начинала выдавать ошибки (начинали часто-часто мигать лампочки — поведение, определенное в стеке CANopen). При обычной перезагрузке контроллера такого не происходило. Возможно, это специфика конкретного контроллера, но на всякий случай это стоит иметь в виду.
2. Протокол CANopen спроектирован таким образом, что если сообщение с определенным id не было отправлено до того момента, как оно должно быть отправлено еще раз, то это тоже вызывает ошибку. При том, каждый узел сети каждую секунду посылает хартбит-сообщение. Поэтому даже если вы ничего не отправляете, то всё равно можете получить ошибку сети.

Источник: habr.com

CAN. Промышленная сеть CAN

CAN (Controll Area Network) — открытый протокол последовательной связи, который определен на физическом и канальном уровнях, получил развитие на пользовательском у ровне и утвержден в качестве стандарта ISO 11898.

11.2.1. Физический уровень CAN реализуется экранированной витой парой с терминаторами RT на концах 118 Ом

Рис. 11.4. Структур стандартного фрейма данных

На рис.11.4 приняты следующие обозначения:

SOF — старт фрейма: один доминирующий бит.

Поле арбитража – в структуре расширенного фрейма количество бит идентификактора увеличено до 29 и добавлены два служебных бита. RTR – бит, которым сообщение определяется как фрейм данных или как удаленный фрейм.

Поле Управляющее — содержит 6 бит, из которых 4 бита DLC определяют количество байт данных в поле данных, а биты- IDE и R(0) зарезервированы для развития.

Поле данных — содержит до 8-ми байт данных.

CRC – 15 бит контрольной суммы, обеспечивающие высокий уровень достоверности передачи сообщений.

Поле АСК — поле подтверждения правильного приема сообщения.

EOF– поле конца фрейма. В нем передаются 7 рецессивных бит.

Int и BI — соответственно обязательный интервал между фреймами и уровень свободной шины.

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

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

3) Организация достоверной передачи сообщений в сети CAN

Контроль достоверности приема сообщения осуществляется в поле подтверждения АСК (acknowlegment – подтверждение), которое содержит два участка: ACK-Slot и ACK –Delimiter (рис.11.5.):

Сегмент подтверждения ACK- Slot Сегмент разграничителя ACK- Delimiter

Рис. 11.5. Структура поля АСК

Принцип подтверждения состоит в том, что передающий узел посылает в обоих сегментах АСК рецессивные биты и одновременно отслеживает состояние сигнала на шине. Приемник анализирует СКС принимаемого фрейма: если будет установлено, что сообщение недостоверно, то состояние приемник не изменяет уровень сигнала в АСК-Slot, но если будет установлен достоверный прием сообщения, то приемник в секторе АСК-Slot выставляет доминирующий бит. При наложении рецессивного бита передатчика и доминирующего бита приемника в линии установится доминирующий бит, подтверждающий передающему узлу, что сообщение принято и повтор не требуется. Таким образом, если низкий уровень сигнала принять за логическую «1», а высокий – за логический «0», то в поле АСК будут передаваться сигналы: 10 – если подтверждение получено или 11 если подтверждение не получено.

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

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

— Ошибка подтверждения возникает, когда передатчик определяет, что сообщение не было подтверждено.

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

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

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

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

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

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

Механизм арбитража состоит в следующем. В течение передачи поля арбитража биты идентификатора последовательно передаются в линию связи, начиная от старшего значещего к младшему. В процессе выполне-ния передачи CAN-устройство одновременно и формирует в линию связи сигнал требуемого уровня (CAN_L/CAN_H), и контролирует состояние си-гнала в линии связи, сравнивая: соответствует текущее значение сигнала в линии связи сформированному значению?

Если CAN-устройство сформировало в линию связи сигнал высокого уровня CAN_H и в линии связи установился сигнал CAN_H, то устройство продолжает передачу фрейма. Если CAN-устройство сформировало в линию связи сигнал высокого уровня CAN_H, а в линии связи будет установлен сигнал низкого уровня CAN_L, устройство должно прекратить передачу в линию связи своего сигнала. При одновременном формировании в линию связи сигналов с высоким и с низким уровнями сигнал низкого уровня «давит» сигнал высокого уровня. По этой причине арбитраж выигрывает то CAN-устройство, у которого идентификатор имеет самое низкое значение!

Источник: eti.su

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

Однажды передо мной встала задача разработать встраиваемую систему, в которой бы данные могли передаваться между узлами c максимальной надежностью. Тогда то я впервые и узнал о CAN.

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

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

Далее я хочу поверхностно описать стандарт и рассказать об использовании такой сети на практике.

Стандарт

Стандарт описывает канальный уровень и базовые требования к физическому уровню.
Главное в физическом уровне — это требование возможности передачи бита как «доминантного» и «рецессивного«. Доминантный сигнал считается единицей, а рецессивный — нулем. Основное требование — при передаче доминантного и рецессивного сигнала одновременно, всем узлам должен прийти доминантный сигнал. На этом принципе основан механизм арбитража. Из этого следует, что для передачи могут использоваться разные среды, однако на практике чаще всего используют дифференциальную пару.

Передача в сети происходит кадрами. В стандарте существуют два типа кадров: базовый и расширенный.
Базовый кадр содержит 11 битовый идентификатор, а расширенный — 29 битовый. Кадр так же содержит бит запроса на передачу, информацию о длине передаваемых данных и сами данные. Они могут занимать от 0 до 8 байт в кадре. Так же кадр содержит некоторую служебную информацию, но для программиста она не принципиальна, поскольку её добавление реализовано аппаратно в контроллере сети.
Изначально идентификаторы не привязаны к какому либо узлу и характеризуют именно сообщение, а не отправителя и получателя. Идентификаторы так же показывают приоритетность сообщения. Приоритет определяется доминантными битами в идентификаторе. Так 10000000000 приоритетнее чем 01000000000.

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

Помимо этого используются механизмы обнаружения ошибок, такие как контроль передачи, дополняющие биты, использование контрольной суммы и проверка значений полей. Разработчики оценивают вероятность невыявления ошибки передачи как 4,7×10-11.

Данный стандарт не описывает протоколы верхнего уровня, поэтому было создано несколько реализаций, как коммерческих, так и открытых.
Наиболее известные из них:
— CANopen
— DeviceNet
— CAN Kingdom

Эту и даже более подробную информацию о стандарте легко найти в интернете, поэтому я наконец приступаю к описанию CANopen.

CANopen

Как я уже писал, однажды мне потребовалось создать надежную сеть из микроконтроллеров. После рассмотрения возможных вариантов было решено остановиться на сети CAN. В качестве протокола верхнего уровня был выбран CANopen и его реализация — CANopenNode, поскольку она является открытой и простой в портировании на нужное мне устройство. CANopenNode лицензирован под LGPL.

Основные моменты протокола CANopen:
— протокол работает со стандартными идентификаторами. Сеть может содержать до 127 узлов.
— каждому узлу выдается уникальный номер в сети.
— протокол не требует обязательного наличия мастера сети (однако существуют возможности, которые доступны только одному узлу в сети, который условно можно назвать мастером)
— OD (Object Dictionary ) — словарь объектов. Содержит отсортированный список переменных, доступ к которым можно получить по сети с помощью SDO.
— SDO (Service Data Objects) — механизм доступа к словарю объектов. Для доступа к объектам узла сети на этом узле должен быть запущен так называемый SDO-сервер. В сети может быть только один SDO-клиент, условно называемый мастером, который может получать данные от любого из серверов.
— PDO (Process Data Objects) — объекты для быстрого взаимодействия между узлами. Могут содержать до 8 байт данных и передаются в одном кадре. Для каждого PDO выделяется свой идентификатор (в определенном диапозоне). PDO условно делятся на входящие (RPDO) и исходящие (TPDO). Изначально предполагается, что каждый узел будет иметь по 4 RPDO и 4 TPDO, однако их можно перераспределить между узлами вплоть до того, что один узел будет иметь возможность принимать и передавать до 512 PDO. Однако в этом случае на другие узлы идентификаторов не хватит.
PDO могут посылаться по таймеру, по наступлению определенного события либо по прямому запросу на посылку из управляющей программы.
— NMT (Network Management) — менеджер сети. Сообщения этого типа могут переводить узлы в разные состояния (инициализация, рабочее, предрабочее, остановленное), а так же с их помощью обеспечивается контроль работы сети — механизм heartbeat.
— Heartbeat — переводится как сердцебиение. Суть механизма заключается в том, что каждый узел передает в сеть определенное сообщение, уникальное для каждого узла (ID получается путем прибавления номера узла в сети к определенному числу). Любой узел, который хочет узнать, по прежнему ли ему доступны узлы с определенными id должен просто принимать и обрабатывать эти сообщения. Сообщения от неинтересных для него узлов могут игнорироваться.
— Emergency message — в протоколе предусмотрена посылка сообщений об аварийных ситуациях.
— EDS (Electronic Data Sheets) — специальные текстовые файлы, позволяющие настроить словарь объектов. Существуют программы, помогающие в генерации таких файлов.

CANopenNode

CANopenNode — открытая реализация протокола CANopen, написанная на чистом С для использования в микроконтроллерах.

Теперь я опишу особенности, с которыми мне пришлось столкнуться при работе с CANopenNode.
1. Я использовал 32-битный контроллер, а CANopenNode изначально написан для 8/16 битных. Из-за этого в одном месте таймер сходил с ума, поскольку вместо того, чтобы переполниться и, как следствие, обнулиться, он продолжал расти и в механизме хартбита выдавалась ошибка о том, что поголовно все узлы превысили время ожидания нового хартбита.
2. Моя задача предполагала, что я могу передавать большие объемы данных. При этом несколько контроллеров могли передавать эти данные, а остальные — получать. Пришлось отказаться от механизма SDO (поскольку в нем только один контроллер имел бы возможность посылать данные с размером больше чем 8 байт) и написать свою собтвенную надстройку, которая использовала первые два байта PDO в виде управляющей информации.
3. Решение из пункта два привело к тому, что мне потребовалось однозначно определять участников взаимодействия, что возможно сделать только с помощью идентификаторов.
Это был, пожалуй, самый тонкий момент в работе. Было решено ограничить количество «мастеров» четырьмя штуками. Эти четыре узла получали 127 PDO на вход и на выход. А остальные узлы работали с 4 входящими и исходящими PDO. При чем, идентификаторы PDO были распределены так, что узлы-«ведомые» имели по одному исходящему сообщению, каждое из которых читал только определенный «мастер» и по одному входящему сообщению от каждого «мастера». Мастера же соответственно имели по одному каналу для обращения лично к любому из «ведомых» и точно знали, кто из них обращается к нему.
Эта концепция была сложнее всего, так как даже на форумах, где люди работают с CAN, бытует мнение, будто CANopen нельзя настроить подобным образом.
4. Настройка идентификаторов в данном протоколе происходит в коде. Более того, от неё зависят id узлов, которые будет читать и принимать конкретный узел. Поэтому смена id на ходу представляется сложной для данного протокола и требует дополнительных усилий.

В виде заключения

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

Я с удовольствием отвечу на любые вопросы, принимаю критику и дополнения, а так же могу подробнее остановиться на каких-либо моментах, если кому-нибудь это будет интересно.
Спасибо Вам за внимание!

Ссылки на некоторые ресурсы, связанные с CAN

www.can-cia.org — (англ.) международная организация CAN in Automation.
sourceforge.net/projects/canopennode — (англ.) проект CANopenNode

UPD:
Забыл добавить еще один интересный момент, который некоторое время вводил меня в заблуждение. Я отлаживал свою сеть на двух контроллерах, которые я соединил напрямую.
1. Когда я перепрошивал один из контроллеров, сеть на втором начинала выдавать ошибки (начинали часто-часто мигать лампочки — поведение, определенное в стеке CANopen). При обычной перезагрузке контроллера такого не происходило. Возможно, это специфика конкретного контроллера, но на всякий случай это стоит иметь в виду.
2. Протокол CANopen спроектирован таким образом, что если сообщение с определенным id не было отправлено до того момента, как оно должно быть отправлено еще раз, то это тоже вызывает ошибку. При том, каждый узел сети каждую секунду посылает хартбит-сообщение. Поэтому даже если вы ничего не отправляете, то всё равно можете получить ошибку сети.

Источник: habr.com

CAN-шина

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

Протокол разработан на основе стандартов ISO передачи данных.

В середине 80-х годов прошлого столетия компании Intel и Robert Bosch GmbH разработали цифровое устройство для обмена данных, которое стало стандартом автомобильной

электроники.

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

Особенности устройства CAN-шины

Передаются данные, со скоростью 1Мбит/сек, по радиоканалам или на оптоволоконном уровне. Биты данных одномоментно превращаются в кадры (подобие ограниченных порций). Есть сложная схема разделения кадров на доминантные и рецессивные и приоритетов формирования очереди передачи, с применением арбитража. Однако в эти области высоких технологий, простому автолюбителю заглядывать нет никакой нужды.

На физическом уровне CAN-сеть – это непрерывная «шина» дифференциальной пары, в роли проводника информации, прописанной стандартом ISO. Доступ к ней осуществляется посредством драйвера CAN-шины.

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

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

В последних выпусках есть функции подключения к смартфонам.

Есть заложенная функция предвидения и устранения некоторых неполадок электрооборудования автомобиля. Даже электробрелки зажигания, подключаясь через CAN, получают необходимые данные от ЭБУ автомобиля.

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

Передача данных по Кан-шине

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

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

Тот, получив наказ на какое-либо действие, спешит его выполнить.

В покое, напряжение в проводах витой пары одинаковое и составляет 2,5В. Это, так называемое, рецессивное положение. Во время начала сеанса, провода приводятся в возбуждение участником, посылающим сообщение. Напряжение на одном из проводов (CAN High) начинает возрастать, достигая 3,5В. На другом (CAN low) – убывать, до достижения отметки 1В.

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

Обзор возможностей протокола CAN

1. Продукты — микросхема, инструменты разработки, модули, инструменты проектирования;
2. Распределение посланий — каждый участник будет иметь возможность выбирать к просмотру сообщения, касающиеся только его. Для этого предусмотрены фильтры;
3. Широковещательный характер – если участник не выбрал только свои сообщения, то он имеет возможность просмотра всего потока информации;
4. Контентная адресация – нет явного адресата. Выбираются адреса контента по идентификатору в самом сообщении;
5. Виды сообщений – кадр данных, удаленный, ошибки, перезагрузки;
6. СтандартныйCANи его расширенная версия – отличаются длиной установленного идентификатора. Если в станд. варианте он равен 11битам, то в его «толстом» собрате – 29 бит;
7. Конфликтное разрешение и определение приоритета – чтобы избежать одновременной передачи данных несколькими участниками, выработан арбитражный механизм. Все пакеты поделены на доминантный и рецессивный. Не вдаваясь в подробности, отметим только, что всегда приоритет на стороне доминантного сообщения.
8. Физические уровни:

— сигнальная сбалансированная двухпроводная схема high–speed CAN представляет вторую часть стандарта ISO 11898;

— третья часть ISO 11898 составляет следующий уровень вышеназванной схемы;

— однопроводной уровень, описываемый стандартом SAE J2411. Шины этого уровня установлены, например, на автомобилях линейки Дженерал Моторс.

1. Прерывание конца – CAN-шина должна содержать на конце резисторное сопротивление (120ОМ), для гашения отражения сигнала, создания уровня постоянного тока.
2. Кабель – сопротивление должно укладываться в интервал 108 – 132ОМ.
3. Разъем – нет стандартов для разъемов CAN. Каждый протокол описывает свои предпочтения. Однако есть фактический стандарт для автопромышленности.
4. Ошибка – контролер найдет ее и отметит флажком, разрушая передачу. Эти флажки станут знаком для всех участников цепи на ее сброс.
5. Сбои в передачи – при различных сбоях дается возможность дальнейшего функционирования. Сбои могут быть разного характера: прерывание, короткое замыкание в разных частях, разъединение с оконечным сопротивлением.

Скорость передачи данных CAN-шины

Все составляющие сети CAN должны иметь единую скорость передачи информации. Однако данный стандарт не задает одного определенного параметра, ограничиваясь лишь максимальным пределом – 1Мбит/с. Изменения объема передаваемого кадра должно успеть распространиться по всей длине сети, что ставит в обратную зависимость скорости от протяженности – чем длиннее провод, тем ниже скорость. Для передачи 1Мбита за 1секунду нужная длина должна составлять не менее 40 метров. Добавьте к этому объективные факторы, снижающие скорость – защита от помех и разветвленная сеть, где происходят множественные отражения сигнала.

В угоду ускорения процесса, разработчики уменьшают протяженность проводов, одновременно увеличивая число цепей, с возможностью подключения большего количества приборов. Например, общая длина шины, составляющая 10 метров, способна пропускать через себя кадры, со скоростью 2 Мбит/c, с 64 подключенными приборами. Если автомобиль снабжен большим числом электрооборудования, то добавляется одна, две, и т. д. цепи.

Протоколы высокого уровня

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

• Задать стандарты запуска, в т.ч. скорости обмена;
• Распределение, предварительно распознанных, адресов взаимодействующих элементов и видов сообщений;
• Точная разметка послания;
• Порядок разбора ошибок.

Достоинства и недостатки протокола CAN

Протокол CAN вошел в состав стандартного протокола OBD-II.

К несомненным преимуществам CAN относятся:

1. Передача информации в реальном времени;
2. Простота и дешевизна использования;
3. Помехоустойчивость;
4. Обеспечение доступа, путем арбитража, без снижения пропускных характеристик сети;
5. Контроль всех ошибок обмена данных;
6. Большой интервал рабочих скоростей;
7. Широкое его применение, большое разнообразие ассортимента от разных поставщиков.

К недостаткам относятся:

1. Маленький объем одного пакета данных, который составляет не более 8 байт;
2. Служебные данные занимают больше объема, чем передаваемые, что значительно влияет на скорость (разработчикам есть куда расширяться);
3. Нет общего стандарта на протоколы повышенного уровня. В CAN можно прописать любой протокол, если его исполнение помещается в рамках пропускной способности CAN.

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

Источник: elm327.club