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

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

Овен Лоджик работает как работает. P-code, о котором Вы так мечтаете - это те же квадратики, но в виде потока байт. За счёт супероптимизации процентов 10, наверное, выжать удастся по производительности.
У нас и так самый быстрый ПР среди конкурентов.

А шаг ниже - это писать свою программу на С и ASM и прошивать её в STM-ю отладку.

Никаких коварно скрываемых от общественности суперформатов загрузки не существует.

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

А шаг ниже - это писать свою программу на С и ASM и прошивать её в STM-ю отладку.

По-моему, вы смотрите со стороны разрабочика ОЛ. Да, для разработчика ОЛ шаг ниже это C или бинарный код STM.
Но для общественности доступны лишь "квадратики ОЛ, которые нужно таскать мышкой".
Для общественности, p-code это и есть тот самый нужный "шаг ниже". Большинству этого самого p-code должно хватить.


Смысл не в "супероптимизации производительности", а в том, чтобы просто иметь возможность генерировать программы для ПР в сторонних редакторах.

Понятно, что соединить вход с выходом в ОЛ проблем не составляет. А, например, записать формулу уже непросто.

Никаких коварно скрываемых от общественности суперформатов загрузки не существует.

О, где можно почитать/попробовать ОЛ p-code?

[Алексей Геннадьевич]

Овен Лоджик работает как работает. P-code, о котором Вы так мечтаете - это те же квадратики, но в виде потока байт. За счёт супероптимизации процентов 10, наверное, выжать удастся по производительности.

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

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

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

Вот как раз это и интересует гурманов как Владимир да и других

Интегрировать C и ОЛ намного сложнее, чем какой-нибудь p-code / IL и ОЛ.
Программировать ПР/ПЛК на C вряд ли будет много желающих.
И уж вряд ли будут желающие вообще весь стек с нуля создавать (ну, на C писать работу с 485, симулятор, online, загрузку программы и т.п.)

Сколько тут умельцев, способных и желающих написать свою прошивку для ПР? Ни-ко-го.
Разве что ради развлечения/хобби.

Поэтому я и говорю, что нужно не STM-32 на C программировать, а делать так, чтобы в ОЛ можно было добавлять программы-макросы, написанные на p-code / IL.
Разумеется, IL программы не вручную писать, а каким-нибудь генератором (компилятором). Например, пишем на ST -- получаем IL, вставляем IL в ОЛ.

[Алексей Геннадьевич]

Сколько тут умельцев, способных и желающих написать свою прошивку для ПР? Ни-ко-го.
Разве что ради развлечения/хобби.

Вопрос неправильно поставлен.
Правильный вопрос - нафига?
1)Приключений себе на задницу найти можно и более простыми способами.
А если так припекло, то:
2)Сравниваем цену на отладочную плату STM и ПР-200.
3) в промышленности "самопал" недопустим.

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

Вопрос неправильно поставлен

Читаем между строк или как?

Я же и говорю: никому не впилось программирование ПР на C.

я и говорю, что нужно не STM-32 на C программировать, а делать так, чтобы в ОЛ можно было добавлять программы-макросы, написанные на p-code / IL.

Переводя с русского на русский: прошивка ПР от ОВЕН, а прикладной код на IL. Разумеется, в IL не должно быть возможностей прямого доступа к памяти/портам ввода-вывода, а только оговоренный перечень инструкций.

Безопасность кода сохраняется, и всё норм.

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

Он может и появится через 1-2 года но к тому времени и ПР должна быть уровнем выше да это уже будет другой прибор это уж точно.

Тема "Модули расширения для ПР200" длится примерно эти самые 1-2 года и ничего.
Поэтому никуда за эти 1-2 года прогресс не сдвинется. Как есть сейчас ПР+ОЛ, так и останется. Как сейчас полезна возможность IL в ОЛ, так и через год-два никуда потребность не денется.

Ну, разве что конкуренты сделают.