Beremiz, портирование под stm32 Опции

[yanvasiij]

Доброго времени суток!

Несколько слов о том, что я делаю и что получается.
Озадачился портированием вышеупомянутого ПО. Идея была такая: поскольку Beremiz компилирует входные исходники на языках IEC в Си, то эти исходники можно далее компилировать на чем угодно в том числе и под микроконтроллеры. Тогда я взял GCC под ARM embed (GNU Tools ARM Embedded), написал несложный рантайм (если это так можно назвать), который вызывает апи беремиза в задачах ртос. Делал по аналогии с тем как это сделано под платформу Xenomai (.\bremiz\targets\Xenomai). Далее организовал папочку STM32 в .\bremiz\targets c необходимыми питонячими файлами, задача которых прилинковывать при компиляции мой рантайм, плюс несколько несложных манипуляций над исходниками самого Beremizа, чтобы он при компиляции использовался gcc. Теперь в результате компиляции программы на IEC в Beremiz получаю hex готовый для зашивки в микроконтроллер.

Теперь собственно проблема. Для того, чтобы появилась связка между конкретным железом и программой, нужно в beremizу написать плагин и разместить его в папочке plugins, в котором и будет описание связки с "железом". Запустить эти плагины у меня так и не вышло. Я уже не раз видел упоминание Beremiza на этом форуме. Кто-нибудь писал эти плагины? Я бы был очень признателен, если бы мне ответили на несколько вопросов.

[unkier]

немножко копнул беремиз. давай вместе подумаем. у меня такие же хотелки.

[yanvasiij]

Вытащил все из официального репозитраия и посмотрел по коммитам: начиная с определенной версии исчезла папка plugins. Плагины теперь не так добавляются. Поэтому начал курить исходники. Я не силен питоне, поэтому удалось придумать пока только следующее: добавил еще одну папку STM32, покидал туда мною созданные питонячие файлы, в которых планирую привязваться к железу. Теперь в дереве проекта можно добавлять еще один тип:



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

[unkier]

мне про matiec больше интересно. всё равно всё потом им кампилится в C. как сделать вызов сишной функции из кода на IEC языках. вообще не понятно.

[yanvasiij]

мне про matiec больше интересно. всё равно всё потом им кампилится в C. как сделать вызов сишной функции из кода на IEC языках. вообще не понятно.

Очень просто: matiec генерирует С файл, в котором производится вызов, например, Вашей функции в которой происходит связь с железом. А эту функция реализована в другом сишном файле. Потом нужно взять все эти сишные файл скомпилить, например в GCC и слинковать. У меня все это делает Beremiz - сначала передает все необходимые данные matiec'y далее берет результат его работы компилирует в gcc и силнковывает с файлом, где реализована привязка с железом.

[unkier]

точно, всё оказалось просто )

посмотрел вдумчиво на py_ext плагин и всё стало более менее ясно. получилось добавить свою функцию в библиотеку. вытаскиваю её на рабочее поле, подключаю входы/выходы. тыкаю собрать проект и вижу что мои сишные файлы добавляются в компиляцию и вызовы корректно вставляются куда нужно. проект кампилится.

[voodoojah]

Извините, конечно, не в тему, но вопрос очень волнует.
Вам не приходилось сталкиваться с проблемами при написании в Beremiz функционального блока с передачей массива в качестве параметра?
Я имею в виду ФБ, написанный на C, и подключаемый на target-платформе в виде shared object library. А его описание в виде .xml и .py файла добавленное в beremiz.

Объявить массив переменных в xml файле, описывающем функциональный блок не получается, или я не знаю как. Никакой документации по этому вопросу найти не смог.
Если я правильно все понял, разработчики поддержки такой возможности не делали. На вопросы отвечают очень долго, месяцами.

Пробовал объявить в ФБ параметр, такого же типа как элемент моего массива и передавать первый член массива как аргумент. Предполагалось, что раз массив все равно указатель, а в ФБ передается тоже указатель, то в своем сишном коде я его спокойно разименую и буду использовать.
Но схитрить не получается, при вызове функционального блока, передается не указатель на массив, а указатель на структуру data__, которая перед этим инициализируется значениями из local и global переменных. Таким образом первый член массива передается по значению, как добраться до остальных, непонятно.

Если сталкивались, то как решали? Если я сам что то по глупости упустил, укажите, пожалуйста)

[yanvasiij]

Обнаружил багу в matiec. При использовании функциональных блоков внутри функций или других функциональных блоков генерируется код, который присваивает структурам целочисленные значения. При компиляции в gcc это приводит к ошибкам. Очень жаль (((

[yanvasiij]

После беседы в mailing list было "официально" признано, что это бага в matiec. Имейте ввиду, если вы сами это не исправляли, то это бага у вас есть.

[yanvasiij]

Аналогичная ошибка при передаче массивов параметрами в функции и функциональные блоки.

[yanvasiij]

Нашел еще несколько очень неприятных ошибок в самом беремизе и matiec, касающиеся пользовательских типов данных.
Без исправления всех вышеперечисленных ошибок использовать беремиз+matiec для компляции более или менее серьезных АСУшных проектов невозможно. Я перенес на беремиз один реальный АСУшный проект (написанный для шнайдеровского контроллера), который использовал большое количество переменных, функциональных блоков, функций, пользовательских типов и т.п. После адаптации обнаружились все эти неприятности. Напрашивается печальный вывод: либо ждать когда исправления появятся в официальном репозитарии, либо обзавестись терпением и самому начать курить исходники matiec, либо не использовать вообще.

[griabig]

Нашел еще несколько очень неприятных ошибок в самом беремизе и matiec, касающиеся пользовательских типов данных.
Без исправления всех вышеперечисленных ошибок использовать беремиз+matiec для компляции более или менее серьезных АСУшных проектов невозможно. Я перенес на беремиз один реальный АСУшный проект (написанный для шнайдеровского контроллера), который использовал большое количество переменных, функциональных блоков, функций, пользовательских типов и т.п. После адаптации обнаружились все эти неприятности. Напрашивается печальный вывод: либо ждать когда исправления появятся в официальном репозитарии, либо обзавестись терпением и самому начать курить исходники matiec, либо не использовать вообще.

Предлагаю объединить усилия и допилить Beremiz/matiec до рабочего состояния. Я исправил некоторые ошибки, которые мне попались в работе в своем репозитории. Кстати, там сделана русская локализация пользовательского интерфейса. Есть части, которые не переведены еще. Но это части кода, которые вообще без поддержки локализации написаны. Это я поправлю, как буду на них натыкаться.

По поводу matiec ничего не могу сказать. Только белгло просмотрел код. Там надо разбираться.
Кстати проблемы, касающиеся matiec, мне кажется, что лучше описывать еще на баг-трекере.

[yanvasiij]

Предлагаю объединить усилия и допилить Beremiz/matiec до рабочего состояния. Я исправил некоторые ошибки, которые мне попались в работе в своем репозитории. Кстати, там сделана русская локализация пользовательского интерфейса. Есть части, которые не переведены еще. Но это части кода, которые вообще без поддержки локализации написаны. Это я поправлю, как буду на них натыкаться.

По поводу matiec ничего не могу сказать. Только белгло просмотрел код. Там надо разбираться.
Кстати проблемы, касающиеся matiec, мне кажется, что лучше описывать еще на баг-трекере.

Поддерживаю Ваше предложение! По поводу баги в matiec я писал Марио на личную почту, он мне ответил обещал исправить.

[griabig]

Поддерживаю Ваше предложение! По поводу баги в matiec я писал Марио на личную почту, он мне ответил обещал исправить.

Замечательно! Но если забудет, то тогда добавим в баг-трекер. Так надежней, уже точно не потеряется.

[paulbell]

Обнаружил багу в matiec. При использовании функциональных блоков внутри функций или других функциональных блоков генерируется код, который присваивает структурам целочисленные значения. При компиляции в gcc это приводит к ошибкам. Очень жаль (((

Здравствуйте, глянул IEC 61131-3:
> 2.5.1 Functions
>...
>Functions shall contain no internal state information, i.e., invocation of a function with the same
>arguments (input variables VAR_INPUT and in-out variables VAR_IN_OUT) shall always yield
>the same values (output variables VAR_OUTPUT, in-out variables VAR_IN_OUT and function
>result).
> It shall be an error if external variables as defined in 2.4.3 cause the violation of this rule.
>...
> 2.5.2 Function blocks
>...
>All the values of the output variables and the necessary internal variables of this data structure
>shall persist from one execution of the function block to the next; therefore, invocation of a
>function block with the same arguments (input variables) need not always yield the same output
>values
>...


Использовать ФБ внутри функций, похоже, нельзя, т.к. при этом невозможно гарантировать,
что функция будет выдавать одни и те же результаты при одних и тех же входах.

Относится ли это к использованию ФБ в качестве входного параметра, не поняно...