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

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

PRU0.prg и PRU1.prg это файлы программ PRU. И да, они, по расширению, совпадают с prg 2-го КоДеСис-а.
prg отлично формируются уже представленным ПО из имеющихся или заново создаваемых ФБ.

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

prg отлично формируются уже представленным ПО из имеющихся или заново создаваемых ФБ.

Проблема в "уже представленном ПО" в том, что для задействования "уже представленного" нужно:
1) Создать схему программы в КДС (неудобно) или в формате КДС_CFC.exp (не реализовано)
2) Очень внимательно следить за использованием ADD vs ADD_CONST vs ADD_WORD_CONST. Вот тут "представленное ПО" крайне тяжело ложится на IDE. Сделать, конечно, всё можно, но я никак не хочу делать 100500 copy-paste'ов, описывающих разновидности ADD/SUB и т.п.

Вот фрагмент моего компилятора, описывающий команды "a := b OP c", где OP это сложение, вычитание и т.п:
c1_st_assignmentcompiler.png

с3_st_simple_operand.png

И ещё пара блоков (Instruction здесь это объект, описывающий ассемблерную команду. Например, XOR, AND выше это и есть Instruction с аргументами), которые превращают "ассемблер" в нужные вызовы Java:
c2_asm_to_java.png

Тут нет никакого взрыва комбинаций "ADD vs ADD_CONST vs ADD_WORD_CONST".
Вышеупомянутый код без проблем компилирует сложение BYTE/WORD/DWORD.
Конечно, мне хотелось бы уйти от unsigned типов, но я уж лучше сначала сделаю рабочий блок ШД, а заниматься знаковыми типами и т.п. потом.



"Компилировать в формат КДС_CFC.exp" неудобно. Да и у меня нет никакого желания откладывать "обкатку блока ШД" до момента, как я научусь генерировать КДС_CFC.exp формат.

Объективно:
1) Компилировать в бинарный формат PRU я могу уже сейчас. Как-никак, а команды, которые выполняет PRU процессор гораздо ближе к ST, чем к графическому языку
2) Компилировать графический язык в ST гораздо проще, чем наоборот. Поэтому, вариант развития "сначала сделать ST -> PRU0.prg компилятор", потом добавить "графический -> ST" выглядит более понятным и позволит не ждать 2018-го года до первого тестирования ШД.
2) Компилировать в формат КДС диаграмм (из ST или из графического языка -- не так важно) только ради того, чтобы использовать "уже представленное ПО" выглядит как отвлекающей задачей, занимающей много времени без видимого результата. Гораздо проще вызвать команду процессора "условный переход", чем превращать разные ветки в CFC.
3) Некоторые блоки становятся ненужными, если компилировать программу целиком. Например, один и тот же код блока CTU_BYTE будет работать как в случае, когда на вход поступает константа, так и в случае, когда на вход переменная. Сам компилятор выберет необходимую команду процессора, и расход регистров/памяти будет зависеть не от имени блока, а от его фактического использования.
И пользователю просто: не нужно задумываться о множестве однотипных блоков, и при написании этого множества блоков не будет copy-paste ошибок.

Поэтому, у меня возник вопрос: "а что, если PRU0.prg генерировать непосредственно из бинарного кода PRU?"

Собственно, вопрос: действительно ли "задействование уже предоставленного ПО" это единственно возможный вариант создания PRU0.prg?
Действительно ли, формат PRU0.prg засекречен, и создание его внешними инструментами недопустимо?