вообще дремучая древность, разработанная в середине 90-х Эт же можно было бы немного так подразобраться в технологиях, а не тупо копипастить из призентаций?
Единственный намек на реальную схемотехнику в cтатье - это отсылка к AMC1306x Но AMC1306x является delta-sigma модулятором. Он не пригоден для взятия моментальных отсчетов. У него даже нет входа синхронизации. Т.е. для всех тех супер пупер плат что там на картинках в начале он не годится.
А так статья ради статьи, никаких практических знаний не несет. Не понятно до каких мощностей преобразования энергии расплескалась фантазия автора. Первая диаграмма как-будто о мегаватных преобразователях. А потом библиотеки перечисляет для DIY-ских проектов. Какая-то несогласованность изложения.
Не в тему , но просто сегодня свалилась еще одна радость от PC-шных программистов. Портировал драйвер Wi-Fi модуля , который пришел из PC-шного линукса. Так там просто в наглую использовали malloc по любому поводу. Куча копирований пакетов между задачами, а как апофеоз - рекурсия в парсинге пакетов , причем куски пакетов на каждом заходе рекурсии выделялитсь в стеке.
Нет , программирование микроконтроллеров не стало легче никак. Он стало труднее, потому что задачи для микроконтроллеров стали труднее и хотят от них больше.
Мануал что ли открываем? Или что открываем? Или панель в отладчике с месивом непонятных битов? Я говорю от прерываниях в проекте, происходящих сейчас и кажду микросекунду. А есть микрокнтроллеры где нет жесткой привязки векторов к периферии в NVIC. Там и мануал не поможет.
Про callback я не понял как вы умудляетесь обойтись дефолтными и разрулить все в RTOS. У вас их пару штук всего ? Как вы передаете ивенты в задачи?
Как минимум, коллбеки сами обрабатывают флаги большинства периферии (за исключением коллбеков ошибок, там да, надо ручками почитать стейты и обработать их).
Callback сами ничего не обрабатывают. Это забота программиста их реализовать. Просто эти реализации должны находиться внутри спец функций объявленных, но не реализованных в API. Пишу так подробно для PC программистов, которые и не подозревают о таких артефактах, приносящих дополнительные страдания. Самый треш в том, что для этих сallback никогда нет четкой спецификации - из каких именно мест они вызываются, из ISR или из обычного потока. И сколько там в нашем распоряжении будет стека и т.п. Хорошо если HAL открыт в исходниках, хотя там встретит стена из макросов и косвенных вызовов. А если это закрытая либа какого-нибудь управления моторами от ST? И при этом она должна работать в жестком риалтайме. Это что? Это боль!
Как смотреть тайминги ISR и их последоавательности, проблем нет. Для этого в C-Spy есть Timeline, где все они видны с точностью до долей микросекунд. Ничего дополнительно в код вставлять не надо. Если надо еще точнее, то есть трасировка в Ozone. Проблема в огромном количестве номенклатуры прерываний. Эт все равно что PC-шника заставить помнить все прерывания на PCI шине или хотя бы думать о них или хотя бы знать о такой шине.
Но конечно, есть embedded-ы, которые ни с чем в своей жизни кроме UART, I2C и SPI не работали. У них может быть свое представление о реальности. Тут не поспоришь. Вселенных есть много.
API то оно предлагает, только реализацию не предлагает. И не может предложить, поскольку это глубоко железо-зависимая вещь. Даже когда у STM32 есть CubeMX и в нем пожно включить RTOS, то все равно HAL не будет использовать сервисы RTOS. И в ISR не будут использоваться семафоры или флаги, а будет туча callback, реализовать которые надо самому программисту. Разве это не слёзы ?!
А ведь могли бы за столько лет уже сделать HAL связанный с RTOS. Этакий фреймворк. Что то похожее лепит Arduino. Но сразу теряет свою аудиторию из-за сложности концепции многозадачности. О синхронизации и тактах то все равно юзеру надо думать. О тактах в embedded не думают только от того что это реально трудно и действуют на авось. Во многих случаях прокатывает. Но в нормальной системе разработчик наизусть должен знать сколько времени у него обрабатываются прерывания от каждой периферии и сколько у него мертвого времени, когда прерывания запрещены и какой джитер прерываний он может получить.
Про MPU тоже я еще не упоминал. А говорил о Trust Zone. А MPU не может дать существенного удобства поскольку ограничено количеством зон. это еще один головняк, и потеря ресурсов на переключение.
Ну да, у меня на столе многоядерный микроконтроллер с тактовой частотой 1 ГГц и отдельным AI-ядром. А я всё равно начинаю писать прикладной софт с конфигурирования таблицы векторов прерываний. Потом перехожу к драйверам, тщательно расписываю приоритеты этих прерываний и оптимизирую обработчики по тактам.
Конфигураторы по-прежнему остаются рекламной заманухой. Да, они сделают стартовую рабочую конфигурацию. Но как только дело доходит до использования всех возможностей периферии — таймерных модулей, цепочечных пересылок по DMA от одной периферии к другой по триггерам от третьих, — весь код конфигураторов летит в топку. ОСРВ тоже, по сути, голые. HAL от производителей никак не коррелирует с ОСРВ, тупо работает на программных задержках и требует тотальной переделки.
Да, у них теперь есть разделение памяти на защищённую и пользовательскую. Мне от этого ни холодно ни жарко — ещё один повод где-то накосячить. Ни одна доступная RTOS эту фичу толком не использует. Да, у них теперь хороший отладочный движок с трассировкой. Но это не отменяет проход по шагам и скрупулёзный подсчёт тактов. Программа сама себя не оптимизирует.
Странно, но мы в реле видим главную опасность не в дребезге (он длится микросекунды) а в залипании. А тут еще конденсатор предлагают. Тогда залипание 100% получится. Кстати сам дребезг значительно короче отрезка времени, когда переключающий контакт находится в воздухе и не пойми что творится. И что-то я не понял причем там Шенон и Буль к реле в промышленности. Шенон взял от Буля формализацию и делал статические схемы коммутации пригодные для телефонных станций. Промышленность там и рядом не лежала. Потому что для конвейера нужна динамика, куча реле времени, и учет гонок. Эт гораздо сложнее булевой алгебры.
От них скрыта большая часть айсберга, а они думают, что стоят на вершине горы.
Эмбеддеры изо дня в день, сколько себя помнят, продолжают заниматься этим хардкором — и конца этому не видно.
Великий раскол случился, когда в процессорах придумали MMU.
Программисты на PC получили возможность писать глючные программы, которые уже не вешают всю систему, — и у них дела пошли в гору.
А эмбеддеры остались на голом железе с общей памятью, где каждое неосторожное движение ведёт к полному краху. Приходится биться за каждый килобайт памяти и каждый процент времени CPU.
И сказано было: «сойдем же и смешаем там язык их, так чтобы один не понимал речи другого» (Книга Бытия, 11:7) — и PC-программисты с эмбеддерами перестали понимать друг друга
ESP32 хорош подменой MAC. Европейские теперь MAC не очень то дадут менять, плюс у ESP32 попроще с региональными ограничениями на полосы и мощности. Ну и скрость по SDIO у них достойная. Еще тестирую.
Тут опять не могу согласиться. К примеру, вы в курсе что у такого всеми любимого ESP32 нет нормальной хостовой библиотеки, чтобы сторонний микроконтроллер мог использовать ESP32 просто как WiFi модуль. То что есть портировано на ESP32-P4 и это монстр из 1300 фалов! Требующий немеренно динамической памяти, создающий 6 задач и кучу очередей, испещренный логами и многоэтажными макросами.
Так вот Cloude не за час, но за пару дней урезал этот кошмар до 20 файлов! И в навесок модуль апгрейда софта написал через UART этого ESP.
Т.е. разработчики могут валить теперь в туман оптом, никто не заметит потери бригады бойцов.
Я понимаю, откуда ноги растут. Ещё совсем недавно HTML-страницу со скриптами сделать обычному эмбеддеру было очень трудно. А тут ещё обмен по JSON и серверная часть. А серверная часть завязана на особенностях встраиваемых ограниченных стеков типа lwIP, NetX Duo или чего-то такого.
Но фишка в том, что сейчас идёт революция. Столпы рушатся.
Сегодня я за час перенёс веб-сайт с CMS Joomla и дорогого хостера на бесплатный облачный сервис со статическими страницами и функциями. Всё прошло идеально: полное сохранение содержимого и форматирования, очистка от всех артефактов Joomla и рекламных ссылок.
Ну а Joomla, думаю, конец — как пришёл конец Stack Overflow. И ещё придёт конец всем сайтостроителям и всей индустрии плагинов под них.
Да что там говорить. Мне Cloude Sonnet легко переделывает приложение с Delphi на новейшие технологии WinUI и XAML. Это конец большинству IDE и индустрии компонентов под них.
Нативы тоже шатаются.
Никто, конечно, JTAG/SWD-адаптеры пока не отменил, хотя RA8 сейчас грузится через USB свободно.
Но легаси точно уже не нужен. Как-то внезапно я заменил свои легаси-утилиты на питоновские скрипты, потому что Cloude идеально пишет и отлаживает код на питоне. Сам я в питоне ничего не понимаю.
И Web-интерфейсом я некоторое время назад заменил терминалы в своих устройствах.
Все Web-страницы мне пишет Cloude (ну иногда Codex, но он жутко медленный).
Первым делом на голые девайсы сразу портирую TCP-стек с Web-сервером. Если нет Ethernet или Wi-Fi, то запускаю через USB.
По сравнению с терминалами это земля и небо по удобству.
У esp32 мало пинов, мало современных интерфейсов, мало памяти и неудобная медленная отладка. На RA8 можно делать полноценные анализаторы протоколов и перехватчики. Сегодня мне GPT-5.1-Codex написал полноценное WEB приложение для перепрограммированися системы из десятков CAN узлов. За один день! сложнейшее приложение с сканированием сети, получением метаинформации, индикацией прогресса, разруливание конфликтов и т,д,
Немного конечно неадекватоно, когда однин из главных плюсов инструмента - его дешивизна. Все равно что выбирать самый дешевый молоток для забивания гвоздей, а лучше вообще первым попавшимся булыжником забивать. Либо наоборот, давайте микроскопом забивать, т.е. приплетать сюда ПЛИС-ы
Да возьмите любую отладочную плату на микроконтроллере. Например такую - https://www.renesas.com/en/design-resources/boards-kits/ek-ra8p1 Сконфигурируйте на ней WEB сервер. И получите тысячи применений вместо четырех. GPT-5.1-Codex влет напишет нужные крависые WEB , протокол обмена по JSON с платой, а на плате напишет обмен по всем современным интерфейсам: I2C, I3C, SPI, OSPI, QSPI, SDIO, UART, USART, 1WIRE, LIN, CAN, MODBUS, CANFD, USB, SSI, PDM, MMC, MIPI ... И не нужно никах левых драйверов под Windows. Можно хоть с телефона рулить.
Момент то тут при чем? Речь идет о мощности! И об активном токе! Не токе через пустую медь. На коробке что, момент написан? Да и момента на насыщеном железе уже не будет никакого. Не забываем, что речь идет о самом дешевом моторе с самым дешевым железом. А разговор идет о первых миллисекундах пуска. А когда мотор зажимают типа руками там уже термистор давно сработал. Некоторым, я вижу, до ответов ChatGPT еще надо поднакопить знаний.
5000 Вт - это похоже на пусковую или мощность при стопорении. Чем дешевле мотор тем она больше в заданых габаритах. А хозяин соотвественно должен подумать о том выдержат ли вводные автоматы. Поэтому эта цифра полезная и очень нужная. А чтобы узнать номинальную надо просто делить на 10.
Поскольку вы связанно не может ответить на вопросы безопасности, то я пытаюсь понять сценарии как мог думать ваш программист, когда делал такие дыры в защите. И вижу ответ в том что он Ethernet кабелем думал подключиться к локальному WiFi VPN роутеру под физической защитой в ящике и далее полагаться на защиту от провайдера. Но это дорого и хлопотно.
Начнем с того что ваш контроллер к облакам и IoT не имеет никакого отношения. Ни одни облака не позволят подключиться к себе без TLS 2.0 минимума. Что вам мешало реализовать TLS? Не разобрались в API ESPэшек? Или тот же интерпретатор LUA или Python что мешало интергрировать? Помяти не хватило? Выбрали самый дешевый микроконтроллер в семействе?
Хотя конечно есть WiFi роутеры с VPN туннелем, и можно утверждать, что трафик защищен если он идет от дивайса чисто по WiFi с WPA3 Но тогда надо предупреждать пользователей, что за дешевым контроллером, должен еще стоять дорогущий специализированный роутер.
А мне нравятся статьи от DeepSeek. Кратко и по делу. Без этой графоманской воды.
Спасибо автору за ссылку на IOT2050. Довольно необычный дивайс для Сименса. Это не ПЛК с входами-выходами. Это шлюз для ардуинщиков!
На этом дивайсе реально стоят ряды пинов для подключения ардуинских шилдов. Т.е. программа сама пишется в ардуине, а этот шлюз вытягивает из ардуин данные и уже их обрабатывает, сохраняет, агрегирует, защищает и пересылает. Т.е. делает то, что ардуинщики не умеют, но очень хотят делать.
Кстати, в этот шлюз можно вставить самые навороченные и при этом дешевые 5G модемы с алика, в нем есть слот для SIM карты. В этот же шлюз можно втавить терабайтные карты памяти и накапливать данные за всю жизнь работы всей системы.
Ну и самое главное, этот шлюз содержит корневые сертификаты. Этот шлюз нельзя подделать, нельзя перехватить его трафик, нельзя перехватить управление им, к шлюзу не могут подключиться всякие левые неавторизированные облака. Этот шлюз уже обеспечен облаками сименса с налаженным конвейером обновления сертификатов. Как известно, сертификаты в IoT не выдают дольше чем на год. И автоматическое обновление сертификатов для тысяч дивайсов - важнейшая функция облаков.
А у автора получился недоделанный ПЛК. Шлюзом он не может быть по определению. В условиях мировой кибервойны это будет просто первой целью для атаки и мамкиных хакеров. Тут даже HTTP не защищен. Где-нить в европах за продажу такого дивайса фирму бы прикрыли. А ведь могли бы сделать нормально. Случись теперь что с этими насосами будут явные признаки саботажа.
Ок, в АЦП для частотников вы не сильны.
Но вот там в статье на рисунке
https://habrastorage.org/r/w1560/getpro/habr/upload_files/a4a/adc/f87/a4aadcf878710d15e871788081ae84a5.png
вообще дремучая древность, разработанная в середине 90-х
Эт же можно было бы немного так подразобраться в технологиях, а не тупо копипастить из призентаций?
Единственный намек на реальную схемотехнику в cтатье - это отсылка к AMC1306x
Но AMC1306x является delta-sigma модулятором. Он не пригоден для взятия моментальных отсчетов. У него даже нет входа синхронизации.
Т.е. для всех тех супер пупер плат что там на картинках в начале он не годится.
А так статья ради статьи, никаких практических знаний не несет.
Не понятно до каких мощностей преобразования энергии расплескалась фантазия автора. Первая диаграмма как-будто о мегаватных преобразователях. А потом библиотеки перечисляет для DIY-ских проектов. Какая-то несогласованность изложения.
GPT не в настроении что ли писал?
Не в тему , но просто сегодня свалилась еще одна радость от PC-шных программистов.
Портировал драйвер Wi-Fi модуля , который пришел из PC-шного линукса.
Так там просто в наглую использовали malloc по любому поводу.
Куча копирований пакетов между задачами, а как апофеоз - рекурсия в парсинге пакетов , причем куски пакетов на каждом заходе рекурсии выделялитсь в стеке.
Нет , программирование микроконтроллеров не стало легче никак.
Он стало труднее, потому что задачи для микроконтроллеров стали труднее и хотят от них больше.
Что значит
Мануал что ли открываем? Или что открываем? Или панель в отладчике с месивом непонятных битов?
Я говорю от прерываниях в проекте, происходящих сейчас и кажду микросекунду.
А есть микрокнтроллеры где нет жесткой привязки векторов к периферии в NVIC. Там и мануал не поможет.
Про callback я не понял как вы умудляетесь обойтись дефолтными и разрулить все в RTOS. У вас их пару штук всего ? Как вы передаете ивенты в задачи?
Callback сами ничего не обрабатывают.
Это забота программиста их реализовать.
Просто эти реализации должны находиться внутри спец функций объявленных, но не реализованных в API.
Пишу так подробно для PC программистов, которые и не подозревают о таких артефактах, приносящих дополнительные страдания.
Самый треш в том, что для этих сallback никогда нет четкой спецификации - из каких именно мест они вызываются, из ISR или из обычного потока. И сколько там в нашем распоряжении будет стека и т.п.
Хорошо если HAL открыт в исходниках, хотя там встретит стена из макросов и косвенных вызовов. А если это закрытая либа какого-нибудь управления моторами от ST? И при этом она должна работать в жестком риалтайме.
Это что? Это боль!
Как смотреть тайминги ISR и их последоавательности, проблем нет. Для этого в C-Spy есть Timeline, где все они видны с точностью до долей микросекунд. Ничего дополнительно в код вставлять не надо. Если надо еще точнее, то есть трасировка в Ozone.
Проблема в огромном количестве номенклатуры прерываний.
Эт все равно что PC-шника заставить помнить все прерывания на PCI шине или хотя бы думать о них или хотя бы знать о такой шине.
Но конечно, есть embedded-ы, которые ни с чем в своей жизни кроме UART, I2C и SPI не работали. У них может быть свое представление о реальности. Тут не поспоришь. Вселенных есть много.
API то оно предлагает, только реализацию не предлагает. И не может предложить, поскольку это глубоко железо-зависимая вещь.
Даже когда у STM32 есть CubeMX и в нем пожно включить RTOS, то все равно HAL не будет использовать сервисы RTOS. И в ISR не будут использоваться семафоры или флаги, а будет туча callback, реализовать которые надо самому программисту.
Разве это не слёзы ?!
А ведь могли бы за столько лет уже сделать HAL связанный с RTOS. Этакий фреймворк.
Что то похожее лепит Arduino. Но сразу теряет свою аудиторию из-за сложности концепции многозадачности. О синхронизации и тактах то все равно юзеру надо думать.
О тактах в embedded не думают только от того что это реально трудно и действуют на авось. Во многих случаях прокатывает. Но в нормальной системе разработчик наизусть должен знать сколько времени у него обрабатываются прерывания от каждой периферии и сколько у него мертвого времени, когда прерывания запрещены и какой джитер прерываний он может получить.
Про MPU тоже я еще не упоминал. А говорил о Trust Zone. А MPU не может дать существенного удобства поскольку ограничено количеством зон. это еще один головняк, и потеря ресурсов на переключение.
Ну да, у меня на столе многоядерный микроконтроллер с тактовой частотой 1 ГГц и отдельным AI-ядром.
А я всё равно начинаю писать прикладной софт с конфигурирования таблицы векторов прерываний. Потом перехожу к драйверам, тщательно расписываю приоритеты этих прерываний и оптимизирую обработчики по тактам.
Конфигураторы по-прежнему остаются рекламной заманухой. Да, они сделают стартовую рабочую конфигурацию. Но как только дело доходит до использования всех возможностей периферии — таймерных модулей, цепочечных пересылок по DMA от одной периферии к другой по триггерам от третьих, — весь код конфигураторов летит в топку. ОСРВ тоже, по сути, голые. HAL от производителей никак не коррелирует с ОСРВ, тупо работает на программных задержках и требует тотальной переделки.
Да, у них теперь есть разделение памяти на защищённую и пользовательскую. Мне от этого ни холодно ни жарко — ещё один повод где-то накосячить. Ни одна доступная RTOS эту фичу толком не использует.
Да, у них теперь хороший отладочный движок с трассировкой. Но это не отменяет проход по шагам и скрупулёзный подсчёт тактов. Программа сама себя не оптимизирует.
Словом, кругом пот и нервы.
Странно, но мы в реле видим главную опасность не в дребезге (он длится микросекунды) а в залипании.
А тут еще конденсатор предлагают. Тогда залипание 100% получится.
Кстати сам дребезг значительно короче отрезка времени, когда переключающий контакт находится в воздухе и не пойми что творится.
И что-то я не понял причем там Шенон и Буль к реле в промышленности.
Шенон взял от Буля формализацию и делал статические схемы коммутации пригодные для телефонных станций. Промышленность там и рядом не лежала. Потому что для конвейера нужна динамика, куча реле времени, и учет гонок. Эт гораздо сложнее булевой алгебры.
Чистые программисты на PC — забавные ребята.
От них скрыта большая часть айсберга, а они думают, что стоят на вершине горы.
Эмбеддеры изо дня в день, сколько себя помнят, продолжают заниматься этим хардкором — и конца этому не видно.
Великий раскол случился, когда в процессорах придумали MMU.
Программисты на PC получили возможность писать глючные программы, которые уже не вешают всю систему, — и у них дела пошли в гору.
А эмбеддеры остались на голом железе с общей памятью, где каждое неосторожное движение ведёт к полному краху. Приходится биться за каждый килобайт памяти и каждый процент времени CPU.
И сказано было: «сойдем же и смешаем там язык их, так чтобы один не понимал речи другого» (Книга Бытия, 11:7) — и PC-программисты с эмбеддерами перестали понимать друг друга
ESP32 хорош подменой MAC.
Европейские теперь MAC не очень то дадут менять, плюс у ESP32 попроще с региональными ограничениями на полосы и мощности.
Ну и скрость по SDIO у них достойная. Еще тестирую.
Тут опять не могу согласиться.
К примеру, вы в курсе что у такого всеми любимого ESP32 нет нормальной хостовой библиотеки, чтобы сторонний микроконтроллер мог использовать ESP32 просто как WiFi модуль.
То что есть портировано на ESP32-P4 и это монстр из 1300 фалов!
Требующий немеренно динамической памяти, создающий 6 задач и кучу очередей, испещренный логами и многоэтажными макросами.
Так вот Cloude не за час, но за пару дней урезал этот кошмар до 20 файлов!
И в навесок модуль апгрейда софта написал через UART этого ESP.
Т.е. разработчики могут валить теперь в туман оптом, никто не заметит потери бригады бойцов.
Я понимаю, откуда ноги растут. Ещё совсем недавно HTML-страницу со скриптами сделать обычному эмбеддеру было очень трудно. А тут ещё обмен по JSON и серверная часть. А серверная часть завязана на особенностях встраиваемых ограниченных стеков типа lwIP, NetX Duo или чего-то такого.
Но фишка в том, что сейчас идёт революция. Столпы рушатся.
Сегодня я за час перенёс веб-сайт с CMS Joomla и дорогого хостера на бесплатный облачный сервис со статическими страницами и функциями. Всё прошло идеально: полное сохранение содержимого и форматирования, очистка от всех артефактов Joomla и рекламных ссылок.
Ну а Joomla, думаю, конец — как пришёл конец Stack Overflow. И ещё придёт конец всем сайтостроителям и всей индустрии плагинов под них.
Да что там говорить. Мне Cloude Sonnet легко переделывает приложение с Delphi на новейшие технологии WinUI и XAML. Это конец большинству IDE и индустрии компонентов под них.
Нативы тоже шатаются.
Никто, конечно, JTAG/SWD-адаптеры пока не отменил, хотя RA8 сейчас грузится через USB свободно.
Но легаси точно уже не нужен. Как-то внезапно я заменил свои легаси-утилиты на питоновские скрипты, потому что Cloude идеально пишет и отлаживает код на питоне. Сам я в питоне ничего не понимаю.
И Web-интерфейсом я некоторое время назад заменил терминалы в своих устройствах.
Все Web-страницы мне пишет Cloude (ну иногда Codex, но он жутко медленный).
Первым делом на голые девайсы сразу портирую TCP-стек с Web-сервером. Если нет Ethernet или Wi-Fi, то запускаю через USB.
По сравнению с терминалами это земля и небо по удобству.
У esp32 мало пинов, мало современных интерфейсов, мало памяти и неудобная медленная отладка.
На RA8 можно делать полноценные анализаторы протоколов и перехватчики.
Сегодня мне GPT-5.1-Codex написал полноценное WEB приложение для перепрограммированися системы из десятков CAN узлов. За один день! сложнейшее приложение с сканированием сети, получением метаинформации, индикацией прогресса, разруливание конфликтов и т,д,
Немного конечно неадекватоно, когда однин из главных плюсов инструмента - его дешивизна.
Все равно что выбирать самый дешевый молоток для забивания гвоздей, а лучше вообще первым попавшимся булыжником забивать.
Либо наоборот, давайте микроскопом забивать, т.е. приплетать сюда ПЛИС-ы
Да возьмите любую отладочную плату на микроконтроллере.
Например такую - https://www.renesas.com/en/design-resources/boards-kits/ek-ra8p1
Сконфигурируйте на ней WEB сервер.
И получите тысячи применений вместо четырех.
GPT-5.1-Codex влет напишет нужные крависые WEB , протокол обмена по JSON с платой, а на плате напишет обмен по всем современным интерфейсам: I2C, I3C, SPI, OSPI, QSPI, SDIO, UART, USART, 1WIRE, LIN, CAN, MODBUS, CANFD, USB, SSI, PDM, MMC, MIPI ...
И не нужно никах левых драйверов под Windows. Можно хоть с телефона рулить.
Момент то тут при чем?
Речь идет о мощности! И об активном токе! Не токе через пустую медь.
На коробке что, момент написан?
Да и момента на насыщеном железе уже не будет никакого.
Не забываем, что речь идет о самом дешевом моторе с самым дешевым железом.
А разговор идет о первых миллисекундах пуска. А когда мотор зажимают типа руками там уже термистор давно сработал.
Некоторым, я вижу, до ответов ChatGPT еще надо поднакопить знаний.
Такие вещи лучше сарашивать у ChatGPT
И как видно, если стопорить двигатель до очень низкой скорости, то увидеть можно только 20...10 его номинальной мощности.
5000 Вт - это похоже на пусковую или мощность при стопорении.
Чем дешевле мотор тем она больше в заданых габаритах.
А хозяин соотвественно должен подумать о том выдержат ли вводные автоматы.
Поэтому эта цифра полезная и очень нужная.
А чтобы узнать номинальную надо просто делить на 10.
Поскольку вы связанно не может ответить на вопросы безопасности, то я пытаюсь понять сценарии как мог думать ваш программист, когда делал такие дыры в защите.
И вижу ответ в том что он Ethernet кабелем думал подключиться к локальному WiFi VPN роутеру под физической защитой в ящике и далее полагаться на защиту от провайдера.
Но это дорого и хлопотно.
Начнем с того что ваш контроллер к облакам и IoT не имеет никакого отношения.
Ни одни облака не позволят подключиться к себе без TLS 2.0 минимума.
Что вам мешало реализовать TLS?
Не разобрались в API ESPэшек?
Или тот же интерпретатор LUA или Python что мешало интергрировать?
Помяти не хватило? Выбрали самый дешевый микроконтроллер в семействе?
Хотя конечно есть WiFi роутеры с VPN туннелем, и можно утверждать, что трафик защищен если он идет от дивайса чисто по WiFi с WPA3
Но тогда надо предупреждать пользователей, что за дешевым контроллером, должен еще стоять дорогущий специализированный роутер.
А мне нравятся статьи от DeepSeek. Кратко и по делу. Без этой графоманской воды.
Спасибо автору за ссылку на IOT2050.
Довольно необычный дивайс для Сименса.
Это не ПЛК с входами-выходами. Это шлюз для ардуинщиков!
На этом дивайсе реально стоят ряды пинов для подключения ардуинских шилдов.
Т.е. программа сама пишется в ардуине, а этот шлюз вытягивает из ардуин данные и уже их обрабатывает, сохраняет, агрегирует, защищает и пересылает. Т.е. делает то, что ардуинщики не умеют, но очень хотят делать.
Кстати, в этот шлюз можно вставить самые навороченные и при этом дешевые 5G модемы с алика, в нем есть слот для SIM карты.
В этот же шлюз можно втавить терабайтные карты памяти и накапливать данные за всю жизнь работы всей системы.
Ну и самое главное, этот шлюз содержит корневые сертификаты. Этот шлюз нельзя подделать, нельзя перехватить его трафик, нельзя перехватить управление им, к шлюзу не могут подключиться всякие левые неавторизированные облака. Этот шлюз уже обеспечен облаками сименса с налаженным конвейером обновления сертификатов. Как известно, сертификаты в IoT не выдают дольше чем на год. И автоматическое обновление сертификатов для тысяч дивайсов - важнейшая функция облаков.
А у автора получился недоделанный ПЛК. Шлюзом он не может быть по определению. В условиях мировой кибервойны это будет просто первой целью для атаки и мамкиных хакеров. Тут даже HTTP не защищен. Где-нить в европах за продажу такого дивайса фирму бы прикрыли.
А ведь могли бы сделать нормально. Случись теперь что с этими насосами будут явные признаки саботажа.