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

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

Другое дело, что возможность использования ПР200 в настоящее время ограничивается ОЛ, в котором недостаточно гибкий набор блоков, который не позволяет создавать достаточно сложные макросы, точнее сложность есть, но в основном структурно-графическая.

Да, всё так. Итеративные вычисления, например, в текущем FBD выглядят как сами знаете что.

Поэтому и возникла просьба - дать возможность написания макросов на С, который имеет развитый набор операторов и функций. С учетом того, что и сам ОЛ и системный софт ПР200 наверняка написаны на С или его клонах - проблема не выглядит особенно трудоемкой.

Интеграция C блоков и ОЛ-ПР это трудоёмкая задача.

Дело в следующем:
1) Само по себе ПР может быть устроено по-разному внутри. Например, ПР200 2017-го года выпуска и ПР2000 2016-го вообще могут иметь внутри разную разводку, разный процессор и т.п.
Для компиляции C кода в пригодный для ПР формат придётся точно знать модель и т.п.
Сейчас эта кухня скрыта внутри ОЛ, а светить её наружу непросто, ведь никто с первого раза не сможет правильно настроить C компилятор, а на второй раз окажется, что льёт программу от старого ПР в новое и беда-печаль.

2) В ПР нет online режима. А в ОЛ есть симуляция. Полагаю, они сделаны вообще независимо друг от друга. Допустим, вы как-то скомпилируете свой блок на C для выполнения в STM32 процессоре внутри ПР. Внимание, вопрос: как этот блок задействовать в симуляции? Компилировать его ещё раз для Intel процессора вашего ноутбука? См. пункт 1. И одного раза-то никто скомпилировать не сможет. Уж два и подавно.

Вспоминаем, что online режима нет, и получается что "при использовании C блоков программу нужно писать вслепую". Кому такое надо? Ни-ко-му.

3) Напомню, что online режима в ОЛ вообще нет. Сам по себе этот факт означает, что для ОВЕН сделать online это трудоёмкая задача.
А скрестить уж C блоки и online режим, значит, архитрудоёмкая.

4) Сам по себе язык С никак не защищает от опечаток, выходов за границы массива и т.п. Эти ошибки встречаются и у зубров, поэтому для массового применения голый C не подходит. Будет слишком много вопросов "у меня ПР зависло" или "у меня ОЛ не открывается", хотя формально дело в кривости C кода. Т.е. нужно как-то на уровне C кода запрещать криворукий код. Это непросто.

5) Возможность программировать ПР на C без ОЛ, скорее, время на ветер. Как-никак, сейчас есть армия ОЛ пользователей, и делать C программирование со своей симуляцией/online не укладывается в понятие "не выглядит особенно трудоемкой"

В ОВЕНЕ обещали подумать - что в общем уже хорошо.

Вот не знаю хорошо это или плохо. Будут думать над интеграцией С в ПР, зря тратить время на непойми что...
Посмотрим, конечно, что в итоге не получится.

На мой взгляд, совершенно неочевидно как можно скрестить C и ОЛ.
С другой стороны, интеграцию C я никогда и не предлагал. Я предлагал провести интеграцию по p-code (~IL).
Если тов. Филоненко под словами "архитектура ПР совсем другая" имел ввиду то, что ОЛ генерирует бинарный код для STM32, то, конечно, соглашусь, что ситуация безнадёжна.

[anthrwpos]

1) Само по себе ПР может быть устроено по-разному внутри. Например, ПР200 2017-го года выпуска и ПР2000 2016-го вообще могут иметь внутри разную разводку, разный процессор и т.п.

Вы путаете прошивку контроллера с пользовательской программой.
Доступа к прошивке, где содержится конфигурация портов ввода-вывода, регистров, прерываний и всему прочему вы не получите 100%, ибо если дать юзеру такой доступ, то половина контроллеров будут доведены до состояния при котором он не сможет отвечать на запрос компьютера по USB в течении недели после ввода такой фичи.

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

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

Вы путаете прошивку контроллера с пользовательской программой.

Не путаю.

В наиболее вероятном случае во внешней памяти установлен какой нибудь из эмбеддед-линукс

32KiB RAM, 128KiB ROM и embedded linux?
Не верю (tm)