Как написать стек CanOpen?
У меня похожая проблема с этим. Как запрограммировать простой слой CANopen .
Я читаю ответы, но мне нужно самостоятельно программировать слой CANopen, я не могу получить коммерческий. Итак, есть ли основы написания стека CANopen (или слоя, в котором я не уверен в разнице)? Я даже не знаю с чего начать ..
Если это необходимо, вот некоторая информация:
Мое мастер устройство — черная гончая кость с QNX. Я думаю, что в QNX есть общая библиотека CAN, но она не относится к CANopen. А мой раб — военизированный бесщеточный мотор-контроллер. Я пишу на C ++.
У меня есть документация об общих требованиях моей системы.
Имеется 2 RPDO и 4 TPDO, передача является синхронной, нет остановленного режима (поэтому нет сердцебиения и защиты узла), и указывается вся информация сообщения (размер, формат, идентификаторы связанных узлов и т. Д.)
Решение
На самом деле есть как минимум 4 проекта с открытым исходным кодом, которые реализуют CANopen:
- CanFestival является старейшим и, возможно, самым зрелым решением. Лицензия: LGPLv2.
- CANopenNode предназначен для микроконтроллеров. Лицензия: LGPLv2.
- Lely CANopen — это библиотека для реализации мастеров и подчиненных CANopen. Лицензия: Apache версии 2.
- openCANopen — мастер, работающий в Linux. Лицензия: ISC. Примечание: я являюсь автором этого проекта.
Я бы разместил ссылки, но, видимо, мне не хватает «репутации».
openCANopen также включает в себя некоторые утилиты, такие как демон для пересылки трафика по TCP и программу, которая интерпретирует и выводит трафик CANopen на стандартный вывод.
Lely CANopen на самом деле имеет довольно приличное качество кода, и я мог бы использовать его, если бы он был доступен, когда я начал писать свою собственную реализацию. Однако я не пробовал использовать его, поэтому не могу сказать, какая реализация «лучше». Я могу только сказать, что они разные, и один или другой может удовлетворить ваши потребности лучше.
Теперь я сомневаюсь, что любая из этих реализаций будет работать прямо из коробки на QNX. Они либо должны быть адаптированы, либо вы можете скопировать отдельные части кода в свои собственные реализации. По крайней мере, это должно сэкономить вам время.
Другие решения
Быстрый и грязный обходной путь заключается в том, чтобы реализовать только минимум (просто не рекламируйте его как CANopen и не заявляйте о соответствии CANopen):
- Поддержка тех конкретных RPDO / TPDO, которые другой узел отправит / ожидает получить. Используйте фиксированный COBID (CAN идентификаторы). Забудьте о отображении PDO и конфигурации PDO, используйте фиксированные настройки.
- Реализуйте загрузочное сообщение NMT.
- Реализуйте переходы состояний NMT между предоперационным и эксплуатационным (ваш узел должен реагировать на них от ведущего устройства NMT).
- Реализуйте некоторые средства для установки идентификатора узла. Проще всего было бы жестко закодировать его как программную константу.
Если вам повезет, это все, что нужно. Если вам не повезет, будет SDO-коммуникация, а это значит, что вам придется внедрить SDO-протокол и весь объектный словарь. В остальном, вышесказанное довольно просто и не так много работы.
В случае, если вам нужен словарь объектов, тогда не может быть другого способа получить полноценный стек протоколов. Вам также необходимо подать заявку на идентификатор поставщика в CAN-in-Automation, но это единовременный сбор (без лицензионных платежей).