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

Прочитал много информации по данной теме:
-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 который я юзаю уже несколько лет.

Сообщение отредактировал ipc - Mar 24 2006, 13:44

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

Пример на пальцах:
В общем виде
- все могут передавать всем
- узел может иметь несколько 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_ раз быстрее...

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