ВСТУПЛЕНИЕ

Всё понятно только тогда, когда ничего не знаешь. Так, я считал, что достаточно хорошо разбираюсь в CANOpen, но только до самого того момента, пока месяц назад не начал писать статью. Точнее попытался это сделать. Вот тут-то я оценил реальный уровень своих знаний или, если точнее, его полное отсутствие. Пришлось подождать до окончания разработки первой рабочей версии микроконтроллерного устройства с CAN-контроллером. Не думаю, что смогу сказать что-то умное в этой статье, настолько умное, что нельзя было бы понять самому, но всё же как-то принято у нас читать чужое, а не думать самому. Итак, приступим?..

Замечу сразу, что в этой статье я касаюсь лишь программного уровня. Я не дам вам каких-либо схемотехнических решений или даже программно-технических (вроде процедур посылки CAN-сообщений, настройки контроллера и пр.). Я освещаю лишь протокол, а потому сразу стоит оговориться, что должно быть в распоряжении программиста до начала реализации этого самого протокола. Во-первых, необходимо иметь возможность передавать/принимать сообщения с любым набором данных, любым идентификатором и любого типа (например CAN Remote Frame). Неправда ли неожиданно?.. Во-вторых, необходимо иметь хранилище достаточно большого объёма (от 1 кб) и функции записи/чтения для него. Хранилище это необходимо очень интересной и одновременно очень сложной концепции CANOpen - объектному словарю. Что это такое мы узнаем позже, а пока лишь имейте ввиду. Да, кстати оперативной памяти для CAN-узла тоже надо никак не меньше 100-200 байт. Ну вот, собственно больше ничего и не нужно.

ЭТО ЗАГАДОЧНОЕ СЛОВО - ФРЕЙМ

Фреймами в CANOpen называют.. просто пакет данных, стандартизованный ещё CAN-ом. Иначе говоря, любая информация в сети может передаваться только в определённом "пакете" и пакеты эти называются фреймами. Среди прочего фрейм содержит служебные флаги, т.н. идентификатор объекта (CobID) и данные. Остальное нас волновать не должно - остальным занимается CAN-контроллер; если вы вдруг вздумаете самостоятельно реализовать CAN-протокол, выйдите на улицу, прогуляйтесь по свежему воздуху и подумайте над чем-нибудь более умным.

ВТОРОЕ ЗАГАДОЧНОЕ СЛОВО - CAN-Object

Объектами в CANOpen называют.. фреймы! Нет, крыша у разработчиков сети на самом что ни на есть нужном месте (хорошая такая крыша, кстати). Просто фрейм - понятие общее. Фрейм - это просто пакет данных. А объект - это пакет данных определённого назначения. Разница между фреймом и объектом лексически такая же как между thing и the thing. Фрейм извещающий об ошибке - просто фрейм и одновременно Emergency Object. Фрейм команды исполнительному устройству - просто фрейм и одновременно PDO (Process Data Object).. Вот ещё пара полезных объектов, которые мы будет рассматривать и пытаться применить на практике: NMT (Network Managment T..), SDO (Service Data Object), BootUp Object и Sync Object. Без реализации этих объектов сеть можно считать бесполезной и не соответствующей стандарту CANOpen. Это - базис.

ТИПЫ CANOpen-СОЕДИНЕНИЙ МЕЖДУ УЗЛАМИ

Допустим у нас есть в сети два CANOpen узла. Кстати, из вредности я буду называть узлами - модули обработки определённых объектов в устройстве, а не сами устройства в сети; так, любое грамотное устройство будет содержать по крайней мере 5-6 узлов: PDO узел, SDO узел, NMT узел, Emergency узел и т.д. Так вот, есть у нас два узла одного объекта на разных устройствах в сети (это я сказал?..); нам нужно организовать общение между ними. Но как определить кто должен начинать говорить - а кто отвечать. Или может они оба могут когда хотят болтать? На самом деле существует определённый набор схем общения и почти за каждым объектом закреплена своя схема.

Первой схемой рассмотрим самое простое - модель Client/Server. Всем знакома эта модель, но на всякий случай повторим. Основная информация находится на сервере. Только клиент может начинать диалог и всё, что он может делать - это обращаться к определённым данным на сервере (читать/записывать). Как видите для PDO эта схема уже не пройдёт - команды посылать мы не можем, а реализовывать их через какую-нибудь ячейку памяти на сервере могут только извращенцы. Зато, как мы потом увидим, эта модель общения идеально подходит для SDO, который и предназначен для работы с таблицами данных. Отличительной особенностью модели является обязательный ответ сервера на любой объект клиента (не зависимо от того, нужен этот сам ответ или нет).

Вторая схема - Master/Slave. Здесь уже всё несколько туманнее. Модель ничего не говорит об типе передаваемых данных. Это могут быть и команды, операции над таблицами данных как в Client/Server, и всё что вам заблогорассудится. Основное условие - передачу инициирует только мастер. Slave может только отвечать (или вообще под дурика косить - молчать). Если мастеру нужно передать какую-нибудь информацию в slave, то он просто посылает объект с 0-8 байтами данных; при этом slave не имеет право орать что бы то ни было в ответ. Если же ему нужно что-то получить от slave'а, то он посылает Remote Frame, о котором будет сказано ниже. Вот тут уж slave'у дают слово и он может высказать всё, что хочет. Даже не может - обязан.

Третьей и последней моделью общения в сети является модель Producer/Consumer. Здесь всё точ-в-точ как в Master/Slave модели (в роли мастера выступает, разумеется, producer) лишь с одной отличительной особенностью: Remote Frame имеет право посылать не producer, а consumer. То есть, поставщик информации ничего не может получить от потребителя (он о нём ничего и знать не будет кроме самого факта существования), зато инициировать передачу информации (повторюсь: исключительно от поставщика к потребителю) может и тот и другой.

Вот собственно и все модели общения.

Продолжение следует...