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

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

Но надо понимать, что кроме нас четверых - пятерых, 28 страниц никто читать не будет.

По факту, читают, делятся мнениями. Зачастую даже по теме, и это при том, что тема действительно неширокая.

Из нас четверых вряд ли кто-то, де факто, будет использовать p-code

И да и нет.

Поднимался вопрос (возможно и не однократно) "дайте хоть какой-нибудь язык кроме квадратиков".
Я не про себя, и не про вопли "сделайте же C в ОЛ".

Использовать p-code можно по-разному. Можно макросы составлять, а можно эти макросы использовать в проектах.
Так вот: соглашусь, желающих составлять макросы на p-code будет меньше, чем общее количество пользователей ОЛ.
Но, если будет макрос, то его смогут использовать все. В том числе и те, кто сам бы такой макрос составить не смог.

а остальные просто не дочитают этот триллер. С учетом, что на 26 странице звучит, к стати совершенно справедливо вопрос - а что это. На 24 странице...

Тема "вопрос-ответ (новичковая)", например, тоже не предназначена для "дочитывания".
Да, многие и не понимают что такое p-code, но:
1) Это слово вполне даёт понять (кому надо) что я имею ввиду
2) Это нормально, когда пользователи ОЛ-ПР не понимают как оно устроено. Вопрос "что такое p-code" в этом плане мало чем отличается от вопроса "что такое прошивка". Многие понятия не имеют как устроена прошивка ПР, но это не мешает им создавать проекты.
3) Если грубо, то для конечного пользователя p-code блок можно сравнить с "макросом, написанным на IL". С точки зрения "обывателя-рисователя квадратиков", язык IL ущербен, непонятен, и непонятно зачем нужен. Но, с точки зрения взаимодействия систем, подобие языка IL это как раз то, что нужно. IL легко реализовать, и в нём сохраняется вся мощь. "Тот самый ST" можно можно превращать в IL (читай -- в p-code) и таким образом можно получить "ST макросы в ОЛ" и не нагружать ОЛ ST редактором.
4) В пользовательском интерфейсе же отображение этого самого p-code как IL можно и НЕ делать. Формат записи Apache Thrift или Google Protocol Buffers может быть гораздо более удобным в разработке, т.к. текстовое представление IL приходилось бы парсить, а Thrift/protobuf предоставляют готовые средства для чтения и записи сообщений.

[starmos]

Самое замечательное - это не то что "28 страниц никто не будет читать" (по факту - читают), а то что эти 28 страниц вообще существуют. Странно, что вообще приходится убеждать в необходимости макросов на текстовом языке. Наверное действительно архитектура ПО в ПР200 какая-то необычная, потому что я так и не понял - почему добавить указанную возможность нельзя или сильно дорого. Меня бы вообще не волновал этот вопрос, будь аппаратные возможности ПР200 хуже, процессор например 8-разрядный дохлый или что. Но на сегодняшний день я вижу, что расширить функционал ПР200 буквально ничего не стоит, относительно всех других усилий, уже затраченных на его проектирование и постановку производства. Я не являюсь экспертом, но имею все же не маленький многолетний опыт в автоматике и электронике, в том числе и в проектировании и создании микропроцессорных систем, поэтому все же могу судить.

[ASo]

Вы создавали микропроцессорные системы, которые программировались ИХ ПОТРЕБИТЕЛЕМ на разработанной вами инструменталке не на АССЕМБЛЕРЕ или С?

[melky]

Использовать p-code можно по-разному. Можно макросы составлять, а можно эти макросы использовать в проектах.
Так вот: соглашусь, желающих составлять макросы на p-code будет меньше, чем общее количество пользователей ОЛ.
Но, если будет макрос, то его смогут использовать все. В том числе и те, кто сам бы такой макрос составить не смог.


именно об этом чаще всего и идет речь...

[starmos]

Вы создавали микропроцессорные системы, которые программировались ИХ ПОТРЕБИТЕЛЕМ на разработанной вами инструменталке не на АССЕМБЛЕРЕ или С?

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

[starmos]

Использовать p-code можно по-разному. Можно макросы составлять, а можно эти макросы использовать в проектах.
Так вот: соглашусь, желающих составлять макросы на p-code будет меньше, чем общее количество пользователей ОЛ.
Но, если будет макрос, то его смогут использовать все. В том числе и те, кто сам бы такой макрос составить не смог.


именно об этом чаще всего и идет речь...

Кстати да, может кому и не надо сразу создание макросов на текстовом языке, но получив такой макрос в готовом виде от кого-нибудь, он его может посмотреть/изменить и в дальнейшем может написать и свой. В итоге человек обучится. А если возможности нет, то и возможного развития тоже нет. Об этом забывают часто.

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

Не понимаю вашего вопроса - я за то чтобы С был как вариант, для написания макросов. Чем это помешает тем, кто мыслит "кубиками" - мне не понятно, т.к. "кубики" в любом случае останутся.

Само по себе "наличие C" не помешает кубистам.
Но поймите же, наконец. "Сделать C в ОЛ" потребует очень больших затрат. Прямо настолько больших, что и ждать, что ОВЕН реально сделает это самое С нет никакого смысла.

Если очень хочется "С в ОЛ", то открывайте свою тему про это и вперёд. С этим самым Си море проблем: сообщения об ошибках, проверка корректности кода (например, выход за границу массива), симуляция, автодополнение, online и прочее прочее.


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

[starmos]

Само по себе "наличие C" не помешает кубистам.
Но поймите же, наконец. "Сделать C в ОЛ" потребует очень больших затрат. Прямо настолько больших, что и ждать, что ОВЕН реально сделает это самое С нет никакого смысла.

Если очень хочется "С в ОЛ", то открывайте свою тему про это и вперёд. С этим самым Си море проблем: сообщения об ошибках, проверка корректности кода (например, выход за границу массива), симуляция, автодополнение, online и прочее прочее.


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

Хорошо, я согласен на p-code, если он мне позволит делать то же, что я мог бы делать на С:вычисления, массивы, строки, обработка данных и т.д. Пусть уже что-нибудь будет - какой язык, это не принципиально.

[dim1987]

Надо ардуино запилить под пр200))

[rovki]

Да там и С и FBD ,причем в одном флаконе -FLProg .