Ну, да, пользовательский код.
Вот сейчас в ОЛ есть такая штука как макрос. Там содержится пользовательский код.
И ничего, многим нравится. Многих выручает.
Какая-то проблема с этим?
Повторюсь, код не бинарный, а p-code.
А что называется словом "оттестировать"?
Вот "макрос ОЛ" можно оттестировать?
Если можно, то и "p-code блок" тоже можно оттестировать.
Суперблок это будет или нет зависит от того, будет ли в p-code инструкция "CALL macro".
Надеюсь, если не в первой версии p-code блока, то следующих эта инструкция появится (ну, чтобы можно было вызывать проектные макросы).
А значит, можно будет вызывать и один p-code блок из другого.
А значит, "оттестирование" p-code блока будет несильно сложнее, чем "оттестирование обычного ОЛ макроса".
Можно же сложные p-code блоки составлять из более простых. Всё в порядке. Где "невозможность в принципе"?
Про возможность тестирования p-code за пределами ОЛ я пока не буду распространяться.
Тестирование PRU блока вполне возможно (pru-emulator прекрасно работает).
Есть реальные примеры, когда пользователи берут и раскручивают ШД на ПЛК110 буквально за день. С разгоном и торможением, без мутоты с прерываниями.
Сами качают среду, заливают PRU0.prg и всё такое.
И никто не бегает как кенгуру. Оно просто работает.
Наоборот, кто-то вообще взял и с нуля сделал свою PRU программу на ST. Да, с точки зрения КДС это получился "один блок", но с точки зрения пользователя это нормальные ФБ и понятный ST код.
В этом плане p-code блок в ОЛ будет смотреться гораздо более органично, ведь по сути он не будет отличаться от имеющихся макросов. А PRU программа хочешь-не-хочешь выполняется на другом ядре процессора, и там даже передача данных это непростая задача.





