Ну тогда делайте как тут https://habr.com/ru/articles/1059562/ Корпус только на алике найти подходящий. Туда еще надо поставить микросхему ToF сенсора, IR сенсора, барометра. и будет на порядок круче Aqara FP300, а по цене если заказать на JLPCB будет почти также. Ставите везде один и тот же сенсор, и закрываете полностью тему с подсчетом людей, ложными срабатываниями, надежностью и долговечностью и приватностью. Все соединяете одной шиной CAN. Логику всего дома пишите на такого же типа плате. Никаких лишних контроллеров не надо. Fable 5 за пару дней все запрограммирует.
Трассировка и расстановка выглядят эффектно. Попробовал. За 60$ и за час эта GPT 6 дошла только до этапа прорисовки доменов питания. Claude Opus 5 за тоже время страссировал в KiCAD 10 цепей из 500. А Fable 5.1 страссировал сразу 200 цепей. Довольно криво, но хоть DRC не нарушил. И быстрее всех разобрался. Хотя может потому что я контекст передавал от одного чата другому. Вся канитель длилась 4 часа.
Похоже Dassault Systèmes и Autodesk в этом году не рухнут. Но в следующем уже могут. Мне кажется понятно от кого отобъют деньги все эти датацентры.
Вот первая версия. Была сделана на R7FS5D9 и EFR32MG24 Но не хватало памяти для всех фичей. Теперь больше на китайскую комплектацию ориентируюсь.
Идея выводить на экран такого дивайса карту довольно интересная. Поскольку у вас не специфицирован тип дисплея я попробовал симулировать вывод на мой монохромный.
Это то что мой промпт может предложить для моего дивайса
Это извините то что делает сейчас ваш 2-битный e-link
По оценке вся административная Москва с Новой Москвой в вашем формате займет 50–140 МБ. Размер мизерный, я бы не экономил и сделал более детализированый формат. Но идея сама по себе прекрасная. Кстати, как вы планируете бороться с инерционностью e-link?
Я свой проект думаю выложить как нибудь по осени. Если к тому времени AI не научится делать такие вещи сам за один проход.
Зачем тратить время на чужое если можно сделать своё? Вот делаю велокомпьютер - https://habr.com/ru/articles/1018540/ Плата уже готова. Софт будет открытый. Кроме BLE имее WiFi , синхронизируется с облаками, получить погоду не вопрос, соединится с другими такими же дивайсами тоже. Может сам отправить трек в Google Maps и вообще куда угодно.
Стоики учили мудрости и всеобщему человеческому братству, но не смогли распознать чудовищную несправедливость рабства, находившуюся у них перед глазами. Они приняли её за обычное устройство мира - точно так же, как мы, возможно, сегодня принимаем за норму то, что в будущем покажется моральным варварством. Наша способность замечать несправедливость тоже исторически ограничена. И это существенно обесценивает претензию стоицизма на роль универсального социального и нравственного учения.
У ST существует официальный ES0647 — X-CUBE-CLASSB self-test library software errata, где описана буквально эта самая ошибка:
APSR register content is incorrectly assumed to have all GE bits cleared during the test.
И ST прямо пишет, что при GE != 0 функция CPU TMCB способна вернуть STL_FAILEDна полностью исправном процессоре. Это классифицировано как false positive.
Не понимаю зачем так мусолить повествование о примитивном баге про который знает любая заштатная модель. Или на подписке экономите?
Ну да, всё возвращается к деньгам. Про $20/мес. - это миф. Но ход мыслей правильный. Но нет, не удастся обхитрить эту систему. У кого дороже план, тот и в дамках, какие бы скиллы ни придумывали. Всё становится проще и жёстче.
Тут полемика без цифр. А в них самый дъявол. Мне модель узнает все про измения протоколов за считанные минуты и внесет правки за минуты. И протестирует за минуты , итого 10 мин. Нет ничего для них сейчас боле простого как починить протокол. Ваш личный скил здесь - не потерять концентрацию хотя бы полчаса. Эт тоже надо тренировать. А "Ваши конкуренты, которые занимаются только аналогичным продуктом" , которые работают по старому потратят эти 10 мин обсуждая в свое курилке какой X нехороший что поменял протокол.
Ваш ответ, чувствую, подготовлен GPT. Я тоже от него получаю такие вот наивные сценарии. Это от того, что он сценарии пишет с точки зрения прошлого опыта, не вставляя самого себя в них.
Ну вал статей тут про агентов я бы спокойно пропускал мимо ушей. Кому-то хочется делать "план по валу", и ничего хайповей агентов не находят.
Я же устал уже отбиваться от агентов. Только дай Fable какую-нибудь задачку поработать с сорсами, как он вмиг создаст с десяток агентов и сожрёт весь лимит за минуты. Приходится отдельно писать ему, чтобы не создавал агентов. Модель одна спокойно в одном потоке управляется. Но эта мода на агентов добралась уже и до GPT. Claude хоть напишет, сколько агентов создал. А этот втихаря их запустит. Хорошо хоть скидку временно дали.
Так что за свои слабые скиллы по части агентов не переживайте. Это не то, во что надо вкладываться. Сами агентские скиллы сторонние я тоже сильно бы не переоценивал. Часто они слишком раздуты. У меня скиллы рождаются автоматически. Модель всё сама найдёт рано или поздно, что написано в каком-либо из существующих в мире скиллов. Но иногда я вижу, что начинает лагать. И это знак: значит, надо сказать ей, чтобы в конце написала скилл про то, чем занималась. Вот и всё. Много ума тут не надо.
Вкладываться я бы сейчас стал в количество проектов. Это же очевидно. Сейчас можно тянуть пять проектов вместо одного. Раньше и один шёл кое-как, всё время надо было держать контекст в памяти. Теперь войти в курс - дело пары минут. value innovation я вижу в подходе "почти индивидуальный продукт по цене массового"
Отсюда кстати ответ на вопрос где эти "выдающиеся приложения". Их нет! Они больше не нужны, эти универсальные приложения для всех.
Автор - сомнительный эксперт. Историю с IoT-датчиком для умного дома с 128 КБ ОЗУ, скорее всего, выдумал. Какая может быть динамическая память при таком объёме? Откуда он это взял? Первое, на что он должен был напороться, - переполнение стеков. Его мечты про стеки в 4–16 КБ - это артефакты больших операционок. А в таких девайсах 1 КБ уже роскошь. Если он брал опенсорсный сетевой стек, то в них всех уже есть пулы пакетов фиксированной длины. Он не должен был вообще притягивать сюда динамическую память. Надо было в первую очередь озаботится глубиной пула. Потом о какой «предсказуемости важнее гибкости» он может говорить в IoT-девайсе, где в любое мгновение может отвалиться связь? Там нет никакой такой важной предсказуемости. Первое, что он должен был сделать, - реализовать получение памяти с таймаутом, как в большинстве RTOS сделано. Его датчики могут и подождать, пока память недоступна. А если всё равно недоступна, то выполнять ресет. IoT-девайсы ресет должны воспринимать как штатную операцию. Им всё равно в Deep Standby нужно переходить периодически с возвратом через ресет.
Это ваш опыт, а не мой. Я имею дело с огромнымы сторонними библиотеками RTOS и middleware. Их приходится проверять разом и целиком. Свой то код я пишу чисто, там не к чему придраться. Я даже тернарные операторы не применяю, минимум косвенных вызовов. Минимальное подмножество C. Даже ретаргетинг не делаю, потому что не использую функций C требующих ретаргетинга. А вот библиотеки править - это тяжелый выбор. Хотите ли вы их потом сами поддерживать после правок? Так вот теперь с Claude я правлю и кромсаю все что находится в репозитариях. Никаких проблем из 1000 файлов сделать 100. Но только анализаторы тут уже не при чем. Дока тоже пишется мгновенно, эту тему можно закрыть.
ctrlX CORE это 64 Bit Quad-Core ARM CPU и 2 Гб RAM И все ради каких-то 125 мкс И вы хотите сказать, что будущее вот такое - дорогущие платформы на избыточном софте?
Я же думаю : Там все это только лишь от того, что код был по любому дороже. А теперь когда код стал дёшев, они разорятся на таких монстрах.
Ну да, если что не сходится, то надо привлечь магию. А именно асушника, который способен в doсker запаковать приложение организующее доступ к клемам через K-Line, не выключая runtime и не вынимая ПЛК из рабочей стойки. Фантастика. Он там только WEB страничку поменять может и то не факт.
Знаете, CODESYS ведь изначально был сделан под микроконтроллеры с RTOS, а не Линукс. И да, там изначально пользоваетель грузил приложения не пересобирая runtime. Пересобирать runtime или нет - это очень мелкий ворос.
У меня к примеру сейчас приложение из пары тысяч файлов , они состовляют фреймворк общий для кучи проектов. Я мог бы спокойно его изолировать и сделать из него такой отдельный модуль. Но мне это не нужно. Зачем мне от себя что-то изолировать? Я его перекомпилирую каждый день вместе с прикладным кодом. Благодаря этому он у меня теперь проверен вдоль и поперёк, при любых уровнях оптимизации , при любых раскладах памяти. А если вы держите runtime как священную корову, к ней не прикасаясь, то сами себя лишаете гибкости. Кто решил что такой runtime эффективен? Тот кто даже не видел ваши задачи! Нет, runtime можно и должно менять. Теже протоколы, они постоянно меняются. А ведь они в runtime. К кому бежите чтобы там поменять пару команд?
Так что аргумент "зато мы не трогаем runtime" ну совсем не катит.
А некритичным задачам так и вовсе ПЛК не нужен. Он и дорог, и место занимет и потребляет как не в себе.
WEB сервер по HTTPS и всеми поддержками сертификатов у ThreadX не хуже чем в Линуксе.
И еще момент. В WAGO PFC200 runtime c CODESYS единолично захватывает драйвер шины клемников K-Line. Свое приложение либо должно отключить CODESYS чтобы забрать драйвер и само организовать цикл, либо в runtime химичить мост. И опять ваше утверждение про "зато мы не трогаем runtime" не катит.
Тут еще прикол буквально сейчас я схватил. Claude Fable отказывается работать с исходниками, где просишь сделать защиту доступа к контроллеру. Т.е. теперь trust zone в Линуксе вне закона для простых смертных. Это еще один повод не лезть в системы с внешними носителями кода.
Просто вы почему-то странно заостряете внимание на "пересобрать, загрузить и заново протестировать". Как будто в Линуксе не нужно загружать и тестировать. Пересобрать да, если у вас скрипты, то не нужно. Но и реальное время тогда вам не светит. А если мне не нужно реального времени, то я и планшет могу приспособить под ПЛК и даже терефон. Т.е. это это уже не совсем ПЛК. Пересборка под RTOS длится секунды. Не надо думать что подгружаемые исполняемые модули есть только в Линуксе. В ThreadX также есть механизм подгрузки исполняемых модулей. Это не какая-то магия, а довольно примитивный процесс. И под RTOS можно все подключть позднее. Или хотитет сказать, что изучить сам API Modbus RTU и все опции запуска и их влияние вы под Линуксом быстрее сделаете? Да нет, вы это сделаете это медленнее. Потому что имеете там меньше инструментов отладки реального времени. Потому что вы лишаетесь сквозной отладки. В жестком реальном времени нужна сквозная отладка от момента вызова файловой операции и до выдачи команды CMD52 на интерфесе SDIO. Иначе месяцами будете ждать ответа вендора и ручками бегать сбрасывать свой контроллер. В RTOS я могу через трассировку в SWD видеть не то что все вызовы, а все потоки прерываний в реальном времени и не использовтаь при этом никакого инструментального кода. Про архивы вообще бы не говорил. У вас там такая же SD карта, как и в RTOS. Но ваш драйвер этой карты не вылизан так как они вылизаны под RTOS. Не согласованы каналы DMA, не выставлены приоритеты у этих каналов, не очищено все от избыточности косвенных вызовов и абстракций, не убраны избыточне объекты синхронизации и т.д. и т.п.
SQLite, OPC UA, Modbus-RTU уже давно портированы на RTOS для мелких контроллеров. Им Линукс не нужен от слова совсем. InfluxDB - требует от 1 Гб RAM-а , это не про Линукс, а про масштаб. Python и Grafana - в embedded лишние надсройки. ИИ агенты теперь делают графики в каком угодно стиле и формате вообще не привлекая сторонние тулсы на голом css и js Конверетеры протоколов однозначно на RTOS будут работать быстрее и детерминирование Подключаться к облакам теперь умеет любой ESP. А Amazon специально для FreeRTOS сделал модуль подключения к AWS. В ThreadX есть спецально под нее модуль подключения к Microsoft Azure IoT. И там есть всё: апгрейд прошивки по воздуху , автоматическое развертывание миллионов дивайсов, телеметрия, управление по MQTT и проч.
Но какие приложения? Можете назвать что нибудь стоящее, кроме питона , Node-RED, Arduino и прочих интепретаторов-прокладок, необходимость в которых полностью отпадает при наличии агентов прямо пишущих на C. С вашим понятием "открытости" и Windows можно назвать полностью открытой операционкой. Потом интересно какой минимальный период цикла поддерживает ваше решение на Линуксе? На обычном микроконтроллере 240 МГц нормально держать жесткий цикл в 100 и меньше мкс.
Да уж и времена когда для подключения к AWS по MQTT, OPC UA или WEB сервер нужен был Линукс тоже прошли. Сейчас это достаточно легко делается на обычной легковесной RTOS типа ThreadX или FreeRTOS. Современные агенты за пару дней перенесут все нужные стеки на RTOS включая навороченные GUI и базы данных.
Кстати, ПЛК типа WAGO PFC200 не делают на одном процессорном чипе. Вот у меня такой один убитый лежит :
Тут как минимум два SoC и две разные операционки. И по ходу есть место еще для одного SoC
Убить такие контроллеры достаточно легко. Программа выполняется из DDRAM, грузится из NAND. Куча мест где что-то может пойти не так. Но они никогда не станут открытыми, потому что в них всегда есть какой нибудь кастомный чип на шине. Их межмодульная шина - самый большой секрет. Проблема еще в том что программу хранимую вне SoC гораздо труднее защитить. А в Европе, к примеру, вступает в силу Cyber Resilience Act. И с ним сделать защиту Линукса ох как нелегко. Придется возится с Trusted Firmware-A или с OP-TEE. А иначе не дадут разрешение на использование нигде. А с обычным микроконтроллером прожег фьюзы и все! Дело сделано.
Поэтому на мой взгляд надежней ПЛК будет на SoC с интегрированной Flash и RAM с Error-Correcting Code. Таких сейчас достаточно много дешевых: RP2354 , ESP32-P4 , RA8P1 , STM32N657 ... Вот за ними-то и вижу перспективы. И дёшево, и надёжно.
А смысл? Индивидуальный Allan-анализ каждого MEMS врядли существенно повысит точность INS. Только время будет зря потеряно на тюнинг алгоритмов. Температура и время свое отыграют. С другой стороны в даташитах и так написаны предельные шумы и девиации.
Ну тогда делайте как тут https://habr.com/ru/articles/1059562/
Корпус только на алике найти подходящий.
Туда еще надо поставить микросхему ToF сенсора, IR сенсора, барометра.
и будет на порядок круче Aqara FP300, а по цене если заказать на JLPCB будет почти также.
Ставите везде один и тот же сенсор, и закрываете полностью тему с подсчетом людей, ложными срабатываниями, надежностью и долговечностью и приватностью.
Все соединяете одной шиной CAN. Логику всего дома пишите на такого же типа плате. Никаких лишних контроллеров не надо. Fable 5 за пару дней все запрограммирует.
Трассировка и расстановка выглядят эффектно.
Попробовал. За 60$ и за час эта GPT 6 дошла только до этапа прорисовки доменов питания.
Claude Opus 5 за тоже время страссировал в KiCAD 10 цепей из 500.
А Fable 5.1 страссировал сразу 200 цепей. Довольно криво, но хоть DRC не нарушил. И быстрее всех разобрался. Хотя может потому что я контекст передавал от одного чата другому. Вся канитель длилась 4 часа.
Похоже Dassault Systèmes и Autodesk в этом году не рухнут.
Но в следующем уже могут.
Мне кажется понятно от кого отобъют деньги все эти датацентры.
Судя по видео, если придется показывать одновременно скорость, пульс, каденс, мощность, путь, время, то там будет катастрофа со скоростью прорисовки.
Вот первая версия. Была сделана на R7FS5D9 и EFR32MG24
Но не хватало памяти для всех фичей.
Теперь больше на китайскую комплектацию ориентируюсь.
Идея выводить на экран такого дивайса карту довольно интересная.
Поскольку у вас не специфицирован тип дисплея я попробовал симулировать вывод на мой монохромный.
По оценке вся административная Москва с Новой Москвой в вашем формате займет 50–140 МБ.
Размер мизерный, я бы не экономил и сделал более детализированый формат.
Но идея сама по себе прекрасная. Кстати, как вы планируете бороться с инерционностью e-link?
Я свой проект думаю выложить как нибудь по осени. Если к тому времени AI не научится делать такие вещи сам за один проход.
Зачем тратить время на чужое если можно сделать своё?
Вот делаю велокомпьютер - https://habr.com/ru/articles/1018540/
Плата уже готова. Софт будет открытый. Кроме BLE имее WiFi , синхронизируется с облаками, получить погоду не вопрос, соединится с другими такими же дивайсами тоже.
Может сам отправить трек в Google Maps и вообще куда угодно.
Стоики учили мудрости и всеобщему человеческому братству, но не смогли распознать чудовищную несправедливость рабства, находившуюся у них перед глазами. Они приняли её за обычное устройство мира - точно так же, как мы, возможно, сегодня принимаем за норму то, что в будущем покажется моральным варварством.
Наша способность замечать несправедливость тоже исторически ограничена.
И это существенно обесценивает претензию стоицизма на роль универсального социального и нравственного учения.
У ST существует официальный ES0647 — X-CUBE-CLASSB self-test library software errata, где описана буквально эта самая ошибка:
И ST прямо пишет, что при
GE != 0функция CPU TMCB способна вернутьSTL_FAILEDна полностью исправном процессоре. Это классифицировано как false positive.Не понимаю зачем так мусолить повествование о примитивном баге про который знает любая заштатная модель. Или на подписке экономите?
Ну да, всё возвращается к деньгам.
Про $20/мес. - это миф. Но ход мыслей правильный.
Но нет, не удастся обхитрить эту систему.
У кого дороже план, тот и в дамках, какие бы скиллы ни придумывали.
Всё становится проще и жёстче.
Тут полемика без цифр. А в них самый дъявол.
Мне модель узнает все про измения протоколов за считанные минуты и внесет правки за минуты. И протестирует за минуты , итого 10 мин.
Нет ничего для них сейчас боле простого как починить протокол.
Ваш личный скил здесь - не потерять концентрацию хотя бы полчаса. Эт тоже надо тренировать.
А "Ваши конкуренты, которые занимаются только аналогичным продуктом" , которые работают по старому потратят эти 10 мин обсуждая в свое курилке какой X нехороший что поменял протокол.
Ваш ответ, чувствую, подготовлен GPT. Я тоже от него получаю такие вот наивные сценарии. Это от того, что он сценарии пишет с точки зрения прошлого опыта, не вставляя самого себя в них.
Ну вал статей тут про агентов я бы спокойно пропускал мимо ушей.
Кому-то хочется делать "план по валу", и ничего хайповей агентов не находят.
Я же устал уже отбиваться от агентов. Только дай Fable какую-нибудь задачку поработать с сорсами, как он вмиг создаст с десяток агентов и сожрёт весь лимит за минуты.
Приходится отдельно писать ему, чтобы не создавал агентов. Модель одна спокойно в одном потоке управляется.
Но эта мода на агентов добралась уже и до GPT. Claude хоть напишет, сколько агентов создал. А этот втихаря их запустит. Хорошо хоть скидку временно дали.
Так что за свои слабые скиллы по части агентов не переживайте. Это не то, во что надо вкладываться.
Сами агентские скиллы сторонние я тоже сильно бы не переоценивал. Часто они слишком раздуты. У меня скиллы рождаются автоматически. Модель всё сама найдёт рано или поздно, что написано в каком-либо из существующих в мире скиллов. Но иногда я вижу, что начинает лагать. И это знак: значит, надо сказать ей, чтобы в конце написала скилл про то, чем занималась. Вот и всё. Много ума тут не надо.
Вкладываться я бы сейчас стал в количество проектов. Это же очевидно.
Сейчас можно тянуть пять проектов вместо одного. Раньше и один шёл кое-как, всё время надо было держать контекст в памяти. Теперь войти в курс - дело пары минут.
value innovation я вижу в подходе "почти индивидуальный продукт по цене массового"
Отсюда кстати ответ на вопрос где эти "выдающиеся приложения". Их нет! Они больше не нужны, эти универсальные приложения для всех.
Автор - сомнительный эксперт.
Историю с IoT-датчиком для умного дома с 128 КБ ОЗУ, скорее всего, выдумал.
Какая может быть динамическая память при таком объёме? Откуда он это взял?
Первое, на что он должен был напороться, - переполнение стеков.
Его мечты про стеки в 4–16 КБ - это артефакты больших операционок. А в таких девайсах 1 КБ уже роскошь.
Если он брал опенсорсный сетевой стек, то в них всех уже есть пулы пакетов фиксированной длины. Он не должен был вообще притягивать сюда динамическую память. Надо было в первую очередь озаботится глубиной пула.
Потом о какой «предсказуемости важнее гибкости» он может говорить в IoT-девайсе, где в любое мгновение может отвалиться связь? Там нет никакой такой важной предсказуемости.
Первое, что он должен был сделать, - реализовать получение памяти с таймаутом, как в большинстве RTOS сделано. Его датчики могут и подождать, пока память недоступна. А если всё равно недоступна, то выполнять ресет. IoT-девайсы ресет должны воспринимать как штатную операцию. Им всё равно в Deep Standby нужно переходить периодически с возвратом через ресет.
Это ваш опыт, а не мой.
Я имею дело с огромнымы сторонними библиотеками RTOS и middleware.
Их приходится проверять разом и целиком. Свой то код я пишу чисто, там не к чему придраться. Я даже тернарные операторы не применяю, минимум косвенных вызовов.
Минимальное подмножество C. Даже ретаргетинг не делаю, потому что не использую функций C требующих ретаргетинга.
А вот библиотеки править - это тяжелый выбор. Хотите ли вы их потом сами поддерживать после правок?
Так вот теперь с Claude я правлю и кромсаю все что находится в репозитариях.
Никаких проблем из 1000 файлов сделать 100. Но только анализаторы тут уже не при чем.
Дока тоже пишется мгновенно, эту тему можно закрыть.
ctrlX CORE это 64 Bit Quad-Core ARM CPU и 2 Гб RAM
И все ради каких-то 125 мкс
И вы хотите сказать, что будущее вот такое - дорогущие платформы на избыточном софте?
Я же думаю :
Там все это только лишь от того, что код был по любому дороже.
А теперь когда код стал дёшев, они разорятся на таких монстрах.
Ну да, если что не сходится, то надо привлечь магию.
А именно асушника, который способен в doсker запаковать приложение организующее доступ к клемам через K-Line, не выключая runtime и не вынимая ПЛК из рабочей стойки.
Фантастика.
Он там только WEB страничку поменять может и то не факт.
Знаете, CODESYS ведь изначально был сделан под микроконтроллеры с RTOS, а не Линукс. И да, там изначально пользоваетель грузил приложения не пересобирая runtime.
Пересобирать runtime или нет - это очень мелкий ворос.
У меня к примеру сейчас приложение из пары тысяч файлов , они состовляют фреймворк общий для кучи проектов. Я мог бы спокойно его изолировать и сделать из него такой отдельный модуль.
Но мне это не нужно. Зачем мне от себя что-то изолировать?
Я его перекомпилирую каждый день вместе с прикладным кодом.
Благодаря этому он у меня теперь проверен вдоль и поперёк, при любых уровнях оптимизации , при любых раскладах памяти.
А если вы держите runtime как священную корову, к ней не прикасаясь, то сами себя лишаете гибкости.
Кто решил что такой runtime эффективен? Тот кто даже не видел ваши задачи! Нет, runtime можно и должно менять. Теже протоколы, они постоянно меняются. А ведь они в runtime. К кому бежите чтобы там поменять пару команд?
Так что аргумент "зато мы не трогаем runtime" ну совсем не катит.
А некритичным задачам так и вовсе ПЛК не нужен. Он и дорог, и место занимет и потребляет как не в себе.
WEB сервер по HTTPS и всеми поддержками сертификатов у ThreadX не хуже чем в Линуксе.
И еще момент.
В WAGO PFC200 runtime c CODESYS единолично захватывает драйвер шины клемников K-Line. Свое приложение либо должно отключить CODESYS чтобы забрать драйвер и само организовать цикл, либо в runtime химичить мост. И опять ваше утверждение про "зато мы не трогаем runtime" не катит.
Тут еще прикол буквально сейчас я схватил. Claude Fable отказывается работать с исходниками, где просишь сделать защиту доступа к контроллеру.
Т.е. теперь trust zone в Линуксе вне закона для простых смертных. Это еще один повод не лезть в системы с внешними носителями кода.
Просто вы почему-то странно заостряете внимание на "пересобрать, загрузить и заново протестировать".
Как будто в Линуксе не нужно загружать и тестировать. Пересобрать да, если у вас скрипты, то не нужно. Но и реальное время тогда вам не светит.
А если мне не нужно реального времени, то я и планшет могу приспособить под ПЛК и даже терефон. Т.е. это это уже не совсем ПЛК.
Пересборка под RTOS длится секунды.
Не надо думать что подгружаемые исполняемые модули есть только в Линуксе. В ThreadX также есть механизм подгрузки исполняемых модулей. Это не какая-то магия, а довольно примитивный процесс.
И под RTOS можно все подключть позднее. Или хотитет сказать, что изучить сам API Modbus RTU и все опции запуска и их влияние вы под Линуксом быстрее сделаете? Да нет, вы это сделаете это медленнее. Потому что имеете там меньше инструментов отладки реального времени. Потому что вы лишаетесь сквозной отладки.
В жестком реальном времени нужна сквозная отладка от момента вызова файловой операции и до выдачи команды CMD52 на интерфесе SDIO. Иначе месяцами будете ждать ответа вендора и ручками бегать сбрасывать свой контроллер.
В RTOS я могу через трассировку в SWD видеть не то что все вызовы, а все потоки прерываний в реальном времени и не использовтаь при этом никакого инструментального кода.
Про архивы вообще бы не говорил. У вас там такая же SD карта, как и в RTOS. Но ваш драйвер этой карты не вылизан так как они вылизаны под RTOS. Не согласованы каналы DMA, не выставлены приоритеты у этих каналов, не очищено все от избыточности косвенных вызовов и абстракций, не убраны избыточне объекты синхронизации и т.д. и т.п.
SQLite, OPC UA, Modbus-RTU уже давно портированы на RTOS для мелких контроллеров. Им Линукс не нужен от слова совсем.
InfluxDB - требует от 1 Гб RAM-а , это не про Линукс, а про масштаб.
Python и Grafana - в embedded лишние надсройки. ИИ агенты теперь делают графики в каком угодно стиле и формате вообще не привлекая сторонние тулсы на голом css и js
Конверетеры протоколов однозначно на RTOS будут работать быстрее и детерминирование
Подключаться к облакам теперь умеет любой ESP. А Amazon специально для FreeRTOS сделал модуль подключения к AWS. В ThreadX есть спецально под нее модуль подключения к Microsoft Azure IoT. И там есть всё: апгрейд прошивки по воздуху , автоматическое развертывание миллионов дивайсов, телеметрия, управление по MQTT и проч.
Но какие приложения?
Можете назвать что нибудь стоящее, кроме питона , Node-RED, Arduino и прочих интепретаторов-прокладок, необходимость в которых полностью отпадает при наличии агентов прямо пишущих на C.
С вашим понятием "открытости" и Windows можно назвать полностью открытой операционкой.
Потом интересно какой минимальный период цикла поддерживает ваше решение на Линуксе?
На обычном микроконтроллере 240 МГц нормально держать жесткий цикл в 100 и меньше мкс.
Да уж и времена когда для подключения к AWS по MQTT, OPC UA или WEB сервер нужен был Линукс тоже прошли.
Сейчас это достаточно легко делается на обычной легковесной RTOS типа ThreadX
или FreeRTOS.
Современные агенты за пару дней перенесут все нужные стеки на RTOS включая навороченные GUI и базы данных.
Кстати, ПЛК типа WAGO PFC200 не делают на одном процессорном чипе.
Вот у меня такой один убитый лежит :
Тут как минимум два SoC и две разные операционки. И по ходу есть место еще для одного SoC
Убить такие контроллеры достаточно легко. Программа выполняется из DDRAM, грузится из NAND. Куча мест где что-то может пойти не так.
Но они никогда не станут открытыми, потому что в них всегда есть какой нибудь кастомный чип на шине. Их межмодульная шина - самый большой секрет. Проблема еще в том что программу хранимую вне SoC гораздо труднее защитить. А в Европе, к примеру, вступает в силу Cyber Resilience Act. И с ним сделать защиту Линукса ох как нелегко. Придется возится с Trusted Firmware-A или с OP-TEE. А иначе не дадут разрешение на использование нигде.
А с обычным микроконтроллером прожег фьюзы и все! Дело сделано.
Поэтому на мой взгляд надежней ПЛК будет на SoC с интегрированной Flash и RAM с Error-Correcting Code.
Таких сейчас достаточно много дешевых: RP2354 , ESP32-P4 , RA8P1 , STM32N657 ...
Вот за ними-то и вижу перспективы. И дёшево, и надёжно.
А смысл?
Индивидуальный Allan-анализ каждого MEMS врядли существенно повысит точность INS.
Только время будет зря потеряно на тюнинг алгоритмов. Температура и время свое отыграют.
С другой стороны в даташитах и так написаны предельные шумы и девиации.