*30--Если в коде есть список чего-либо (прототипы функций, макросы, перечисления), то эти строки должны > быть отсортированы по алфавиту.
Лучше группировать по семантике, а не по алфавиту.
46-- Include(ы) всегда должны только содержать название конечного файла. Include(ы) не должны содержать > часть пути к файлу.
Для файлов в подкаталогах, которые не используются по всему проекту, нет смысла добавлять путь в опции компилятора. А включать их с относительным путем, например #include "cyclical_buff/cyclical_buff.h"
Та он мне и даром не нужен. Для промышленного применения оно не годится, а для DIY собирают из готовых платок с али за копейки. Кто покупает Norvi - отдельный вопрос, требующий изучения.
Та понятно зачем, дешевле взять модуль на W5500 с али сомнительного качества чем трассировать LN8720. Да и места там маловато. А то что с W5500 это маргинальное направление, разработчиков видимо не волнует.
Не видел ни одного ПЛК в "металлическом" корпусе. Глючит оно из-за криворукости разработчиков печатной платы и схемотехники, а не из-за отсутствия экранирования.
Где-то на electronix.ru рекомендуют переход на основную прошивку выполнять после полного ресета, иначе возможны фокусы. Ну а определить что грузить — по флагу во флеш или в BkpSram.
Это вы привели какой-то поток сознания по теме философии разработки, а хотелось бы услышать конкретные преимущества для простого автоматизатора, не для разработчика ПО.
Для меня это до сих пор загадка, как например тот же Овен это делает. Они делают ПЛК под среду Codesys, вероятно и рантайм (транслятор с языков МЭК) предосавляет тот же Codesys. И видимо совсем не бесплатно.
Да и транслятор это одно, а пошаговая внутрисхемная отладка языков МЭК из среды — это отдельная тема, как она реализуется, мне тоже непонятно.
А то сейчас много «ПЛК», вон на ардуине несколько «ПЛК» есть в инете, только на поверку оказывается что никакой это не ПЛК.
С++ прекрасный сильнейший язык программирования. На нем можно запрограммировать любые задачи. Но, это компьютерный язык, а не язык спроектированный специально для ПЛК. Тут есть определенные особенности.
1) Для ПЛК важно иметь интегрированные отладочные средства,
заточенные под специфику автоматизации. Они должны позволять производить технологические операции с оборудованием. Например, при ремонте/наладке некой машины, техник/электрик/механик может машину остановить, вручную поуправлять выходами, проверить входы, зафиксировать выходы и т.п.
В CoDeSys это делается элементарно. Никаких программ писать не нужно вообще. Ни в одной среде С++ этого нет и близко. Там для элементарного задания нескольких последовательных наборов значений выходов, технику надо звать программиста и тратить время на программу.
2) Для ПЛК практически наплевать на эффективность кода, размер программы, экономию памяти, без которых не обойтись, например в базах данных, играх, при запуске непредсказуемо разных приложений пользователя и др. и пр.
Для ПЛК генератор кода должен давать простой дубово-надежный машинный код. Огромные массивы данных тут гонять не нужно. Рядом с ПЛК нет человека-контролера, который бы его перезагрузил при зависании. Да и сам подобный факт может быть фатальным. Поэтому из языков ПЛК намеренно выброшены все потенциально опасные штуки, типа new. В мире широко известны несколько громких аварий по причине примитивных программных ошибок в Си. В МЭК подобные ошибки сделать просто нельзя.
3) ПЛК всегда работает в реальном времени. В МЭК системы встроены свои переносимые средства многозадачности, обеспечения времени цикла, вызова задач по фронтам и т.п. Программисту МЭК нет дела какая ОС сидит внутри ПЛК. Изучать ее функции не надою. В С++ без этого никуда. Своих подобных средств в нем нет, он опирается на ОС. Ее надо изучать.
Ее качество влияет на программу непосредственно. Перенос программы из одной ОС в другую (если сразу не приняты специальные меры) представляет сложность.
4) Языки МЭК значительно проще в освоении. Это не декларация, а факт. Мы не раз сталкивались с обучением техников/наладчиков на заводах. Максимум полдня и электрик уже может выполнить минимально необходимые ему действия сам. Шансов его обучить С++ за полдня ноль. С++ язык для программистов профи. Он позволяет залезать на низкий
уровень и эффективно программировать на уровне железа. Ест-но такие программы требуют знаний, тестирования, по специальным методикам и пр.
5) Часто для некоего электронного устройства 1 программист пишет все от формирования времянок микросхем, до прикладных вещей на С++. Программа выглядит одним большим винегретом. Никто, кроме автора в этом разобраться не может. Он незаменим и обязан сопровождать свою программу, даже если это ему совсем уже не хочется. Руководитель не может отдать это сопровождение молодому специалисту, а этого квалифицированного человека перевести на более выгодную работу. Ни в от отпуск, никуда… У нас это классическая судьба С++ программиста.
Теперь делим софт на системный уровень и прикладной. Между ними простой, четко описанный интерфейс. Это переменные ввода/вывода и системные биб-ки. Системный софт четко разграничен и понятен. Его может писать любой программист, даже наемный. Его легко заменить. Аналогично с прикладным.
Это широко известная старая концепция разделяй и властвуй, но верная и ныне. Подробнее тут.
Для системного уровня С++ прекрасно подходит. Для прикладных задач МЭК языки прекрасно подходят.
Лучше группировать по семантике, а не по алфавиту.
Для файлов в подкаталогах, которые не используются по всему проекту, нет смысла добавлять путь в опции компилятора. А включать их с относительным путем, например #include "cyclical_buff/cyclical_buff.h"
Та он мне и даром не нужен. Для промышленного применения оно не годится, а для DIY собирают из готовых платок с али за копейки. Кто покупает Norvi - отдельный вопрос, требующий изучения.
Надежнее чем ESP с LAN8720? Или какая ESP? И как сравнивали надежность, это же надо одно и то же ПО залить на каждый МК.
Что значит под каждую задачу своя схемотехника? Те же ПЛК довольно унифицированы, никто в них не делает отдельную схемотехнику под каждую задачу.
И неужели покупают? Это же клондайк. Сделать дешевое железо, ПО не надо (это кстати 80% трудозатрат), в ардуинке все есть готовое.
Та понятно зачем, дешевле взять модуль на W5500 с али сомнительного качества чем трассировать LN8720. Да и места там маловато. А то что с W5500 это маргинальное направление, разработчиков видимо не волнует.
Не видел ни одного ПЛК в "металлическом" корпусе. Глючит оно из-за криворукости разработчиков печатной платы и схемотехники, а не из-за отсутствия экранирования.
Так можно сказать про любое устройство.
Можете привести КОНКРЕТНЫЙ пример где существующая система хуже, чем ваша и чем КОНКРЕТНО хуже?
Общаться через COM порт многие могут.
Да и транслятор это одно, а пошаговая внутрисхемная отладка языков МЭК из среды — это отдельная тема, как она реализуется, мне тоже непонятно.
А то сейчас много «ПЛК», вон на ардуине несколько «ПЛК» есть в инете, только на поверку оказывается что никакой это не ПЛК.