Реализовать CANOpen на CAN МК Freescale DSP56F805, Разобрался с аппартным CAN, надо накрутить поверх CANOpen Опции

[syoma]

Было бы очень интересно взглянуть и сравнить!

Дык чего там сравнивать - взял исходники на CANконтроллер и Таймер со всем известной библиотеки FWlib от ST. Все остальное - родное CANfestivalевское.
Ладно, исходники дров выложу вечером, так как я еще туда кучу всего приделал, чего в CANfestivale не было - запись и чтение параметров из EEPROM - приделал пример эмуляции от ST. Еще добавил управление светодиодиками по DS303-3.
Единственное - обработка Heartbeat в CANfestival не очень реализована - добавил обработчик ошибки по Heartbeatу.

Вот что хочется изменить - не нравится мне функция посылки сообщений от ST - в F103 есть всего три буффера, и если они полны, то новое сообщение можно потерять. Я думаю - либо сделать посылку блокируещей - чтобы все ждали пока сообщение отошлется, либо добавить FIFO буфер побольше.

[Forger]

Вот что хочется изменить - не нравится мне функция посылки сообщений от ST - в F103 есть всего три буффера, и если они полны, то новое сообщение можно потерять. Я думаю - либо сделать посылку блокируещей - чтобы все ждали пока сообщение отошлется, либо добавить FIFO буфер побольше.

Я тоже сталкивался с этой проблемой. Решил применением программного FIFO как на передачу и на прием заодно.

Ну, а щас сделано у меня по-другому: использование RTOS позволило использовать ее встроенные сервисы для работы очередями сообщений. А обертка вокруг них создана на базе smart pointer (только C++). Теперь не нужно беспокоиться за валидность указателя на очередное сообщение: если хоть кто-то его еще использует, оно лежит в буфере. А как только все, кому нужно было сообщения, "отстали" от него - это сообщение автоматом освобождается из очереди. Работает изумительно! Оптимизатор компилятора прекрасно работает, удаляя, казалось бы, избыток кода.

[syoma]

обертка вокруг них создана на базе smart pointer (только C++).

К сожалению, мне это пока не грозит. Мне пока достаточно мучений с обычными С указателями.

[Forger]

К сожалению, мне это пока не грозит. Мне пока достаточно мучений с обычными С указателями.

Я тоже мучался на чистом С, пока не начал всерьез осваивать С++ не под ПК, а именно под обычные МК.
После перехода, полного перехода на С++, многие детские болезни из С по-просту отпали

[DmitryDI]

Привет. Если кому интересно.
Короче запустил я этот CANfestival на STM32F103. Заняло это дело 2 месяца подходов к компьютеру и чтения документации и аж 2 дня на перелопачивание драйверов на CAN контроллер и таймер. Исходники могу выложить.
Аж сам удивился, но буквально при первой компиляции эта штука запустилась и начала генерить heartbit и даже реагировать на NMT команды.
На следующий день запустил PDO обмен - тоже работает без проблем. Несмотря на приличную навороченность (стек занял 20кБ места в МК) стек пока выглядит довольно стабильно. Работает все - и SDO и PDO и NMT сервисы (на слэйве).
Вчера даже получилость прикрутить к нему запись параметров во FLASH, а-ля EEPROM. Правда не все скопом, а для заданных объектов при записи.
2 Штуки мне очень понравились по сравнению с CanOpenNode.
1. Во-первых тут есть редактор eds файлов (правда хитро устанавливается, но вполне сносно) который позволяет создать профиль своего устройства и затем по этой информации генерирует .с и .h файлы для стека и сам .eds файл. Работает очень не плохо. Созданные файлы просто копируются в проэкт и перекомпилируются, а eds файл скармливается программе - монитору CANopen шины. О ней дальше внизу.
2. Во-вторых CANfestival имеет намного более развитые возможности. Например программа пользователя общается со стеком только через глобальные переменные, которые являются объектами словаря. При приходе нового PDO переменные сами собой обновляются. При изменении переменной программой - нужно только выполнить функцию послыки PDO и CANfestival сам определит, какая переменная в какой PDO пойдет и нужно ли его слать. Даже по таймеру все работает.
В общем я доволен пока.
Кстати насчет программы. Есть такой сайт: http://www.canwizard.de Там можно скачать одноименную программу.
Она хоть и предназначена для лифтов, но достаточна полезна и для простых CANopen сетей. Она позволяет подключаться к CANopen сети, искать узлы, читать eds файлы, генерить NMT и LSS команды, общаться с любыми узлами по SDO протоколу и т.д. Даже софт по сети обновлять может. Правда лог файлы она не ведет. Единственное ограничение, что бесплатная версия может работать толька максимум с тремя узлами. Поддерживает она Vector, Ixxat, Peak адаптеры.

Добрый день!

Я так же запустил CANfestival в AT90CAN128. Все как бы работает. Но непонятен ряд вещей. Если с контролер в мастер шлеца PDO, то как контроллер узнает о том, что PDO дошло – в программе CAMmonitor – никаких подтверждений я не видел? Как этим протоколом передавать большие объемы данных – есть ли стандартные профили? Как передавать метку времени?
C уважением

[syoma]

Если с контролер в мастер шлеца PDO, то как контроллер узнает о том, что PDO дошло

Насколько я понял PDO протокол - подтверждения в нем не предусмотренно. То есть - никак. Но как пишут умные книжки - в этом нет смысла, так как применение PDO подразумевает применение Heartbeat - то есть мониторинга состояния узлов. И если принимающий узел будет мониторить все узлы, с которых он принимает PDO, то вероятность непринятия PDO будет весьма низка.
Также можно настроить event таймер, чтобы PDO передавалось не только по изменению, но и периодически.

Как этим протоколом передавать большие объемы данных

PDO для этого не предназначен. Смотрите SDO - это типа peer-to-peer соединения. По нему можно передавать большие объемы данных. Вроде в CANfestival реализован и клиент и сервер, но я еще не разбирался.

[slimjack]

Добрый день!
Не хотел плодить новые ветки и решил написать сюда, т.к. похоже тут собрались знатоки CANopen.
Не ругайте сильно (возможно будут глупые вопросы), но очень хочется получить простое, доступное объяснение основ CANopen. Я перерыл форум, почитал стандарты, читал статьи, но все равно как-то все смутно. Правда я не разглядывал исходники (CANfestival и CANopenNode).
Попытаюсь объяснить как я понимаю CANopen, попутно задавая вопросы в непонятных местах.


Итак, пользовательское приложение не видит сеть напрямую - оно видит словарь обектов, который представляет собой массив переменных, которые связаны с параметрами, допустим, технологического процесса (температуры, токи и т.д.), а также с параметрами настройки режимов работы самого устройства. Т.е. (как я понимаю) часть словаря - личные данные конкретного устройства, а другая часть - общие данные всей сети (т.е. такие же данные могут находиться и в словаре другого устройства). Т.о. пользовательскому приложению не нужно знать о существовании сети, оно просто берет данные из словаря (например, чтоб узнать текущую влажность воздуха) или записывает данные в словарь (например, давление масла, если это давление измеряется непосредственно данным устройством). Перемещением данных между словарями занимается CANopen.
Обмен между словарями производится посредством сетевых объектов PDO и SDO.
PDO сообщения могут переносить до 8 байт полезной информации и используются для передачи данных о тех. процессе. PDO являются широковещательными сообщениями. Источником (производителем) PDO должно быть устройство которое непосредственно вычисляет или измеряет какой-то параметр, входящий в PDO. Каждый PDO имеет свой уникальный идентификатор (именно он и указывается в качестве идентификатора в сообщении CAN). Т.о. устройство измеряет какие-то параметры и пишет их в словарь. В этом же словаре хранится информация о том, какие данные, в каком порядке и в какое PDO нужно упаковать. Также для каждого PDO существуют правила отправки в сеть (по времени, по изменению, по синхроимпульсу и т.д.). Если выполняется условие отправки, CANopen упаковывает данные со словаря в PDO и отправляет их в сеть. Другие устройства в сети, если они настроены на прием данного PDO (определяется по идентификатору), принимают это PDO и распихивают его содержмое по словарю в определенные ячейки. Теперь вопрос: для чего разделяются PDO на входящие и исходящие (Rx Tx)? Правильно ли я понял, что идентификатор PDO не подразумевает привязки к устройству (т.е. в нем отсутствует информация, о том кто именно в сети отправил PDO)?

Если требуется передать какую-то часть словаря размером более 8 байт, необходимо применять SDO сообщения.
Существует два типа SDO (для передачи информации и для подтверждения). В виду необходимости подтверждения SDO подразумевает только соединение точка-точка. Через SDO одновременно передается только один объект словаря (а в PDO можно несколько), но он может быть большим (более 8 байт).
Дальше у меня практически одни вопросы.
1. При передаче SDO, что из себя представляет идентификатор сообщения? Есть ли в нем адрес конкретного устройства?
2. Какое отношение приложение имеет к SDO?
3. Как устанавливается связь между SDO и объектом словаря?

Просьба - разъясните мне "на пальцах", я не смог найти ответы на свои вопросы из спецификаций.

[Ruslan1]

вы очень все внятно разложили по полочкам

Мой опыт разработки кэн-приложения был таков:

Исходники
1) использовал CANopenNode. У меня тоже PIC-процессор, но другой. Но переписывать ничего не пришлось, забегало сразу.
2) там же редактор словаря, мощная штука, без этого загнулся бы. Но нужен FireFox.
3) даже автора нашел на каком-то форуме, на письма очень быстро отвечает

Документация по протоколам
1) протоколы запросил прямо на их сайте (www.can-cia.org) при регистрации. Любопытно, они очень внимательно проверяют чего там в регистрации им пишут. Мне прислали запрос, почему указанный мной почтовый адрес не совпадает с адресом, написанном на указанном мной www сайте. Для ускорения позвонил им голосом, объяснил, через 10 минут все выслали
2) советую посмотреть также профили, если подойдет готовый- то меньше придумывать придется.
3) ну конечно и дополнительно неофициально гуляющими версиями документации пользовался.
4) посмотрите аппноты, мне помогло: http://www.microcontrol.net/en/know-how/canopen.html
5) еще цикл статей "CAN basics", 8 частей : http://www.can-cia.de/index.php?id=66 ( от "CAN basics: CAN in Automation history and CAN, part 1 of 8" до "CAN basics: Traffic control, part 8 of 8")

Внутрь исходников практически не лазил, по мелочам под себя дорисовывал (ну и LSS протокол написал). Как результат- от запроса документации до сдачи пилот-проекта прошел месяц (вместе с железом). Супербыстро, учитывая что до этого ничего с кэном я вообще не делал.

Правильно ли я понял, что идентификатор PDO не подразумевает привязки к устройству (т.е. в нем отсутствует информация, о том кто именно в сети отправил PDO)?

ага.

Я не пользовал SDO, про это не подскажу. А Вы уверены что оно Вам надо (SDO)?

[slimjack]

А Вы уверены что оно Вам надо (SDO)?

В сети предполагается два "умных" устройства. Одно собирает инфу с цифровых датчиков, а второе - тоже что-то типа датчика, но оно собирает высокочастотные куски осциллограмм (т.е. размер большой, до 1 Мб) и некоторые из них отправляет на первое устройство. Т.е. без SDO никак.

По поводу PDO можете подсказать для они чего разделяются на входящие и исходящие (Rx Tx)? Какой смысл? Я пока для себя понял, есть PDO с каким-то идентификатором. Он попадает в сеть (неважно откуда) и тот, кому надо, подбирает его. Зачем тут делить на входящие и исходящие?

У меня есть устройство (датчик) с контроллером ATTiny (128 б ОЗУ), получится ли реализовать хоть что-нибудь от CANopen?

[Forger]

По поводу PDO можете подсказать для они чего разделяются на входящие и исходящие (Rx Tx)? Какой смысл? Я пока для себя понял, есть PDO с каким-то идентификатором. Он попадает в сеть (неважно откуда) и тот, кому надо, подбирает его. Зачем тут делить на входящие и исходящие?

У каждого узла в сети CANopen есть всегда 4 TPDO и 4 RPDO. Данные, которые отправляются узлом в сеть - именуются TPDO, принимаемые из сети - RPDO. Какие именно данные (точнее, объекты словаря) в них входят - настраиваются один раз после сброса устройства мастером сети CANopen (в подавлющем числе случаев мастер всегда один) через SDO. Далее настроенные таким узлы мастер переводит в состояние Operational, в котором данные уже идут к узлу и от узла только по PDO (в подавлющем числе случаев). CANopen практически не используются для передачи огромных массивов данных. Для этого лучше сделать свой простой протокол, используя шину CAN. Хотя в документации на CANopen я находил такой объект словаря, предназначенный для удаленной смене прошивки узла.

У меня есть устройство (датчик) с контроллером ATTiny (128 б ОЗУ), получится ли реализовать хоть что-нибудь от CANopen?

Все возможно
А вам так важен именно CANopen?
Я бы в вашем случае значительно быстрее "накидал" свой простенький протокольчик для указанной задачи, чем пытался бы использовать CANopen, т.к. на это у меня вышло бы гораздо больше времени и сил.
Исключение составляет тот случай, когда ваш узел должен встраиваться в УЖЕ существующую сеть CANopen.
Распишите по-подробнее сеть, в которой все это будет делаться. Какие узлы, сколько их всего?

[slimjack]

Все равно не понял на счет PDO.

У каждого узла в сети CANopen есть всегда 4 TPDO и 4 RPDO.

Значит все-таки в идентификатор PDO закладывается nodeID? Но зачем? Кому нужно знать с какого узла пришли данные?

Данные, которые отправляются узлом в сеть - именуются TPDO, принимаемые из сети - RPDO.

Кому нужна информация о направлении сообщения? Зачем разделять на входящие и исходящие? Если устройство передает PDO, то, естественно, оно знает, что для него это сообщение исходящее. И совсем непонятно, что такое входящее сообщение? Что устройство с nodeID=99 может принимать только те PDO, в идентификаторе которых зашит nodeID=99? А если оно хочет принять PDO от других устройств в сети?

А вам так важен именно CANopen?

Ну может в первом варианте нет, но в итоге понадобится гибкость и совместимость.
Проектируется распределенная система сбора данных. Разрабатывается не одно устройство, а несколько - контроллер и несколько типов датчиков. Предполагается возможность использования устройств ввода-вывода сторонних производителей (хотя это не обязательно). Но система должна быть масштабируема и универсальна. Если разрабатывать свой протокол, в итоге получу исковерканую версию какого-нибудь стандартного протокола. Зачем тогда мучаться - можно использовать уже готовый протокол.

И по поводу SDO. Правильно ли я понял - каждому узлу в сети назначается по 2 SDO (не более)?

[Forger]

Значит все-таки в идентификатор PDO закладывается nodeID? Но зачем? Кому нужно знать с какого узла пришли данные?

CANopen изначально проектировался для ОДНОГО мастера и кучи узлов.
Поэтому в RPDO nodeID хранит тот узел, которому это PDO предназначен. TPDO - от какого узла эти данные идут, чьи они.
Так мастер и другие узлы точно знают предназначение кадров.

Кому нужна информация о направлении сообщения? Зачем разделять на входящие и исходящие? Если устройство передает PDO, то, естественно, оно знает, что для него это сообщение исходящее.

Если вам не нравиться или не понятна логичность CANopen - используйте другой протокол или пишите свой.
В сети полно инфы по CANopen, даже на русском, ищите, и все получится

И совсем непонятно, что такое входящее сообщение? Что устройство с nodeID=99 может принимать только те PDO, в идентификаторе которых зашит nodeID=99? А если оно хочет принять PDO от других устройств в сети?

Изначально в шине CAN ВСЕ узлы могут принимать ВСЕ кадры. CANopen тут не накладывает ограничений.

Проектируется распределенная система сбора данных.

Если уж так нужен CANopen, то есть простое решение (я сам делал что-то подобное): через один PDO организовать свой минипротокол: например, 1-й байт (а всего из в PDO может быть до 8 включ.) - код команды, 2..4 байты - адрес, 5...8 байты - 32-битное слово данных. А в конце желательно передавать контрольную сумму всего массива данных. По SDO выйдет значительно дольше.

p.s. Я вижу, что вам пока туго даются даже базовые понятия CANopen. Поэтому, может оказаться, что эта задача вам пока что будет не по силам. Особенно если сроки жесткие.
Но, в любом случае, желаю удачи

[slimjack]

Если вам не нравиться или не понятна логичность CANopen

Дело не в этом-просто не до конца понятна идеология.
Но спасибо за советы. Буду копать дальше.

[syoma]

CANopen изначально проектировался для ОДНОГО мастера и кучи узлов.

Откуда Вы это взяли? CANopen никак не лимитирует мультимастерность CANа, а наоборот ее расширяет.
PDO расширяются на исходящие и входящие по одной простой причине - так их легче обрабатывать в устройстве. А на самом деле каждый PDO уникален - имеет свой идентификатор и набор данных. Разделение сделано для того, чтобы пользователь знал - источником данного PDO может быть только один узел в сети. В нем и настраивается TPDO с определенным идентификатором - необязательно соответсвующему адресу узла и совсем необязательно ограничение в 4шт на узел. Может быть и 8 и 100 TPDO в одном узле. Приемником же данного PDO могут быть множество узлов в сети. Чтобы они начали принимать это PDO - в них настраивается RPDO с таким же идентификатором, как уже указанное TPDO. Таким образом устанавливается связь между узлами.
А насчет SDO обмена - к сожалению в моей системе он нужен только для конфигурации. И для этого есть комп с купленной конфигурационной программой и CAN-адаптером. Когда я запустил CANfestival, SDO обмен заработал сразу и комп увидел мои устройства и смог обмениваться с ними по SDO. Как он это делает, я к сожалению не вникал.
Но по идее SDO - это как доступ через заднюю дверь ко всему словарю. Поэтому:

2. Какое отношение приложение имеет к SDO?

У меня - никакого. Т.е SDO обмен производится вообще без участия приложения. Так как при этом сам стек обрабатывает сообщения и посылает ответ.

3. Как устанавливается связь между SDO и объектом словаря?

Тот кто спрашивает - сам определаяет какой объект он хочет прочитать или записать.

Я не могу сказать, как все это дело будет работать с данными объемом 1Мб. Но с меньшими данными это работало так:
У меня было желание присвоить имя плате. В итоге я создал тектовый объект в словаре с тектом: "Тестовая плата №1. Разработчик ФИО"
В eds файле этот объект был описан, как текст с неопределенной длиной.
Размер этого обхекта более 8 байт. Естественно через PDO я его не передавал и ничего в программе с ним не делал. Но когда конфигурационная программа с компа сконнектилась с моим устройством, то она просканировала весь словарь согласно eds файлу и прочитала мой текст - я его увидел на компе. Как она это сделала - без малейшего понятия. Но это работает!

Есть неплохой интернет курс по CANopen - я постараюсь ссылку найти.
Ну и все спецификации есть тут, для Своих.

[slimjack]

Спасибо!
Похоже, что уже для меня все стало ясно.
Еще вопрос - словарь ограничивает объем данных для одной ячейки или нет? Можно ли тот же 1 Мб в нем хранить?

Есть неплохой интернет курс по CANopen - я постараюсь ссылку найти.

Буду благодарен!