Возможность программирования на более низком, чем ОЛ схемы уровне

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

Давайте посчитаем.
ФБ AND - 2 бинарных входа - 4 варианта состояний входов - протестировать легко
Самоё большое кол-во входов в ФБ 5, внутренних переменных в ФБ - 3. Логика простая и понятная. Циклов нет, сложных переходов нет, отладка проста.
И сравним с:
Условный ФБ "Супер P-code" (например управление ШД) 9 входов, 6 внутр. состояний - число комбинаций 2^15. И это без учёта плавающей точки и использования времени.

Ну а если писать всю программу на 1 ФБ (к чему тов. Ситников и продвигает свой продукт), т.к. сделать нормальную фрагментацию кода, как и планировалось на PRU это сложно, лучше всё впихнуть внутрь - число входов и вн. состояний зашкаливает и проверить все комбинации в принципе невозможно.

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

И правильно тут отметили про права доступа для "внешнего кода".
Будьте любезны процессор (уже не микроконтроллер!) с MMU с внешней ОЗУ и Flash, да побольше, защищённый режим, RTOS полноценную и все прелести.
Иначе любой чих приводит ПР в неработоспособность + контроль доступа куда не надо.

Покупайте ПЛК100 с линуксом и кодьте.

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

И правильно тут отметили про права доступа для "внешнего кода".

Владислав, перестаньте, пожалуйста, скатываться в "бинарный код", в "программы на Си".

Я говорю исключительно про p-code. Никаких MMU, RTOS и прочей ереси на уровне p-code не должно быть видно и не должно быть доступно.
Только понятные операции типа "сложить два числа", "вызвать ФБ", "вызвать макрос", "сравнить" и т.п.

Ну каким боком тут ПЛК с линуксом? Он мне не впился. Ровно как никому не впилось программирование ОЛ-ПР на Си.

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

Ну а если писать всю программу на 1 ФБ (к чему тов. Ситников и продвигает свой продукт), т.к. сделать нормальную фрагментацию кода, как и планировалось на PRU это сложно, лучше всё впихнуть внутрь - число входов и вн. состояний зашкаливает и проверить все комбинации в принципе невозможно.

Владислав, тут я буду вынужден призвать модератора и обратить внимание на то, что текущая тема не имеет отношения к PRU.
Чего это вы постоянно скатываетесь на PRU?

Вспомните, что тут мы обсуждаем ПР и ОЛ.
Вспомнили?

Тогда вспомните, что я предлагаю создавать на p-code отдельные блоки и их использовать в финальной ОЛ программе.
Разумеется, при составлении p-code блоков будет удобно использовать имеющиеся ОЛ блоки, имеющиеся ОЛ макросы и другие p-code блоки.
Иными словами, я никого не призываю составлять ОЛ программу в виде одного единого ФБ. Ни в коей мере. Я за разделение кода на понятные фрагменты.


Поэтому сравнивать "простой SR триггер" и "суперсложный p-code блок" совершенно неправильно. Как вообще язык поворачивается сравнивать две совершенно разные вещи? Понятно, что на p-code можно сделать говнокод. Но говнокод можно сделать и в текущем ОЛ макросе. Значит ли это, что нужно срочно запрещать ОЛ макросы?
Правильно сравнивать "ОЛ макрос" и аналогичный по существу блок, написанный на p-code.
Например: "макрос вычисления синуса" и аналогичный "p-code вычисления синуса".

Если уж захотелось управлять ШД на ПР-ОЛ, то, милости прошу. Давайте сравним сложность составления ОЛ макроса для управления ШД (с разгоном, торможением, аварийным остановом и прочим). И сравним возможность протестировать этот самый "ШД макрос", написанный в ОЛ с макросом, написанным на p-code.

Что, ОЛ макрос для ШД это "Логика простая и понятная. Циклов нет, сложных переходов нет, отладка проста"? Едва ли.

[Newcomer]

Владислав, тут я буду вынужден призвать модератора и обратить внимание на то, что текущая тема не имеет отношения к PRU.

Владислав, сам себе модератор.

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

Это как оценка работы бригады таджиков по результатам предыдущих ремонтов.
Если раньше крепили розетки вверх ногами, как не просил заказчик, то и потом будут крепить.
Так что не надо звать маму-модератора!

[capzap]

https://habrahabr.ru/company/everydaytools/blog/327070/ наверное чтение этой темы и подобных навеяло написать на хабре

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

https://habrahabr.ru/company/everydaytools/blog/327070/ наверное чтение этой темы и подобных навеяло написать на хабре

А какое отношение имеет "конвертация с языка X на язык Y" к текущей теме?

[capzap]

А какое отношение имеет "конвертация с языка X на язык Y" к текущей теме?

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

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

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

Разумеется. Может, например, оказаться, что в первой версии p-code не будет команды "вызвать макрос". Будет ли полезен IL без команды "вызвать макрос"? Будет. Будет ли полезна сама команда вызова других макросов? Будет.

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

Слова "переделать на" неправильные. ОЛ уже переводит схему в низкоуровневый язык (не машинный, а IL). Поэтому тут вопрос лишь в том, чтобы сделать ОЛ-блок, в котором можно эту самую IL программу писать без ОЛ схемы.

ОЛ уже компилирует схему в IL. Откуда берутся фразы "нанять команду программистов" -- вообще непонятно. Там нужно не с нуля новое создавать, а использовать имеющееся.