Интерфейс CAN, Принципы обмена по протоколу CAN Опции

[denwill]

Здравствуйте уважаемые разработчики!

Прочитал много информации по данной теме:
-http://www.microchip.ru/files/d-sheets-rus/an713.pdf
-http://www.gaw.ru/html.cgi/txt/interface/can/start.htm
-Спецификации CAN 2.0 A и CAN 2.0 B
-Документация на AT90CAN128
-http://electronix.ru/forum/index.php?showtopic=12898&hl=CAN
-и др.
Но к сожалению так и не смог понять логику работы интерфейса!
Как например, раздать идентификаторы устройствам (приоритеты данных от этих устройств одинаковые)?
Как передать данные конкретному устройству (нужен ли для этого remote frame, и если да, то какой идентификатор передается в этом фрейме)?

Расчитываю на Ваш совет! Спасибо.

[shans]

Только начал разбираться с CAN-интерфейсом, что-т не догоняю: обязательно ли использование трансиверов? Или возможно подключение без них?

[ipc]

Только начал разбираться с CAN-интерфейсом, что-т не догоняю: обязательно ли использование трансиверов? Или возможно подключение без них?

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

[shans]

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

[ipc]

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

Если в системах на базе RS-232 это может и прокатит но вот в RS-485 и CAN(который использует похожую физическую линию) нет.Во первых потому что это шинные интерфейсы(т.е подразумевается что устройств будет больше двух) а главное то что в обычно используемой физической линии CAN нет состояний 0/1 а есть доминантное и рецесивное.
Если кратко то эти состояния неравноценны(как 0 и 1) и когда одно устройство выставляет рецесивное состояние другое устройство может задавить его доминантным чем и достигается контроль передачи и неразрушающий арбитраж.Вот эта фича и обеспечивается драйвером.
Как это делается в других физических линиях(оптика и блютуз) мало понятно но скорее всего идет эмуляция привычной CANу физической линии.

[shans]

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

Если в системах на базе RS-232 это может и прокатит но вот в RS-485 и CAN(который использует похожую физическую линию) нет.Во первых потому что это шинные интерфейсы(т.е подразумевается что устройств будет больше двух) а главное то что в обычно используемой физической линии CAN нет состояний 0/1 а есть доминантное и рецесивное.
Если кратко то эти состояния неравноценны(как 0 и 1) и когда одно устройство выставляет рецесивное состояние другое устройство может задавить его доминантным чем и достигается контроль передачи и неразрушающий арбитраж.Вот эта фича и обеспечивается драйвером.
Как это делается в других физических линиях(оптика и блютуз) мало понятно но скорее всего идет эмуляция привычной CANу физической линии.

Ну а если объединить по монтажному "И"? Вполне получаем доминантный и рецессивный уровень. А стоимость реализации значительно ниже. Понятно, что с уровнями под стандарт ISO 11898 не попадаем, но это уже другой вопрос. Извиняюсь, если задаю бестолковые вопросы , просто хочу уяснить преимущества решения с использованием трансиверов.

[ipc]

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

Если в системах на базе RS-232 это может и прокатит но вот в RS-485 и CAN(который использует похожую физическую линию) нет.Во первых потому что это шинные интерфейсы(т.е подразумевается что устройств будет больше двух) а главное то что в обычно используемой физической линии CAN нет состояний 0/1 а есть доминантное и рецесивное.
Если кратко то эти состояния неравноценны(как 0 и 1) и когда одно устройство выставляет рецесивное состояние другое устройство может задавить его доминантным чем и достигается контроль передачи и неразрушающий арбитраж.Вот эта фича и обеспечивается драйвером.
Как это делается в других физических линиях(оптика и блютуз) мало понятно но скорее всего идет эмуляция привычной CANу физической линии.

Ну а если объединить по монтажному "И"? Вполне получаем доминантный и рецессивный уровень. А стоимость реализации значительно ниже. Понятно, что с уровнями под стандарт ISO 11898 не попадаем, но это уже другой вопрос. Извиняюсь, если задаю бестолковые вопросы , просто хочу уяснить преимущества решения с использованием трансиверов.

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

[=AK=]

думаю что фронты завалятся в корягу метра через два.

LIN работает при помощи открытых коллекторов, т.е. по монтажному ИЛИ. При 20 кбод на 40 м работает.
Далласовский 1-wire тоже использует открытые коллекторы. Даллас пишет - то 700 м.

[spf]

думаю что фронты завалятся в корягу метра через два.

LIN работает при помощи открытых коллекторов, т.е. по монтажному ИЛИ. При 20 кбод на 40 м работает.

CAN на 40 метрах может работать в полный рост - 1Мбод при родном драйвере, это в _50_ раз быстрее...

[ipc]

думаю что фронты завалятся в корягу метра через два.

LIN работает при помощи открытых коллекторов, т.е. по монтажному ИЛИ. При 20 кбод на 40 м работает.

CAN на 40 метрах может работать в полный рост - 1Мбод при родном драйвере, это в _50_ раз быстрее...

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

Ну не такие уж копейки, а на километр мне тянуть не нужно, всего несколько метров. Собственно я сам за использование драйверов, дабы не создавать себе же лишние проблемы. Однако, как водится, на любой дополнительный корпус смотрят косо, и его использование нужно мотивировать

Ну тогда неправильно выбран интерфейс.CAN это полевая шина(название говорит само за себя) и предназначен для распределения девайсов в пространстве.Тут подошел бы ethеrnet(благо он сильно подешевел и в виде XPortа нетребует вобще никакой разработки) или вобще чтонибудь децкое типа SPI,I2c или нахудой конец проверенный веками RS-485.

[shans]

думаю что фронты завалятся в корягу метра через два.

LIN работает при помощи открытых коллекторов, т.е. по монтажному ИЛИ. При 20 кбод на 40 м работает.

CAN на 40 метрах может работать в полный рост - 1Мбод при родном драйвере, это в _50_ раз быстрее...

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

Ну не такие уж копейки, а на километр мне тянуть не нужно, всего несколько метров. Собственно я сам за использование драйверов, дабы не создавать себе же лишние проблемы. Однако, как водится, на любой дополнительный корпус смотрят косо, и его использование нужно мотивировать

Ну тогда неправильно выбран интерфейс.CAN это полевая шина(название говорит само за себя) и предназначен для распределения девайсов в пространстве.Тут подошел бы ethеrnet(благо он сильно подешевел и в виде XPortа нетребует вобще никакой разработки) или вобще чтонибудь децкое типа SPI,I2c или нахудой конец проверенный веками RS-485.

SPI, I2C не катят однозначно, а вот RS-485 тоже рассматривается как один из вариантов. Насчет полевой шины: интерфейс был изначально разработан для автомобильных дел. Сомневаюсь, что там километры шины

[spf]

SPI, I2C не катят однозначно, а вот RS-485 тоже рассматривается как один из вариантов.

Яйцо с курицей не сравнивайте
RS485 - физический уровень.
CAN - два уровня OSI.(аппаратный арбитраж, фильтрация пакетов и т.п.)

[shans]

SPI, I2C не катят однозначно, а вот RS-485 тоже рассматривается как один из вариантов.

Яйцо с курицей не сравнивайте
RS485 - физический уровень.
CAN - два уровня OSI.(аппаратный арбитраж, фильтрация пакетов и т.п.)

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

[ipc]

SPI, I2C не катят однозначно, а вот RS-485 тоже рассматривается как один из вариантов.

Яйцо с курицей не сравнивайте
RS485 - физический уровень.
CAN - два уровня OSI.(аппаратный арбитраж, фильтрация пакетов и т.п.)

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

Ну CAN положим тоже надо привязывать к программной реализации и это будет посложнее чем протоколы базирующиеся на RS-485.
Я думаю что его использование обосновано только если присутствует один или больше из нижеперечисленных факторов.
1.Нужны сравнительно большие скорости
2.Нужно тащить данные на расстояние првышающее 10 метров
3.В сети нужна мультимастерность
4.Выбранные аппаратные средства имеют его(CAN) на борту бесплатно
5.Существует проблема с помехами
6.Есть желание(установка руководства) неиспользовать малоперспективные(нерасширяемые,слабомасштабируемые или просто подходящие впритык) и уходящие в прошлое программно аппаратные средства.