Не понимаю смысл этого куска. ENFG никогда не будет 1, если в CANGCON записать 0. Или я ошибаюсь?

если кан находится в рабочем режиме ENFG=1
когда записываем 0 в CANGCON дается команда войти в ресет моде
пока кан входит в ресет моде ENFG будет 1 надо ждать пока не станет 0

Позволю добавить от себя ;-) Я разобрался с работой CAN за неделю. Из своего непонимания почти всё было ликвидировано. Вопрос о негарантированности доставки одному из слейвов (получателей) приобрёл другой характер:
CAN шина ГАРАНТИРУЕТ, что все приёмники РАБОТАЮЩИЕ В ЭТОТ МОМЕНТ на шине успешно получили сообщение. Никакой информации о количестве узлов, получивших сообщение НЕТ! В контексте поего предыдущего вопроса из этого можно сделать вывод, что надо после этого уметь на мастер узле принять N подтверждений о доставке (узел мог просто потерять питание!). В противном случае надо принять решение о дальнейшей работе всех устройств.

Сложность реализации оказалась незначительной, но до конца я пока не разобрался ( скажем, как надо распределить MOB'ы если посылающий RDF должен принять ответ на него и прочие мелочи), поскольку в данный момент после успешного испытания простейшего решения на базе "один сообщил => другой принял" работы ведутся над другими частями.

PS Отдельное спасибо НПП Славна (http://www.slavna.ru). Успешно получено купленное у них USB->CAN устройство. Пока не испытано.

Мне кажется что в данном случае имеет место попытка использовать CAN как обычный RS-485 с технологией запрос-ответ.Прелесть CANа как раз в том что проблемы целостности сети и работоспособности узлов решаются на более высоком уровне(на уровне протокола).Физическая линия гарантирует и так все на свете.Допустим в протоколе CANOpen существует по крайне мере 2 способа слежения за работой узлов это Nodeguarding и Heartbert.Первый заключается в периодичном опросе всех узлов мастером и получении их текущего статуса(режима работы) а второй заставляет slave-ы постоянно отправлять свой статус самостоятельно(из названия понятно что это как серцибиение).Кроме того в случае перезагрузки прибора он обязан отослать пакет BootUp который можно отлавливать.
В крайнем случае можно использовать RTR но это уже в чистом виде RS-485.

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

Привет всем! Идейные соображения по поводу CAN меня не интересуют, такой я вот Пацак :-)
Авот в материальном плане чем смогу тем и помогу. Работал когда то я в команде которая разрабатывала Банковскую Автоматизированную Распознающую Систему. Так вот в ней все устройсва были подключены к хосту через CAN. Я уже давно там не работаю но исходники как ниского так и высого уровня есть. Может поработаем вместе. Прошу не судить строго но у меня есть свои интерсы в этом вопросе.

Несовсем в тему но всетаки вопрос.А незавалялось ли с тех времен какого нибудь фирменного софта например IXXAT CANAnalizer или Vector CANErator а может быть CANOpen Conformance Test.

Совершенно верное суждение насчёт протоколов высокого уровня. В CANOpen, DEVICENET это всё есть. Единственная сложность в том, что нет готового OpenSource верианта, если я правильно понимаю суть проблемы. Иными словами если надо использовать MODBUS/485 - пожалуйста. За час работы в сети я нашей 4 независимые реализации. Полностью все спецификации выложены на сайте и т.д. С CAN ситуация иная. Пути:
1. Иметь МНОГО времени и реализовать либо свой CANOpen
2. Иметь МНОГО денег и купить уже реализованный (как я понял, минимум $850 за библиотеку без исходников)
3. Иметь большой умный мозг и МНОГО времени - придумать некое "подмножество" протокола CANOpen и реализовать его.
4. Ограничиться самым примитивным решением - взять только DataFrame от физической части CAN и сделать только HeartBeat для гарантированности работы всего "в целом".

Можно даже BootUP не использовать - в некотором смысле при фиксированном наборе устройств, при отсутствии одного по HeartBeat, работа всей остальной совокупности уже невозможна. В этом смысле BootUP заменяется просто "push'ингом" HeartBeat'ов от слейвов к мастеру. Даже не требуется RDF использовать для этого, шина и так рассчитана на большую пропускную способность.

Ну для реализации своего CANOpen варианта нужно не так уж и много времени благо часть функциональности можно неделать что допускается спецификациями.Но в любом случае вопрос звучит по другому а именно для чего все это,какую задачу вы пытаетесь решить.Пару лет назад когда в моей лавке встала задача собрать измерительную систему тоже были варианты.
1.Купить готовую или собрать из покупных модулей
2.Купить исходники или библиотеки для убыстрения разработки
3.Создать свою с нуля определившись с технологией,интерфейсами и протоколами

В результате
1.Был произведен маркетинг и сравнение существующих систем и решений
В силу ряда причин готовое решение найти неудалось и было принято решение создавать свое
2.Была выбрана распределенная технология измерения(в силу конструктивных особеностей контролируемого обьекта)
3.Было проведено сравнение полевых шин и сделан выбор(CAN по соотношению цена качество оказался на коне)
4.Было проведено сравнение протоколов и по характеристикам и количеству/качеству существующего готового(само собой платного софта) а также ареалу рапространения был выбран CANOpen
5.Был проведен анализ функциональности(по пригодности для наших задач) готовых библиотек и их стоимость а также сроков выделенных на реализацию проекта после чего было принято решение писать протокол самостоятельно.
6.Была закуплена документация(спецификации CIA),интерфейсные платы для верхнего уровня и фирменная прога(Ixxat CANOpen Studio) для первоначально проверки реализации своего протокола.

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

Тогда можно попросить указать цены на вами закупленное решение:
1. Цена на плату, на библиотеку, на документацию (примерно до +- 50$). Сайт datamicro оказался очень сложен в использовании :-)

В нашем случае вроде нет необходимости делать стыковку с приборами не своего изготовления, поскольку они "по сути" не применимы в данном случае. Скорее всего это будет сделано при переходе на "следующий" виток развития, если вообще будет сделано. На данном этапе скорее всего будет доделана работа с CAN на основе At90CAN128 (примерно шесть экземпляров на одну систему), сбор данных температуры и прочего осуществляется по Dallas 1-wire, а самый дешёвый датчик с CANOpen стоил почти 800euro, что пока излишне ;-)
В качестве USB-PC будет устройство от slavna.ru - они предоставляют "каркас" программы на VC, так что можно очень быстро начать его использовать, поскольку код на C портируется с MCU без изменений, только интерфейсная часть будет другой.

Плата IXXAT USBtoCAN(2 канала с опторазвязкой) ~250 евро
Плата IXXAT USBtoCAN compact (1 канал с опторазвязкой) ~200 евро
Плата Adlink 7841 (два канал с опторазвякой) ~150 евро
CANOpen Configuration Studio ~1000 баксов(точно непомню)
СANOpen CIA Standart 200 евро + годовая подписка

Столько плат было нужно для разных целей,USB для использования с командировочными ноутбуками(и фирменным софтом) а PCI для рабочих станций на которых ведется калибровка и настройка приборов.

Средняя стоимость прибора(1-2ух канальных) получилась 200 баксов.
При выпуске около 2000 штук.

Цена действительно оказалась более чем приемлемой. Я полагал примерно 2x-4x диапазон. При этом раскладе это <$1500 для начала работы, что приемлимо даже для личной разработки.

Осталось разобраться в следующем: физически CANOpen - это только data frame, которые ходят по шине. Никакая конкретика непосредственной физической реализации аппаратного уровня его не интересуют. Из этого можно сделать вывод, что и код на C должен быть одинаковым как для PC карты, так и для MCU. У них же (если я правильно понимаю) предлагается отдельно "стандарт" и отдельно "он же реализованный под Win32 с закрытым кодом", отдельно "софт мониторирования пакетов и проверки соответствия работы устройства стандарту", ну и платы, разумееется.

Если внимательно посмотреть на это, то вместо их библиотеки можно было бы использовать C версию кода, но они его не предоставляю. Я правильно понимаю ситуацию, что фактически надо реализовать 80% их библиотеки, являющейся кросс-платформенной, в каждом проекте?

Нешёл очень интересный сайт с большим чилом БЕСПЛАТНОГО софта (ограниченного на 125к/бит и временем работы), называется port.de. http://www.port.de/engl/canprod/content/software.html
Пока не ясно, но возможно, что предлагают недорогую кросс-платформенную реализацию на С.

Сообщение отредактировал dormouse - Apr 5 2006, 08:37

Да для CANOpen вобщем по барабану на физическую линию это всего лишь формат пакетов,структура и диапазон идентификаторов и временные параметры(таймауты) передачи.
Но есть небольшой нюанс.Обычно в приборах реализуют CANOpen Slave а на PC CANOpenSlave+CANOpenMaster.Мастер как таковой очень громоздок и реализовать его в полном обьеме внутри микроконтроллера из среднего ценового дивапазона проблематично.То же касается готовых библиотек и патентованых кроссплатформенных исходников.Сами продавцы пишут что только CANOpen практически на любой платформе займет не менее 64K(это плата за универсальность).В моем случае узкоспециализированный и конкретно заточеный CANOpen(с приличной функциональностью) около 10Кслов(вместе со словарем).
Вобще CANOpen неоднородная вещь.Это набор подпротоколов(те вариантов обмена) которые используются для разных целей.Например.
SDO-протокол для конфигурационного обмена
PDO-протокол для обмена данными
NMT-протокол для управлению сетью и состоянием узлов
LSS и LMT -протоколы для раздачи идентификаторов(NID Node ID) и смены скорости сети.
Необязательно реализовывать все,но часть полюбому нужно будет сделать.Фирменные библиотеки содержат все и потому такие громоздкие.

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

Вот кароче бесплатная дока по CANOpen кому интересно можете почитать

Что касается ресурсов.
Фирма Port предлагает много но вот купить это у нас проблематично.
Лучше смотреть на http://www.vector-cantech.com/ и www.ixxat.com

Сорри. Облажался. С CAN контроллером разобрался. Все работает, только у Atmel'a даташит не достаточно детальный.

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


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

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