[Phantom_ 0]

В этом МК есть аппаратный CAN интерфейс. С ним я разобрался, вот только могу пользоваться им лишь для связи с другим таким же МК.

А мне требуется интегрироваться в сетку с протоколом CANOpen.

Вопрос: Возможно ли такое выполнить ? И как ? Очень нужны базовые примеры и документы.

Сам я пока лопачу документацию. Но без вашего опыта буду долго возиться.

Уважаемое сообщество, прошу помощи.

[Седой 0]

В этом МК есть аппаратный CAN интерфейс. С ним я разобрался, вот только могу пользоваться им лишь для связи с другим таким же МК.

А мне требуется интегрироваться в сетку с протоколом CANOpen.

Вопрос: Возможно ли такое выполнить ? И как ? Очень нужны базовые примеры и документы.

Сам я пока лопачу документацию. Но без вашего опыта буду долго возиться.

Уважаемое сообщество, прошу помощи.

Документацию на что?

[AlexandrY 2]

CANopen так с бодуна не делается.

Помимо стека с реализацией коммуникационного уровня по спецификации DS301

нужно еще реализовать профиль из набора спецификаций DS4XX

Ну и еще понадобится конфигуратор на PC для формирования dcf файлов

Ну и менеджер сети нужен как минимум для отладки.

Т.е. солидный набор тулсов. Возьмите лучше готовый стек CANopen .

 

В этом МК есть аппаратный CAN интерфейс. С ним я разобрался, вот только могу пользоваться им лишь для связи с другим таким же МК.

А мне требуется интегрироваться в сетку с протоколом CANOpen.

Вопрос: Возможно ли такое выполнить ? И как ? Очень нужны базовые примеры и документы.

Сам я пока лопачу документацию. Но без вашего опыта буду долго возиться.

Уважаемое сообщество, прошу помощи.

[Phantom_ 0]

Спасиб за мнение.

На данный момент смотрю в сторону CANFestival.

[Forger 17]

На данный момент смотрю в сторону CANFestival.

 

Тогда уж лучше CANopenNode - в нем исходники гораздо внятнее и есть хорошая документация по ним и примеры.

Хороший покупной стек стоит очень дорого. На практике не требуются абсолютно все фичи CANopen. Да и не так уж и сложен CANopen. А сложности в нем другого рода: перестраховки на самые "нелепые" случаи работы других узлов и самого мастера сети, исчерпывающий набор методов отправки/приема важных и критичных ко времени данных и т.п. Но в большинстве узлов (девайсов) это все не нужно и хватает основных базовых возможностей CANopen (например, см. стек от Microchip).

 

В моем случае я реализовывал CANopen slave самостоятельно (узлы для работы с ПЛК под CoDeSys).

На полное понимание CANopen ушло около двух недель. Вполне достаточно одного документа DS301 и какого-нибудь "профильного" документа, например, DS401.

Еще примерно месяц на реализацию (на С++ удалось отказаться от шаблонов).

Конечно похвастаю: у меня получилось абсолютно кросплатформенное решение, хотя это - и не цель.

Я не все сделал (просто не требуется для текущего проекта), но спроектирован практически весь стек CANopen. На одном кристалле могут абсолютно без ущерба друг другу работать более одного стека, каждый из которых может висеть на своем CAN драйвере (мне это нужно для реализации надежной сети с дублированием шин CAN - девайс далеко не бытового назначения).

 

Вот пример простейшего проекта на моей реализации стека:

// Экземпляр драйвера для работы с платформой
TTargetSTM32    target;

// Экземпляр драйвера для работы с шиной CAN
TCANDriverSTM32    driver;

// Экземпляр протокола CANopen
TCANopenSlave    CANopenSlave;

// Обязательные (mandatory = M) и необязательные (optional = O) объекты устройства
TObject0x1000    deviceTypeObject;            // Регистр типа устройства (M)
TObject0x1001    errorRegisterObject;        // Регистр ошибок (M)
TObject0x1002    manufacturerStatusRegisterObject; // Регистр состояния от производителя  (O)
TObject0x1018    identityObject;                // Объект идентификации устройства (M)
TObject0x1400    receivePDO1_CommunicationParameter;

// ......

static unsigned numberOfRecievedFrames = 0;
static TCANFrame recievedFrame;

int main()
{
    CANopenSlave.run();

    for (;;)
    {
        while (numberOfRecievedFrames > 0)
        {
            numberOfRecievedFrames--;
            CANopenSlave.dispatch(recievedFrame);
        }
    }
}

// CAN RX0 interrupts requests
extern "C" void USB_LP_CAN_RX0_IRQHandler() 
{
   numberOfRecievedFrames++;
   driver.getFrame(recievedFrame);
}

void TTargetSTM32::initialize() // Инициализация платформы
{
    setSystemFrequency(SYSTEM_FREQUENCY_72MHz);
// ..........
}

void TCANDriverSTM32::initialize() // Инициализация драйвера CAN
{
    _configuration.portNumber    = 0;
    _configuration.baudRate    = BR_1000Kbps;
}

void TCANopenSlave::initialize()
{
    _configuration.deviceNodeId    = 2; // TODO ????
    _configuration.driverHandle    = &driver;
    _configuration.targetHandle    = ⌖
}


void TObject0x1000::initialize()
{
    _deviceType.deviceDS401.digitalInputEnabled        = true;
    _deviceType.deviceDS401.digitalOutputEnabled    = true;
    _deviceType.deviceDS401.analogInputEnabled        = false;
    _deviceType.deviceDS401.analogOutputEnabled        = false;
    _deviceType.deviceDS401.specificFunctionality    = 0; // No specific function
}


void TObject0x1018::initialize()
{
    _deviceIdentity.productCode                = 0;
    _deviceIdentity.vendorID                = 0;
    _deviceIdentity.revisionNumber.major    = 1;
    _deviceIdentity.revisionNumber.minor    = 0;
    _deviceIdentity.serialNumber            = 0;
}

// ......

 

К сожалению, код я не могу выкладывать - меня за это... чи-чи.

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

 

Кстати, скажу по-секрету, военные и космические заинтересовались CAN-ом. И можно понять почему: в настоящее время в отечественной авиации, космосе и войне для связи девайсов используется старая шина MIL-STD-1553 (успешно "спертая" военными у янков аж в далеком 1973). Так вот, трансивер + контроллер этой шины для одного узла стоит минимум 1000$ !!! Все решение полностью покупается у янок. А в космосе это обходится и того больше. А цена решения CAN шины обойдется в 1000 руб (для военных) или того меньше, если военные/космос догадаются купить исходники CAN-контроллера и запихать их в рад-стойкую ПЛИС.

[syoma 1]

Так все-таки CANopenNode или CANfestival?

Что лучше, если надо реализовать и мастер и слейв?

[Serega 0]

По мне так CANopenNode будет попроще в реализации для контроллера, а вот для ПК надо CANfestival использовать.

[syoma 1]

Я имел ввиду, конечно контроллер. Например STM32F. Хоть и как сдесь сказали, CANopenNode лучше документирован, но на форуме CANFestival есть информация, что его достаточно легко можно портировать под STM.

Еще интересно - имеет ли смысл все это дело на CANpie заворачивать, или стандартных библиотек и функций достаточно?

[Serega 0]

А что такое CANpie?

[syoma 1]

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

Привет.

В общем я теперь вроде нахожусь на том уровне понимания стека, что как работает - понятно, но теперь вижу ущербность Open-source стеков и даже некоторых не-Opensource. Поэтому есть пара вопросов.

1. Я так понял что у Вас, как и у многих других реализаций, есть функция CANOPen.dispatch, которая должна циклически вызываться из главной программы и выполнять раскидку и создание PDO,SDO сообщений и реакцию на NMT. То есть время выполнения такой функции зависит от загрузки сети и точно не детерминировано - что мне как-то не нравится. Или это нормально?

2. Как у Вас выглядит Object Directory - просто массив данных одинаковой длины? Как вы к нему обращаетесь? Через функции, чтобы избежать порчи данных при чтении и чтобы CANopen знал, когда слать PDO? Или просто?

3. Как насчет NMT master и сервисов LSS. Реализовывали ли их?

4. Что посоветуете для первой попытки связи с CANopen устройством?

У меня есть CANanalyzer с IXXATшным USB адаптером. Как я понял, NMT и PDO сообщения я еще смогу сгенерить самостоятельно, но SDO - надо бы что-то получше. Я думал, действительно какой-нибудь ПЛК взять для экспериментов, но не могу понять, какой.

5. Вы брали какой нибудь стек за основу или полностью свой лепили?

6. Отправка сообщений - используете ли Вы какой-нибудь буфер или по одному шлете?

[Forger 17]

Поэтому есть пара вопросов.

1. Я так понял что у Вас, как и у многих других реализаций, есть функция CANOPen.dispatch, которая должна циклически вызываться из главной программы и выполнять раскидку и создание PDO,SDO сообщений и реакцию на NMT. То есть время выполнения такой функции зависит от загрузки сети и точно не детерминировано - что мне как-то не нравится. Или это нормально?

От загрузки сети это почти не будет зависеть, если отсев левых кадров будет производится еще в прерываниях по приему кадров.

Более того вызов dispatch я делаю в отдельной задаче RTOS по событию (сообщению) из прерывания по приему.

Разумеет, контроллер должен иметь достаточную производительность.

В RTOS есть анализ загрузки, типа профайлинг. Так что, все под контролем :)

 

 

2. Как у Вас выглядит Object Directory - просто массив данных одинаковой длины? Как вы к нему обращаетесь? Через функции, чтобы избежать порчи данных при чтении и чтобы CANopen знал, когда слать PDO? Или просто?

Нет, не массив. Список с абстрактным интерфейсом для доступа к объекту.

Т.е. TObject - полностью абстрактный класс, все методы - виртуальные.

CANopen стек имеет доступ ко всем объектам только через этот абстактный класс.

Подобное построение реализовано во всем стеке.

 

 

3. Как насчет NMT master и сервисов LSS. Реализовывали ли их?

Нет. Не требовалось. Но, если понадобиться, добавить недолго - стек построен прозрачно.

 

4. Что посоветуете для первой попытки связи с CANopen устройством?

У меня есть CANanalyzer с IXXATшным USB адаптером. Как я понял, NMT и PDO сообщения я еще смогу сгенерить самостоятельно, но SDO - надо бы что-то получше. Я думал, действительно какой-нибудь ПЛК взять для экспериментов, но не могу понять, какой.

Я использовал ПЛК от BECK@IPC: SC23/24. Среда CoDeSys.

http://www.beck-ipc.com

 

 

5. Вы брали какой нибудь стек за основу или полностью свой лепили?

Исключительно свой, по документам CANopen CIA.

 

 

6. Отправка сообщений - используете ли Вы какой-нибудь буфер или по одному шлете?

Разумеется, буфер. По передаче тоже. Более того, у CAN контроллера есть как правило свои аппаратные буферы.

[syoma 1]

CANopen стек имеет доступ ко всем объектам только через этот абстактный класс.

Подобное построение реализовано во всем стеке.

Я не имел ввиду со стороны стека, а как обстоит дело с доступом со стороны приложения?

 

Я использовал ПЛК от BECK@IPC: SC23/24. Среда CoDeSys.

http://www.beck-ipc.com

Можете подсказать во сколько это примерно обойдется по деньгам, если у меня ничего нету - ни железа ни софта под это дело.

[Forger 17]

Я не имел ввиду со стороны стека, а как обстоит дело с доступом со стороны приложения?

При объявлении класса объекта (TObjectXXX) он должен обязательно наследоваться от шаблона TObjectCustom<>.

При статическом (желательно) или динамическом объявлении экзэмпляра этого класса TObjectXXX, он автоматически включается в список объектов и доступен стеку через закрытые и уже реализованные самим стеком методы (для приложения они недоступны).

Для приложения необходимо реализовать лишь одну чисто виртуальную функцию updateInputs, которую будет вызывать сам стек CANopen, это обновляет выходные сигналы (со стороны узла), т.е. RPDO.

В самом классе TObjectXXX можно наделать сколько угодно своих методов, но для обновления входов (со стороны узла), т.е. TPDO,

необходимо в этих методах в нужных местах вызывать уже реализванную в TObjectCustom<> функцию updateOutputs.

 

 

Можете подсказать во сколько это примерно обойдется по деньгам, если у меня ничего нету - ни железа ни софта под это дело.

 

Я этого не могу сказать, поскольку я - не руководитель фирмы, а лишь ее сотрудник: платил не я ;)

Одно знаю: преобразователь CAN-USB и софт (все от отечественной компании Марафон) обошелся в ~20 тыр.

Но этот вариант не советую, все ж лучше один раз раскошелиться на нормальный набор, например, от IXXAT.

Без сторонних железок и софта нормальный CANopen практически невозможно реализовать.

[syoma 1]

Я вот смотрю, что вы с STM32 работаете. Я тоже собираюсь на нем реализовывать.

Вопрос - у вас, я так понял, реализация с использованем ООП?

На CANopenNode - есть вариант обычной реализации и ООП - правда он еще полностью не протестеный, но доступный. Вот я и не понимаю, чего тот чел тоже перелез на объекты, если и без них все прекрасно работало. Зачем для микроконтроллера объектная реализация?

Или может есть весомые преемущества ООП реализации CANopen стека, по сравнению с обычной реализацией, с точки зрения понимаемости программы в будущем и расширяемости, если основное приложение будет оставаться обычным - без объектной реализации?

 

ПС. Я это спрашиваю еще потому, что посмотрел документацию на основные коммерческие CANopen стеки от IXXAT, Vector и т.д - там все без ООП. Но это наверное в угоду портируемости.

[garry_ 0]

...

Одно знаю: преобразователь CAN-USB и софт (все от отечественной компании Марафон) обошелся в ~20 тыр.

Но этот вариант не советую, все ж лучше один раз раскошелиться на нормальный набор, например, от IXXAT.

..

 

А у кого вы купили за такую цену? На сайте марафона он 6 тысяч рублей стоит.