Что такое шина CAN и как она работает
Видео:Кан шина, что это? Поймет школьник! принцип работыСкачать
Что такое интерфейс CAN и зачем он нужен
Controller Area Network (CAN) – это последовательная коммуникационная шина, разработанная для надежной и гибкой работы в жестких условиях, особенно для промышленных и автомобильных приложений.
Первоначально изобретенный Bosch, а затем кодифицированный в стандарт ISO11898-1, интерфейс CAN определяет канал передачи данных и физический уровень модели взаимодействия открытых систем (OSI), обеспечивая низкоуровневое сетевое решение для высокоскоростной связи в автомобилях и промышленном оборудовании. В частности, CAN был разработан для уменьшения кабельной проводки в автомобилях, чтобы отдельные электронные блоки управления (ЭБУ) внутри транспортного средства могли обмениваться данными только по одной паре проводов. На следующем рисунке показаны ЭБУ автомобиля, подключенного к шине CAN.
Бортовая диагностика (OBD) – это система диагностики и отчетности автомобиля, которая позволяет устранять неполадки с помощью диагностических кодов неисправности (DTC). Когда загорается индикатор «проверьте двигатель» (check engine), техник часто использует портативное устройство для считывания кодов двигателя с автомобиля. На самом низком уровне эти данные передаются по протоколу, который в большинстве случаев является CAN.
DeviceNet – это сетевой протокол высокого уровня, используемый в промышленных приложениях. Это значительно уменьшает проводку, необходимую между системой управления и устройствами ввода/вывода. Вместо того, чтобы подключать каждое устройство к отдельному входу/выходу на модулях ввода/вывода ПЛК, устройства могут быть связаны друг с другом через четырехпроводный разъем и подключены к сетевому сканеру на ПЛК. На самом низком уровне мы находим, что CAN работает в рамках протокола DeviceNet. На следующем рисунке показан ПЛК, сканирующий сеть промышленных устройств, обменивающихся данными через DeviceNet.
Видео:CAN шина👏 Как это работаетСкачать
Кадры сообщений CAN
Так как же на самом деле выглядит сообщение CAN? В первоначальном стандарте ISO изложено то, что называется стандартом CAN. Стандарт CAN использует 11-битный идентификатор для разных сообщений, что в сумме составляет 211, т. е. 2048, разных идентификаторов сообщений. CAN был позже изменен; идентификатор был расширен до 29 бит, что дало 229 идентификаторов. Это называется расширенной шиной CAN. CAN использует мультимастерную шину, где все сообщения транслируются по всей сети. Идентификаторы обеспечивают приоритет сообщения для арбитража.
CAN использует дифференциальный сигнал с двумя логическими состояниями, называемыми рецессивным и доминантным. Рецессивный указывает, что дифференциальное напряжение меньше минимального порогового напряжения. Доминантный указывает, что дифференциальное напряжение больше, чем этот минимальный порог. Интересно, что доминантное состояние достигается путем передачи логического уровня «0» на шину, в то время как рецессивное состояние достигается с помощью логического уровня «1». Это инверсия от традиционных высоких и низких логических значений, используемых в большинстве систем. Эти два состояния будут подробно описаны далее. Важно то, что доминантное состояние приоритетнее рецессивного в арбитраже.
Видео:Подробно про CAN шинуСкачать
Стандартный кадр CAN
Стандартный кадр сообщения CAN состоит из нескольких битовых полей. Они показаны на следующем рисунке.
Первый бит – это начало кадра (SOF). Этот доминирующий бит представляет начало сообщения CAN. Далее идет 11-битный идентификатор, который устанавливает приоритет сообщения CAN. Чем меньше идентификатор, тем выше приоритет сообщения.
Бит запроса удаленной передачи (RTR) обычно является доминантным, но он становится рецессивным, когда один узел запрашивает данные у другого. Бит расширения идентификатора (IDE) является доминантным, когда отправляется стандартный кадр CAN, а не расширенный. Бит r0 зарезервирован и в настоящее время не используется. Кусок кода длины данных (DLC) показывает, сколько байтов данных содержится в этом сообщении.
Далее идут сами данные, представляющие собой столько байтов, сколько представлено в битах DLC. Циклическая проверка избыточности (CRC) – это 16-битная контрольная сумма для обнаружения ошибок в передаваемых данных. Если сообщение принято правильно, принимающий узел перезаписывает рецессивный бит подтверждения (ACK) доминантным битом. ACK также содержит бит-разделитель для синхронизации. Конец кадра (EOF) означает конец сообщения CAN и имеет ширину 7 бит для обнаружения ошибок вставки битов. Последняя часть сообщения CAN – это межкадровое пространство (IFS), используемое в качестве временной задержки. Эта временная задержка точно соответствует времени, необходимому контроллеру CAN для перемещения полученного сообщения в буфер для дальнейшей обработки.
Видео:поиск нерабочей can шины, часть дваСкачать
Расширенный кадр CAN
Расширенный кадр сообщения CAN использует 29-битный идентификатор вместе с несколькими дополнительными битами.
Расширенное сообщение имеет заменяющий бит удаленного запроса (SRR) после 11-битного идентификатора, который действует как заполнитель для сохранения той же структуры, что и стандартный CAN. На этот раз расширение идентификатора (IDE) должно быть рецессивным, что указывает на то, что за ним следует расширенный идентификатор. Бит RTR находится после 18-битного идентификатора, за ним следует второй резервный бит r1. Остальная часть сообщения остается прежней.
Видео:лекция 403 CAN шина- введениеСкачать
Типы сообщений CAN
Теперь, когда вы знаете, как выглядит сообщение CAN, вам может быть интересно, какие сообщения передаются по шине. CAN допускает четыре разных типа сообщений. Это кадр данных, удаленный кадр, кадр перегрузки и кадр ошибок.
Стандартный кадр данных CAN использует идентификатор, данные и код длины данных, проверку циклическим избыточным кодом и биты подтверждения. Оба бита RTR и IDE являются доминирующими в кадрах данных. Если рецессивный бит подтверждения на принимающей стороне перезаписан доминантным битом, и передатчик, и приемник распознают это как успешную передачу.
Удаленный кадр CAN выглядит аналогично кадру данных, за исключением того факта, что он не содержит никаких данных. Он отправляется с битом RTR в рецессивном состоянии; это указывает на то, что это удаленный кадр. Удаленные кадры используются для запроса данных от узла.
Когда узел обнаруживает ошибку в сообщении на шине CAN, он передает кадр ошибки. Это приводит к тому, что все другие узлы отправляют кадр ошибки. После этого узел, где произошла ошибка, повторно передает сообщение. Кадр перегрузки работает аналогично, но используется, когда узел получает кадры быстрее, чем он может их обработать. Этот кадр обеспечивает временной буфер, чтобы узел мог догнать.
Видео:Простая проверка CAN шины. Сканер не видит автомобиль через OBD2. Как правильно выбрать изоленту.Скачать
Арбитраж и сигналы на шине CAN
CAN – это протокол CSMA/CD, означающий, что каждый узел на шине может обнаруживать коллизии и откатываться на определенное время перед попыткой повторной передачи. Это обнаружение коллизий достигается посредством арбитража приоритетов на основе идентификаторов сообщений. Прежде чем обсудить арбитраж, давайте подробнее рассмотрим доминантные и рецессивные биты, используемые на шине CAN.
Интересным аспектом шины CAN является то, что она использует инвертированную форму логики с двумя состояниями: доминантным и рецессивным. На рисунке ниже показана упрощенная версия вывода и ввода CAN-трансивера. Поток битов ‘101’ поступает с / идет на CAN-контроллер и / или микроконтроллер. Обратите внимание, что когда контроллер отправляет поток битов, они дополняются и помещаются в линию CANH. Линия CANL всегда является дополнением CANH. Чтобы арбитраж работал, устройство CAN должно отслеживать как то, что оно отправляет, так и то, что в данный момент находится на шине, то есть то, что оно получает.
На следующем рисунке показаны сигналы CANH и CANL одновременно, так что вы можете видеть шину CAN в действии. Под сигналами шины изображено дифференциальное напряжение, которое соответствует доминантному и рецессивному состояниям сигналов CAN. Первые три сегмента во времени, t1 – t3, нарисованы так, чтобы соответствовать трем битам, показанным на предыдущем рисунке. Мы рассмотрим это с точки зрения драйвера вывода. Ввод драйвера изначально видит «1» и дополняет его до нуля, который помещается в CANH. CANL видит дополнение CANH и переводится в высокое логическое состояние. Это показано как t1 на рисунке. Обратите внимание, что напряжения CANH и CANL смещены относительно друг друга. В течение времени t1 дифференциал CANH — CANL очень близок к нулю, так как CANH и CANL имеют почти одинаковое напряжение. Этот период, когда драйвер посылает логику «1», в результате чего CANH и CANL близки к одному и тому же напряжению, мы называем рецессивным состоянием CAN.
Читайте также: Шины летние промокод гудс
Следующий отправленный бит – «0». CANH получает свое дополнение, и CANL снова получает дополнение CANH. Обратите внимание, что на этот раз напряжения CANH и CANL не близки друг к другу. Следовательно, дифференциальное напряжение (VDIFF) больше. Это CAN-доминантное состояние. Мы говорим, что логика инвертирована, потому что «1» приводит к понижению логического уровня шины, а «0» — к повышению. Входной приемник работает аналогично.
Как упоминалось ранее, чем меньше 11-битный идентификатор, тем выше приоритет сообщения. Каждый бит, который передает узел, он контролирует. Таким образом, узел обнаруживает, что сообщение с более высоким приоритетом размещается на шине. В тот момент, когда узел отправляет рецессивный бит, но обнаруживает доминантный бит на шине, он «отступает». Это называется неразрушающим арбитражем, потому что «победившее» сообщение продолжает передаваться без каких-либо проблем. Обратите внимание, что рецессивная логика «1» проигрывает доминантной логике «0». Это имеет смысл, поскольку более низкое значение идентификатора представляет более высокий приоритет. Чтобы лучше понять, что это значит, взгляните на следующий рисунок, на котором показаны три узла на шине CAN, пытающиеся получить контроль. Важно помнить, что каждый раз, когда отображается рецессивный бит, контроллер отправляет «1», в то время как доминантные биты соответствуют отправке «0».
Узлы 1–3 все посылают поток битов. Этот поток битов представляет идентификаторы сообщений и их приоритет. Для начала все три узла отправляют «1», который представлен на шине CAN как рецессивный бит. Затем каждый узел отправляет «0» или доминанатный бит. Третий бит, помещенный в шину – это еще один бит «1» или рецессивный бит. На этом этапе ни один из узлов не обнаружил никакого конфликта с другим узлом на шине, поэтому они продолжают передавать.
Для четвертого бита узел 1 отправляет «0» или доминантный бит. Узел 2 передает рецессивный бит, но обнаруживает доминантный бит на шине. Он немедленно «отступает», зная, что в данный момент отправляется сообщение с более высоким приоритетом. Узел 3 продолжает передачу, поскольку он считывает тот же доминантный бит, который он передал. Когда пятый бит помещается в шину, узел 3 затем распознает, что он имеет более низкий приоритет, и прекращает передачу. И узел 2, и узел 3 ждут определенное количество времени, прежде чем пытаться снова. Это показано в правой части рисунка, где выиграл арбитраж узел 3. Как видите, логический бит «0», соответствующий младшему идентификатору сообщения, позволяет проводить арбитраж.
Видео:Что такое CAN шинаСкачать
Заключение
В этой статье были представлены основные принципы работы шины CAN. CAN – это надежная шина последовательной связи, используемая в основном в автомобильной и промышленной среде. CAN использует дифференциальный сигнал, что делает ее более устойчивой к шуму, а также схему арбитража приоритетов для неразрушающей передачи сообщений. CAN отлично подходит для встраиваемых приложений, которые работают в опасных средах или областях с большим количеством электромагнитных помех.
Видео:Как проверить CAN шину Используем симулятор ElectudeСкачать
Краткий обзор протокола CAN. Часть I
По материалам компании Kvaser
Эта статья не претендует на полноту и абсолютную точность сведений, указанных в ней, и предназначена для ознакомления с протоколом 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 используются кадры данных длиной всего лишь 8 байт) и т.п.
Системы распределённого управления
Протокол CAN является хорошей основой для разработки систем распределённого управления. Метод разрешения конфликтов, используемый CAN, обеспечивает то, что каждый узел CAN будет взаимодействовать с теми сообщениями, которые относятся к данному узлу.
Систему распределённого управления можно описать как систему, вычислительная мощность которой распределена между всеми узлами системы. Противоположный вариант – система с центральным процессором и локальными точками ввода–вывода.
Сообщения CAN
Шина CAN относится к широковещательным шинам. Это означает, что все узлы могут «слушать» все передачи. Не существует возможности послать сообщение конкретному узлу, все без исключения узлы будут принимать все сообщения. Оборудование CAN, однако, обеспечивает возможность локальной фильтрации, так что каждый модуль может реагировать только на интересующее его сообщение.
Адресация сообщений CAN
CAN использует относительно короткие сообщения – максимальная длина информационного поля составляет 94 бита. В сообщениях отсутствует явный адрес, их можно назвать контентно–адрессованными: содержимое сообщения имплицитно (неявным образом) определяет адресата.
Типы сообщений
Существует 4 типа сообщений (или кадров), передающихся по шине CAN:
• удаленный кадр (Remote Frame);
• кадр перегрузки (Overload Frame).
Кадр данных
Кратко: «Всем привет, есть данные с маркировкой X, надеюсь вам понравятся!»
Кадр данных – самый распространенный тип сообщения. Он содержит в себе следующие основные части (некоторые детали не рассматриваются для краткости):
Читайте также: Рейтинг автомобильных шин зимних r17
• Поле арбитража (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 использует код без возвращения к нулю (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 метров. Это связано с требованием схемы разрешения конфликтов, согласно которому фронт волны сигнала должен иметь возможность дойти до самого дальнего узла и вернуться назад прежде чем бит будет считан. Иными словами, длина кабеля ограничена скоростью света. Предложения по увеличению скорости света рассматривались, но были отвергнуты в связи с межгалактическими проблемами.
Другие максимальные длины кабеля (значения приблизительные):
• 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.
- Свежие записи
- Нужно ли менять пружины при замене амортизаторов
- Скрипят амортизаторы на машине что делать
- Из чего состоит стойка амортизатора передняя
- Чем стянуть пружину амортизатора без стяжек
- Для чего нужны амортизаторы в автомобиле
🎥 Видео
Колесо: Уникальное изобретение человека | Интересные факты про колесоСкачать
Мерседес разьем CAN шины, как выглядит и где?Скачать
Шина CAN. Часть 1. Разбираемся как работает CAN bus, разберем кадр данных до "костей".Скачать
CAN шина на осциллографе FINIRSI ADS1013DСкачать
Сканер не подключается: поиск неисправности CAN шины (видео 57)Скачать
Галилео. История изобретений. ШиныСкачать
Поиск уровня топлива в CAN шине Toyota Camry 2017Скачать
CAN-шина, простой поиск данных в кан шине автомобиля. Как расшифровать и найти данные в кан шине?Скачать
Как работает LIN шина автомобиля. K-Line L-Line шины данных. Лин шина автомобиля. Lin-bus networkСкачать
Вебинар: Как найти любые данные из CAN-шины любого автомобиля?Скачать
LIN шина - пример работы. LIN bus exampleСкачать
Проходим 3 уровень simulator electude Проверяем CAN шинуСкачать
