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

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

Концепция сверхжёсткого реального времени с 100% гарантией исполнения алгоритма не позволяет переиспользовать ресурсы

1) На самом деле, позволяет. Например, для умножения WORD'ов достаточно сделать 16 итераций цикла. На этих итерациях можно переиспользовать переменные. Никто не пострадает. Можно всегда крутить все 16 итераций и время выполнения вообще константным будет. А можно и выходить из цикла пораньше (если числа маленькие) -- тогда останется время на другие задачи.
2) Для большинства типичных случаев сверхжёсткий realtime и не нужен. Ну на кой нужен этот самый realtime, если мы ШД крутим?

Например в Овен Лоджик блок расчёта таких "запретных" линий, где надо делать промежуточную ячейку памяти занимает немалую часть логики среды разработки и даже после годов отладки иногда бывают "особые ситуации".

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

Вот ФБ для "линии задержки":
Снимок экрана 2016-10-04 в 20.29.51.png

Вот программа с его использованием. Надеюсь, вы понимаете, что FBD программы в такой ST код переводятся в режиме "что вижу, то пою"?
Для преобразования FBD в такой ST код нужно лишь объявить переменные с ФБ и присвоить входные-выходные значения.
Да, топологическую сортировку FBD, конечно, сделать придётся, но это вовсе не вопрос "где нужна доп ячейка, а где не нужна".

И, да, я ни строчки кода в компиляторе не менял. Просто добавил ФБ и создал программу с его участием.
Снимок экрана 2016-10-04 в 20.38.11.png

Вот результирующий ассемблер:

Снимок экрана 2016-10-04 в 20.38.49.png

"промежуточная" ячейка образовалась сама собой. R1.b1 (для первой обратной связи) и R1.b2 (для второй).

Ну, я, конечно, понимаю, что "с первого раза никогда ни одна программа не получается", но не вижу никаких сложностей с обратными связями. Честное слово не вижу.
Вот я написал простой ST, и он сразу заработал. В чём реально проблема?

Мой план -- FBD программы преобразовывать в ST, а потом обрабатывать уже имеющимся ST компилятором.
И наглядность FBD сохранится, и всегда можно будет проверить "во что оно превратилось" / "на каком этапе косяк".

На всякий случай, я использую следующие ключевые слова: dataflow analysis, live variable analysis, linear scan register allocation. Первые два алгоритма реализовывал не я, а они встроены в среду, на которой я пишу Hardella.


И, да, сейчас в ОЛ поведение "если есть цикл в программе, то разрывать его и где-то автоматически делать обратную связь", но, на мой взгляд, это нехорошее поведение. Если делать FBD в Hadrella, то я хотел запретить явные циклы, и всегда требовать от пользователя указания где именно связь с задержкой на такт.