Вот на это ответьте, пожалуйста:Сообщение от игорь68
starmos верно сказал.
Сейчас же получается, что "политика партии" состоит в том, чтобы ОЛ было унылым. Хозяин-барин.
Перефразирую: если только и умеешь, что читать однолинейные схемы, то нечего говорить за архитектуру ПР-ОЛ.
Или так: создайте систему, которой сможет пользоваться дурак, и только дурак захочет ею пользоваться.
Для удобства можете считать и так.
Именно поэтому и появились "языки МЭК" как инструмент для инженера-ТЕХНОЛОГА, а не программиста.
Тем не менее, в той же промэлектронике во всю используют стандартные одноплатные компьютеры (начиная от ушедшего, но до сих пор используемого в нашей нефтянке micro PC == IBM/PC-XT, продолжая PC/104 и т.д.) но они программируются профессиональными программистами.
И что?
Уволился по общей несовместимости с остальным персоналом)
Взорвать ничего не успел, несмотря на то, что чего-то там даже понакрутил на котельной.
Тогда вы должны понимать, что пользовательская программа не зависит от версии разводки платы и тому подобного. И пользователь однозначно будет писать программу не под STM-контроллер, а под конкретную среду исполнения.Если это всё что там есть, тогда конечно полноценный линух не влезет. А так это вполне могут быть остатки от всей памяти, которые даны пользователю на свои нужды)32KiB RAM, 128KiB ROM и embedded linux?
Не верю (tm)
Я не знаю, конечно разные бывают предприятия, но по-моему, весьма маловероятно, чтобы ТЕХНОЛОГ занимался автоматизацией.
Он даст задачу АСУшнику, а АСУШник уже скажет, что нужно для этого купить и сам будет всё программировать.
У нас например, технологи вообще компьютером пользоваться не умеют)
ASo
starmos
Сей спор ведётся ещё со времён Фон-Неймана, который шпынял и троллил коллег которые пользовались новомодным языком-ассемблером. "Что это за математики-программисты такие, что машинный код в голове удержать не могут?
Моё мнение - если на написание программы на FBD и её отладку+ПНР уйдёт неделя, а на то-же самое на С - месяц, то выбор очевиден даже при равных зарплатах инженера АСУ и программиста.
Оттуда-же, откуда и электрики не знающие закон Ома. И приводчики, которые на привод смотрят как баран на новые ворота.
Считал себя самым умным при нулевом опыте?
Последний раз редактировалось Алексей Геннадьевич; 15.03.2017 в 08:33.
Файл прошивки для ПР200 занимает 156 КиБ
Файл прошивки для ПР110 занимает 32 КиБ
См. выше. Ресурсов негусто и надеяться на богатую среду исполнения вряд ли придётся.
Ещё раз повторю свою мысль: едва ли сейчас прошивки ПР заточены под то, чтобы к ним можно было легко подключать самописные функции на C. Можно ли сделать такую "среду окружения"? Конечно, сделать можно почти что угодно, но сделать это непросто.
Я утверждал, что "добавить в ПР поддержку заливки написанных на C функций непросто". Возражения есть? Есть хотя бы пример "вон, у таких-то контроллеров легко совмещаются FBD и C программирование"?
Ежу понятно, что сделать "окружение" можно, если очень захотеть. Другое дело, что, если изначально такой цели не стояло, то прикрутить такое окружение пост-фактум непросто.
Раз у них есть в ОЛ графический редактор, то они в итоге должны генерировать то, что в схемотехнических САПР называется netlist - список цепей, который описывает какая цепь от какого вывода и к какому идет. Имена выводов известны, какие из них входы, какие выходы - тоже и все это в списке цепей. Макросы уже есть - на одном уровне иерархии вы видите макросы с входами/выходами, а глубже - содержимое макроса, при этом видите те же всходы/выходы. И в итоге все это транслируется в машинные коды. Так в чем проблема обозвать макрос как "написанный на С" и откомпилировать его отдельно, а редактор связей свяжет его по именам переменных (входов/выходов)? Это все уже делается сейчас, только макросы (подпрограммы, модули) сейчас представляются в виде схемы, а не текста. Это просто вы так видите программу в процессе разработки, а на самом деле она в итоге однородна, хоть на чем макросы пиши.
Блин. Такое ощущение, что вы вообще не сталкивались с разработкой компилятора.
Приведу пример: сложно будет поддержать этот "написанный на C" в режиме "симуляции".
Допустим, с помощью лома получилось из C текста получить бинарный код. Внимание, вопрос: как тестировать этот макрос? Как тестировать программу, использующую этот макрос?
Не забываем, что online режима у ПР нет, т.е. возможности "залить в ПР" для теста тоже нет.
Но и сама задача "скомпилировать" непростая. Разрабатывать свой C-компилятор это неблагодарное дело, а прикручивать сторонние непросто.
Вы никогда не сталкивались с системами схемотехнического моделирования, Proteus то же? Нарисованная схема моделируется в "реальном" времени, при этом модели могут быть макро (содержать в себе тоже схему) или выполненными в текстовом виде, а микроконтроллер на схеме может моделироваться с учетом его программы, написанной на С. Как они это делают - для меня тоже загадка, но сам факт несомненен. Но такого даже и не надо вовсе.
"Прикрутить" к среде разработки тот или иной компилятор - обычное дело, например софт для микроконтроллеров Atmel можно разрабатывать на С с помощью нескольких компиляторов, это вообще обычно для микроконтроллеров, а что и как компилировать - задается в командных файлах. Сперва видится проход компилятора из схемы в C, макросы на С - пропускаются, а затем проход компилятора С уже полностью. Как вариант.
Ваши права
