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

Прочитал много информации по данной теме:
-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, и если да, то какой идентификатор передается в этом фрейме)?

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

Интерфейс работает предельно просто.Принцип передачи пакетный,у каждого пакета есть идентификатор(в зависимости от версии CAN 2.0а или 2.0b) его размер 11 или 29 бит соответсвенно.Поле данных размером от 0 до 8 байт.
Кроме того CAN интересен именно тем что одновременно передавать пакеты могут несколько устройств но будет отправлен в первую очередь тот у кого выше приоритет,остальные пакеты будут отправлены позже.CAN обладает так называемым неразрушающим арбитражем и поэтому ни при каких условиях в нем неможет быть коллизий.
Что касается приоритетов.Чем меньше число записанное в идентификатор пакета тем выше приоритет этого пакета.Но само собой два устройства в сети в один момент времени немогут отправлять пакеты с одним идентификатором,в сетке тут же начнется бардак.
Само собой одно устройство может принимать и отправлять несколько пакетов с разными идентификаторами,но для этого должно быть соответсвующим образом сконфигурировано.В каждом CAN контроллере програмируется скорость обмена и аппаратные фильтры которые предназанчены для отсеивания ненужных устройству пакетов.В случае если в сеть начал передаватся пакет ВСЕ устройства в сети его принимают и сравнивая со своими фильтрами ведут аппаратный отсев.Никто немешает принимать все пакеты и фильтровать их программно но это приведет к излишней потере процессорного времени.Remote Frame оставлен для совместимости и сейчас практически неиспользуется.Работа с ним большего всего похожа на режим хендшекинг(те запрос ответ) существующий в системах на базе RS-485.
Теперь главное.Конечно CAN это очень здорово но это всего лишь интерфейс,для того чтобы начать работать с ним нужно выбрать(или придумать) протокол(те формат передаваемых данных и политику обмена и раздачи идентификаторов).Существует много стандартных протоколов например CANOpen,DeviceNet итд.
Каждый протокол был разработан для решения определенного круга задач и если нехочется изобретать велосипед и к тому же получить устройство работающие в соответствии со стандартом(что позволяет использовать его совместно с другими стандартными устройствами) то стоит немного подумать и в результате выбрать протокол.
Каждый протокол однозначно определяет всю последовательность телодвижений для конфигурационного и информационного обмена в сети и вопроса "как/когда/кому/с каким ID отправить пакет просто неможет возникнуть.
Конечно было бы неплохо узнать о задаче побольше но всеравно немогу удержатся и непосоветовать посмотреть на протокол CANOpen который я юзаю уже несколько лет.

Читай доки на протоколы высокого уровня, там все в картинках.

Пример на пальцах:
В общем виде
- все могут передавать всем
- узел может иметь несколько CANID

Узел 1 -- номер 2: BIN:0010

Узел 2 -- номер 6: BIN:0110

Узел 3 -- номер 7: BIN:0111

Разделим CANID(11бит) на 3 секции :
- Команда, номер данных или т.п. 5 бит
- Адрес назначения 4 бита
- Адрес источника 4 бита

CANID при передаче команды 0x00110 от первого узла второму примет вид

CANID при передаче команды 0x00110 от второго узла первому примет вид


У каждого узла необходимо настроить фильтр, какие биты CANID всех принимаемых кадров с чем сравнивать.




Будут приняты пакеты от всех блоков, предназначенных первому.

Если есть несколько фильтров то можно сделать фильтры на команды:

Команда 00110 от всех блоков


Команда 01010 от всех блоков


Все остальные

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

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

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

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

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

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

Шина параллельная, поэтому понадобятся как минимум открытые коллекторы(или диоды) в цепях выходов(TX), есть где-то в апликухах подобные примеры.

НО!
- Скорость под вопросом...
- Защиты от помех на линии выводов RX/TX под вопросом...

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

С пол года назад тут (на electronix) уже изобретали "дешовый" драйвер, все кончилось покупкой обычного 82C250.

Ну 20 кбод это несерьезно.CAN вобщем довольно быстрый интерфейс и использовать его меньше чем на 125Кбод кощунство.Я например вобще использую 500Кбод.

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

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

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


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

Вопрос был как дешевле реализовать, а не как быстрее. Еще DALI можно помянуть, тоже открытый коллектор. 1200 бод на 300м, зато на любом кабеле и при любой топологии, без терминаторов. C-Bus 5 кбод на 1 км, свободная топология на любой неэкранированной витой паре.

А эти "50 раз быстрее", небось, требуют экранированный кабель с контролируемым волновым сопротивлением, терминаторы с обоих концов и малое кол-во узлов с макс. отводами сантиметров по 10?

Да действительно нужны терминаторы(120 ом) и 60 ом сопротивление линии,хотя на нескольких метрах можно себе позволить на это забить.Но вот то что короткие отводы и экранированный кабель тут уж ничего неподелаеш.Вон то же Modbus+ так вобще еще и тапы(тройники) требует на каждый узел а уж кабель скока стоит это вобще караул.

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

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

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

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

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

"Если сравнивать RS-485 c CAN" - то это на самом деле сравнения яйца с курицей. Сравнение возможно только поле того, как разберёшься в том, что такое "CAN"... После этого пункта само слово "сравнение" будет трактоваться уже иначе.

Важно понять, что RS-485 без использования MODBUS или чего-то подобного есть просто "три проводка", которые соединяют аппаратные UART на двух (или более) MCU. Отличие только в несравнимо больших расстояниях и помехозащищённости. Ничего нового это не добавляет в плане качества связи, гарантированности доставки или чего-либо ещё. Это только ХОРОШИЙ способ растянуть три проводка на N метров.

С CAN ситуация обратная всвязи с добавлением второго уровня OSI - для программы это такой же "чёрный ящик", как и UART:
1. MSG-> bbox
2. bbox->[по шине]->bbox1, bbox2...bboxN
3. у bbox2 во время приёма возникла ошибка (он засомневался) => опять на шаг 2 *Обращаем внимание, что не на шаг 1!*
4. [раз здесь, то послали, или знаем, что не послали]
UART принципиально имеет MSG=1байт, при этом у него НЕТ средств для аппаратной реализации шагов 2 и 3.

!! Уже писал в свой топик. Сюда же дублирую:
----------------------------------------------------------------
Atmel сделала шаг вперёд к gcc и CAN. Конкретно: только что выложили новую версию библиотеки для At90CANxxx для gcc! Качаем, разбираемся.
Похоже, что внутри уже имеются примеры работчего "скелета" программ hello world для работы с шиной.


http://www.atmel.com/dyn/products/product_...sp?part_id=3780
-----------------------------------------------------------------
!!

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

Все-таки решительно надо иметь земляной провод в идеологии RS-485. Это не вполне очевидно, поскольку есть много примеров дифф. линий, в которых нет "земляного" провода. В 4-х проводном варианте земля тоже одна.
Если продолжать "правильный идеологически" разговор, то RS-485 привязан к конкретной физической реализации. CAN оперирует понятием "доминантного и рецессивного" битов, что без проблем имплементируется оптоволокном ("один проводок"). Сигнал (световой импульс) либо есть = "доминантный", либо нет. Использование электрического способа передачи данных для CAN - это одна из многих (гипотетически) реализаций, не являющаяся "единственно правильной" или "плохой, но работающей"....

to: spf. Прочёл внимательно первый пост в этой теме. Еёсли речь идёт о CAN 2.0A, то получается интересная арифметика: "Разделим CANID(11бит) на 3 секции : 5+4+4" =13 в сумме, как я понимаю?
.
Пока не довёл до конца изучение CiA 301, но уже подчерпнул много полезного. Раздел с определением полей внутри CANID пока не смотрел, поэтому не могу говорить на тему реализованного количества поддерживаемых устройств. Спасибо за указание на стандарт.

Правильно подмечено, просчитался, так сказать на ходу сочинял вариант попроще, пользую только 2.0B.

PS:
Дуплексные оптоволоконные элементы слишком дороги, чаще недоступны. Поэтому CAN практически реализуется на двух волокнах -- "два проводка" .

Продолжаю разбираться с CiA 301. Меня смутил порядок следования полей. Основные варианты:
либо A:
1. P бит - ID посылающего => уже работает арбитраж
2. дальше уже неважно, поскольку один может "за раз" послать только 1 сообщение
либо B:
1. Код сообщения => первичный арбитраж по "важности" сообщения
2. ID посылающего => вторичный арбитраж по приоритету источника
3. ID приёмника - уже только для фильтрации на стороне приёмника, не участвует в арбитраже, как и п. А.2.

либо С: (для неравновесной системы [в смысле 3 мастера, 10 слейвов])
1. Указание мастер/слейв (или большее число групп)
2. Код
3. Оставшаяся часть ID посылающего
4. ID приёмника

Похоже, что реализован вариант B, поскольку предполагается, что сами по себе функциональные коды делятся на коды, возможные для 1 мастера и на коды, общие для группы слейвов (B = C при 1 мастере).

Я правильно понял суть?

Если действовать в рамках стандарта CANOpen, фактически надо реализовать часть обязательных функций от CANOpen slave, а работу на PC в качестве мастера исполняет купленная за деньги .dll на их аппаратной платформе?

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

Речь про мой набросок? Если да, то суть верна.

С CANOpen дел не имел, но уверен что мастер может быть реализован не только на PC. Если нет жесткого требования применения CANOpen, то можно посмотреть на открытый стандарт CANkindom и т.п.

Ну незнаю.Сколько раз делал системы на RS-485 никогда с землей особо незаморачивался.Может быть в устройствах без опторазвязки это и критично но теже айсипиконы имеют развязаное питание и драйвер запитывается через преобразователь посему про землю поданую снаружи ничего незнает.

Там все просто но непутайте NID(node ID) и COBID.Все поле идентификатора в соответствии со стандартом можно делить как угодно.Допустим обычно в CANOpen сети может быть до 127 устройств те под NID нужно выделить 7 бит.Остается 4 бита.Т.е прибор сможет иметь 16 разных видов пакетов с уникальными COBID.
Если сократить количество устройств до 63 то типов пакетов будет в 2 раза больше итд.

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

Надо помнить что аппаратный приоритет оперирует со всем полем идентификатора.И COBID выбираются таким образом чтообы более важные сообщения передавались лучше независимо от источника и получателя.Хотя конечно к примеру пакет EMERGENCY имеющий код 0x80 отправленный прибором с NID=1(COBID получится 0x80+1=0x81) будет более приоритетным чем у устройства с NID=2(COBID=0x82).Потому как в сети нет двух одинаковых приоритетов на самом деле их 2^11 штук.

А можно по-подробнее? Почему нельзя? Я не могу разве, имея контроллер с 2.0B, реализовать нужные функции CANopen программно? Сетевой уровень разве не единый?

Сейчас проблематично найти контроллер который неподдерживает 2.0в но я консультировался с представителями CAN-CIA и мне было ясно сказано что выпущеные на сегодняшний день спецификации касающиеся формата идентификатора(COBID) рассматривают только его 11 битное представление.
Конечно можно сделать свою 29 битную реализацию CANOpen но она непройдет сертификацию(CANOpen Conformance Test) и небудет совместима с современными программно-аппаратными средствами.Если это небеспокоит то можно делать все что угодно только называть это CANopen будет нельзя.

А это не Вы писали:
"
Все поле идентификатора в соответствии со стандартом можно делить как угодно.Допустим обычно в CANOpen сети может быть до 127 устройств те под NID нужно выделить 7 бит.Остается 4 бита.Т.е прибор сможет иметь 16 разных видов пакетов с уникальными COBID.
Если сократить количество устройств до 63 то типов пакетов будет в 2 раза больше итд.
"

А вот если это "итд." растянуть на 29 бит? И что, это уже не CanOpen?
Я не говорю про профиль I/O, и то - младшие входы/выходы я буду передавать со стандартными ID, а если мое устройство поддерживает много больше входов/выходов?
Я что, не могу присвоить им (например, динамически) ID с применением 29-бит идентификаторов?
А если я создам свой собственный профиль?

А если у меня "Programmable CANopen Devices", т.е. смотрим DSP302.
Да во всех COB-ID бит 29 говорит: 0 == 11-bit ID (CAN 2.0A), 1 == 29-bit ID (CAN 2.0B)

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

Под стандартом CANOpen в первую очередь подразумевается соответствие профилю DS301 а под сертификацией прохождение теста устройства прогой CANOpen Conformance Test в сертификационной организации CAN-CIA и получения уникального Vendor ID(который кстати используется в LSS).Оба этих критерия и определяют можно ли на фронт панели своего девайса поставить логотип CANOpen и гордица этим до пенсии.

Всё понял, спасибо. Вы меня успокоили