Как написать стек CanOpen?

У меня похожая проблема с этим. Как запрограммировать простой слой CANopen .
Я читаю ответы, но мне нужно самостоятельно программировать слой CANopen, я не могу получить коммерческий. Итак, есть ли основы написания стека CANopen (или слоя, в котором я не уверен в разнице)? Я даже не знаю с чего начать ..

Если это необходимо, вот некоторая информация:

Мое мастер устройство — черная гончая кость с QNX. Я думаю, что в QNX есть общая библиотека CAN, но она не относится к CANopen. А мой раб — военизированный бесщеточный мотор-контроллер. Я пишу на C ++.
У меня есть документация об общих требованиях моей системы.
Имеется 2 RPDO и 4 TPDO, передача является синхронной, нет остановленного режима (поэтому нет сердцебиения и защиты узла), и указывается вся информация сообщения (размер, формат, идентификаторы связанных узлов и т. Д.)

2

Решение

На самом деле есть как минимум 4 проекта с открытым исходным кодом, которые реализуют CANopen:

  • CanFestival является старейшим и, возможно, самым зрелым решением. Лицензия: LGPLv2.
  • CANopenNode предназначен для микроконтроллеров. Лицензия: LGPLv2.
  • Lely CANopen — это библиотека для реализации мастеров и подчиненных CANopen. Лицензия: Apache версии 2.
  • openCANopen — мастер, работающий в Linux. Лицензия: ISC. Примечание: я являюсь автором этого проекта.

Я бы разместил ссылки, но, видимо, мне не хватает «репутации».

openCANopen также включает в себя некоторые утилиты, такие как демон для пересылки трафика по TCP и программу, которая интерпретирует и выводит трафик CANopen на стандартный вывод.

Lely CANopen на самом деле имеет довольно приличное качество кода, и я мог бы использовать его, если бы он был доступен, когда я начал писать свою собственную реализацию. Однако я не пробовал использовать его, поэтому не могу сказать, какая реализация «лучше». Я могу только сказать, что они разные, и один или другой может удовлетворить ваши потребности лучше.

Теперь я сомневаюсь, что любая из этих реализаций будет работать прямо из коробки на QNX. Они либо должны быть адаптированы, либо вы можете скопировать отдельные части кода в свои собственные реализации. По крайней мере, это должно сэкономить вам время.

6

Другие решения

Быстрый и грязный обходной путь заключается в том, чтобы реализовать только минимум (просто не рекламируйте его как CANopen и не заявляйте о соответствии CANopen):

  • Поддержка тех конкретных RPDO / TPDO, которые другой узел отправит / ожидает получить. Используйте фиксированный COBID (CAN идентификаторы). Забудьте о отображении PDO и конфигурации PDO, используйте фиксированные настройки.
  • Реализуйте загрузочное сообщение NMT.
  • Реализуйте переходы состояний NMT между предоперационным и эксплуатационным (ваш узел должен реагировать на них от ведущего устройства NMT).
  • Реализуйте некоторые средства для установки идентификатора узла. Проще всего было бы жестко закодировать его как программную константу.

Если вам повезет, это все, что нужно. Если вам не повезет, будет SDO-коммуникация, а это значит, что вам придется внедрить SDO-протокол и весь объектный словарь. В остальном, вышесказанное довольно просто и не так много работы.

В случае, если вам нужен словарь объектов, тогда не может быть другого способа получить полноценный стек протоколов. Вам также необходимо подать заявку на идентификатор поставщика в CAN-in-Automation, но это единовременный сбор (без лицензионных платежей).

6

По вопросам рекламы [email protected]