Программирование ПЛК110 [М02] для задач реального времени

[Дмитрий Артюховский]

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

.. но обсуждаемая тема про другое! жесточайший лимит памяти, суровые команды с не очевидным синтаксисом, ориентированные на максимальное быстродействие - вот что такое PRU. Здесь место "голого ассемблера", даже чистый С будет неэффективно расходовать регистры и постоянно срываться на использование медленной памяти, а уж самописный транслятор...... Поэтому я считаю что тема пошла по неправильному курсу - хочется людям "красивостей", да за ради бога, но лично я не вижу применения этому. Имеющийся материал ужасть какой сырой и нужно прежде всего его обкатывать - три дня на элементарный проброс данных через PRU с помощью существующих блоков - при наличии вроде как рабочего примера - за гранью добра и зла )))

Я пошел по другому пути - ФБ PRU_DIMAS и в нем голый ассемблер с минимальным использованием описателей, лишь бы удовлетворить транслятор, в котором требуемый мне алгоритм не отягощен требованиями на совместимость блоков и выделением регистров на хранение промежуточных результатов... ну и START END по краям, вроде как обязательные... и вот они импульсы в 50 кГц.... как оказалось чуть позже - импульсы в 500 кГц были просто не видны из-за емкости щупов и установленной подтяжки ))

а вывод PRU -> "кино не для всех" и овеновцы правы в том что тратят основное время на что-нить другое, согласитесь проблем хватает...

кстати, то что "быстрые ВЫХОДЫ" поделены между 2 процессорами по 2 я уже вычитал, а входы как заведены? все 4 в каждое ядро, параллельно???

[Дмитрий Артюховский]

Да, у меня есть задачи под PRU.
Для того чтобы прочитать мануал при примененному чипу, не нужно подписывать никакие договоры. "Сторонний софт" наверняка найдется на сайте производителя чипа, а получившийся бинарник весьма вероятно загрузится в память ПЛК при старте и успешно заработает, будучи просто поименован соответствующим образом ))) Сам еще не пробовал, но весьма сомневаюсь что Филоненко будет лепить закодированный файл при трансляции, а потом его раскодировать при загрузке! Да и убедиться в этом кстати не долго, просто посмотрев файл в бинарном виде.

[Владимир Ситников]

Да, у меня есть задачи под PRU.

Можете озвучить?

Задачу генерировать "N импульсов нужной частоты" уже сделали.

Для того чтобы прочитать мануал при примененному чипу, не нужно подписывать никакие договоры. "Сторонний софт" наверняка найдется на сайте производителя чипа, а получившийся бинарник весьма вероятно загрузится в память ПЛК при старте и успешно заработает, будучи просто поименован соответствующим образом )))

Понимаете какая штука. Если в прошивке ПЛК есть хоть какое-нибудь распознавание бинарника, то можно очень круто залететь, когда, вроде бы "рабочая" программа в ПЛК выполняется совсем не так, как должна.

Например, компилятор от производителя процессора не любит букву Я (у неё код 255 или что-то типа того). Запросто подобное может быть прошивке ПЛК110. Исследовать методом научного тыка желания нет.

Сам еще не пробовал, но весьма сомневаюсь что Филоненко будет лепить закодированный файл при трансляции, а потом его раскодировать при загрузке! Да и убедиться в этом кстати не долго, просто посмотрев файл в бинарном виде.

Технически, это нарушение "авторских прав" и соответствующая статья.
По букве закона, единственный способ сделать программу для PRU ПЛК110 -- это запросить у ОВЕН "линкер", написать на ассемблере программу, и создать PRU0.prg через инструментарий ОВЕН.

Собственно, без подписания договора о неразглашении мне инструментарий никак не выдавали.

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

Посмотреть -- одно дело, а генерировать -- другое.
1) Декомпилирование и исследование форматов файлов с целью повторения существующего функционала -- это 100% статья про авторские права. Там явно сказано, что нельзя декомпилировать с целью "создания подобного".

2) Я не юрист, и не хочу разбираться будет ли нарушением авторских прав просто попытка переименовать бинарник от официального TI компилятора в название PRU0.prg. Если ОВЕН явно скажут, что "ок", то ок.
Я не хочу рисковать тем, что через неделю придёт ОВЕН с иском о "потерянных миллионах из-за злостной дешифрации формата PRU0.prg".

[Дмитрий Артюховский]

Я не хочу рисковать тем, что через неделю придёт ОВЕН с иском о "потерянных миллионах из-за злостной дешифрации формата PRU0.prg".

В овене работают весьма здравомыслящие люди, а свои возможности "по нанесению вреда", как мне кажется, вы оцениваете не совсем адекватно )))

что нельзя декомпилировать с целью "создания подобного"

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

[Филоненко Владислав]

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

.. но обсуждаемая тема про другое! жесточайший лимит памяти, суровые команды с не очевидным синтаксисом, ориентированные на максимальное быстродействие - вот что такое PRU. Здесь место "голого ассемблера", даже чистый С будет неэффективно расходовать регистры и постоянно срываться на использование медленной памяти, а уж самописный транслятор...... Поэтому я считаю что тема пошла по неправильному курсу - хочется людям "красивостей", да за ради бога, но лично я не вижу применения этому. Имеющийся материал ужасть какой сырой и нужно прежде всего его обкатывать - три дня на элементарный проброс данных через PRU с помощью существующих блоков - при наличии вроде как рабочего примера - за гранью добра и зла )))

Я пошел по другому пути - ФБ PRU_DIMAS и в нем голый ассемблер с минимальным использованием описателей, лишь бы удовлетворить транслятор, в котором требуемый мне алгоритм не отягощен требованиями на совместимость блоков и выделением регистров на хранение промежуточных результатов... ну и START END по краям, вроде как обязательные... и вот они импульсы в 50 кГц.... как оказалось чуть позже - импульсы в 500 кГц были просто не видны из-за емкости щупов и установленной подтяжки ))

а вывод PRU -> "кино не для всех" и овеновцы правы в том что тратят основное время на что-нить другое, согласитесь проблем хватает...

кстати, то что "быстрые ВЫХОДЫ" поделены между 2 процессорами по 2 я уже вычитал, а входы как заведены? все 4 в каждое ядро, параллельно???

входа 4 во 2-е PRU. Но можно передавать данные между PRU через память, там очень удобный механизм.

[Филоненко Владислав]

Линкер, кстати, Владимиру дали. Так что я вообще не понимаю проблемы!? Делаешь ФБ и вперёд. Запустить пару бат-файлов из Hardell-ы несложно.
Дмитрий Артюховский вот использует.

[Владимир Ситников]

Там не всё так просто, но и не суперсложно

Озвучьте, пожалуйста, что именно сложно.

[Владимир Ситников]

Линкер, кстати, Владимиру дали. Так что я вообще не понимаю проблемы!? Делаешь ФБ и вперёд. Запустить пару бат-файлов из Hardell-ы несложно.
Дмитрий Артюховский вот использует.

А вы посмотрите, что Дмитрий пишет:

Я пошел по другому пути - ФБ PRU_DIMAS и в нем голый ассемблер с минимальным использованием описателей, лишь бы удовлетворить транслятор, в котором требуемый мне алгоритм не отягощен требованиями на совместимость блоков и выделением регистров на хранение промежуточных результатов... ну и START END по краям, вроде как обязательные..

Судя по этим словам, Дмитрий пишет один большой монолитный блок на ассемблере, и использует линкер не потому, что нравится, а потому, что выбора у него нет. И? Этот "ФБ PRU_DIMAS и в нем голый ассемблер с минимальным использованием описателей" надёжнее, чем аналогичный код на ST?

Т.е. не я один пошёл по варианту "неиспользования предоставленных блоков".


Очевидно, что:
1) Для среднего инженера-программиста вариант "написать на ассемблере" недостижим
2) При написании монолитного кода на ассемблере гораздо проще ошибиться, чем при написании того же кода на ST или FBD языке
3) Требование использовать "линкер" только для того, чтобы "использовать" лишь усложняет общую систему, и добавляет нетривиальные проблемы. Кто, например, тестирует сам линкер?
Как тестировать, что ваш линкер правильно слинковал мою конкретную программу? Да и вообще, линкер привязан к windows, что создаёт проблемы при запуске на macos.

[Владимир Ситников]

Давайте есть слона по кусочкам. Сейчас основное ограничение технологии PRU - отсутствие полноценного редактора.
А не написание ФБ на ассемблере.

Давайте. Озвучьте, пожалуйста, сложность документировать формат PRU0/1.prg и разрешить его использование.

[Newcomer]

Много спора из ничего. Все давно уже придумано. У замечательной фирмы Texas Instruments есть фирменная интегрированную среда разработки (IDE) Code Composer Studio, которая поддерживает микроконтроллеры компании TI и встраиваемые процессоры. "Code Composer Studio включает в себя набор инструментов, используемых для разработки и отладки встроенных приложений. Она включает в себя оптимизирующий C / C ++ компилятор, редактор исходного кода, среды сборки проекта, отладчик, профайлер, и многие другие функции" (http://www.ti.com/tool/ccStudio).

Среда эта естественно платная. Можно сделать что-то подобное для микроконтроллера, который используется в ПЛК110 М[02]. Если у фирмы "ОВЕН" есть фирменный инструментарий TI для написания программ для PRU на ассемблере, то можно приобрести все необходимое для написания программ на C/C++ (компилятор, линковщик, проч.).

У vladimirisitnikov есть своя Hardella IDE. Если фирма "ОВЕН" без проволочек передаст все необходимые причиндалы и разрешения, то очень скоро vladimirisitnikov сделает классный инструментарий для разработки PRU приложений. Этот инструментарий будет понятен и доступен широким массам пользователей продукции фирмы "ОВЕН".

Заниматься таким достаточно сложным делом на голом энтузиазме тяжело. Естественно фирма "ОВЕН" должна заключить с vladimirisitnikov договор подряда. К этому договору надо приложить согласованное ТЗ на разработку IDE и вперед к светлому будущему.