Где-то на electronix.ru рекомендуют переход на основную прошивку выполнять после полного ресета, иначе возможны фокусы. Ну а определить что грузить — по флагу во флеш или в BkpSram.
Это вы привели какой-то поток сознания по теме философии разработки, а хотелось бы услышать конкретные преимущества для простого автоматизатора, не для разработчика ПО.
Для меня это до сих пор загадка, как например тот же Овен это делает. Они делают ПЛК под среду Codesys, вероятно и рантайм (транслятор с языков МЭК) предосавляет тот же Codesys. И видимо совсем не бесплатно.
Да и транслятор это одно, а пошаговая внутрисхемная отладка языков МЭК из среды — это отдельная тема, как она реализуется, мне тоже непонятно.
А то сейчас много «ПЛК», вон на ардуине несколько «ПЛК» есть в инете, только на поверку оказывается что никакой это не ПЛК.
С++ прекрасный сильнейший язык программирования. На нем можно запрограммировать любые задачи. Но, это компьютерный язык, а не язык спроектированный специально для ПЛК. Тут есть определенные особенности.
1) Для ПЛК важно иметь интегрированные отладочные средства,
заточенные под специфику автоматизации. Они должны позволять производить технологические операции с оборудованием. Например, при ремонте/наладке некой машины, техник/электрик/механик может машину остановить, вручную поуправлять выходами, проверить входы, зафиксировать выходы и т.п.
В CoDeSys это делается элементарно. Никаких программ писать не нужно вообще. Ни в одной среде С++ этого нет и близко. Там для элементарного задания нескольких последовательных наборов значений выходов, технику надо звать программиста и тратить время на программу.
2) Для ПЛК практически наплевать на эффективность кода, размер программы, экономию памяти, без которых не обойтись, например в базах данных, играх, при запуске непредсказуемо разных приложений пользователя и др. и пр.
Для ПЛК генератор кода должен давать простой дубово-надежный машинный код. Огромные массивы данных тут гонять не нужно. Рядом с ПЛК нет человека-контролера, который бы его перезагрузил при зависании. Да и сам подобный факт может быть фатальным. Поэтому из языков ПЛК намеренно выброшены все потенциально опасные штуки, типа new. В мире широко известны несколько громких аварий по причине примитивных программных ошибок в Си. В МЭК подобные ошибки сделать просто нельзя.
3) ПЛК всегда работает в реальном времени. В МЭК системы встроены свои переносимые средства многозадачности, обеспечения времени цикла, вызова задач по фронтам и т.п. Программисту МЭК нет дела какая ОС сидит внутри ПЛК. Изучать ее функции не надою. В С++ без этого никуда. Своих подобных средств в нем нет, он опирается на ОС. Ее надо изучать.
Ее качество влияет на программу непосредственно. Перенос программы из одной ОС в другую (если сразу не приняты специальные меры) представляет сложность.
4) Языки МЭК значительно проще в освоении. Это не декларация, а факт. Мы не раз сталкивались с обучением техников/наладчиков на заводах. Максимум полдня и электрик уже может выполнить минимально необходимые ему действия сам. Шансов его обучить С++ за полдня ноль. С++ язык для программистов профи. Он позволяет залезать на низкий
уровень и эффективно программировать на уровне железа. Ест-но такие программы требуют знаний, тестирования, по специальным методикам и пр.
5) Часто для некоего электронного устройства 1 программист пишет все от формирования времянок микросхем, до прикладных вещей на С++. Программа выглядит одним большим винегретом. Никто, кроме автора в этом разобраться не может. Он незаменим и обязан сопровождать свою программу, даже если это ему совсем уже не хочется. Руководитель не может отдать это сопровождение молодому специалисту, а этого квалифицированного человека перевести на более выгодную работу. Ни в от отпуск, никуда… У нас это классическая судьба С++ программиста.
Теперь делим софт на системный уровень и прикладной. Между ними простой, четко описанный интерфейс. Это переменные ввода/вывода и системные биб-ки. Системный софт четко разграничен и понятен. Его может писать любой программист, даже наемный. Его легко заменить. Аналогично с прикладным.
Это широко известная старая концепция разделяй и властвуй, но верная и ныне. Подробнее тут.
Для системного уровня С++ прекрасно подходит. Для прикладных задач МЭК языки прекрасно подходят.
Все ограничивается что есть пользователи ПЛК, у них например есть Codesys. Программируется ли ваш ПЛК из Codesys? Нет? Значит есть своя среда с поддержкой одного из популярных языков? Нет? Аа, можно в IAR на С++ запрограммировать? Чудесно.
Для программирования ПЛК используются стандартизированные языки МЭК (IEC) стандарта IEC61131-3
Языки программирования (графические)
LD (Ladder Diagram) — Язык релейных схем — самый распространённый язык для PLC
FBD (Function Block Diagram) — Язык функциональных блоков — 2-й по распространённости язык для PLC
SFC (Sequential Function Chart) — Язык диаграмм состояний — используется для программирования автоматов
CFC (Continuous Function Chart) — Не сертифицирован IEC61131-3, дальнейшее развитие FBD
Языки программирования (текстовые)
IL (Instruction List) — Ассемблеро-подобный язык
ST (Structured Text) — Паскале-подобный язык
Я 4 KB использую как буфер значений датчика. При отключаниях питания буфер не стирается, этим гарантируется непрерывный мониторинг.
Ну и плюс в этих 4 KB хранится запись SytemHealth, там вся инфа о возникших ошибках/ассертах, срабатываниях вочдога и т.д. за все время работы. Очень помогает увидеть качество работы устройства в реальных условиях у заказчика. А то может быть ситуация когда девайс у заказчика перезагружается по вочдогу, а разработчик об этом никогда и не узнает.
Ну почему же не имеют. Кому то захочется одно мощное реле и датчик движения, кому то датчик влажности и радио и т.д. Это же десятки плат надо плодить для всего разнообразия.
Ну да, тут ограничение то что модули друг над другом. А не было задумки компоновать готовые устройства из этих модулей, или только для прототипирования? Хотя для готового модульного девайса нужен модульный корпус и оптимизация самих модулей по стоимости.