Как ни странно, но именно для подъемников и простейших лифтов Arduino вполне годится. Там как раз времени на реакцию есть с запасом. Реакция самая примитивная - включить/выключить. А безопасность в лифтах заключается лишь в том чтобы остановиться при любой проблеме и стоять. Умрете ли вы там от голода ожидая техников или получите инфаркт пока откроются двери в наставлении по безопасности не прописано. Поэтому безопасность там делается элементарно на обходе последовательной цепью всех концевиков и заходом на контакторы расцепления питания тормозов и мотора. Все! И Arduino никакого отношения к этому не имеет. Максимум лампочку может зажечь красную.
Да не для чего он не хорош кроме самых примитивных функций. Включить-выключить что-то по времени и вывести в порт - все! Ну может быть еще измерить и только после этого включить-выключить. Достаточно посмотреть на API Arduino Какие принтеры? Какие умные дома? Там в помине нет таких функций. Там даже крутить BLDC моторчик нет функций. Уже не говорю про чтобы крутить по траектории. Другое дело что это API Arduino может лежать поверх mbed А вот там уже все серьезней. Но зачем нужен API Arduino если освоен mbed понять трудно.
С другой стороны SDK под IDE Arduino с базовым Arduino API теперь Claude Sonnet или Opus может слепить за день для любой платы. Но опять вопрос. Если есть Claude Sonnet, то зачем ограничивать себя Arduino API? Сам можеш разработать себе API по вкусу.
По данным официального сайта Arduino, с момента запуска платформы было продано более 50 миллионов плат и клонов. А сообщество насчитывает десятки миллионов активных пользователей по всему миру.
Что-то очень мало. Микроконтроллеров делают разных по 35 миллиардов в год. Я бы задумался об обратном как раз. Почему Arduino занимает так мало места в embedded. Почему так и не вышла за рамки DIY. Почему такая слабая инфраструктура отладки. Почему embedded до сих пор такая сложная область разработки. А видел любителей аrduino, которые при огромном желании так и не поднялись до разработки промышленных решений. А не являетя ли Arduino ловушкой? Обещанием быстрого успеха. Как курсы по IT. Они же эти обещания так легко продаются. А потом фрустрация и выгорание.
Думаю это потому что во взрослом embedded уже никто не заинтересован, чтобы у вас быстро включалась лампочка и закрутился моторчик. Чем больше потратите сил на освоение, тем больше заработают на вас. И в консолидации технологий ни у кого нет интереса. Может ИИ порвет эту порочную схему.
вообще дремучая древность, разработанная в середине 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.
Как ни странно, но именно для подъемников и простейших лифтов Arduino вполне годится.
Там как раз времени на реакцию есть с запасом. Реакция самая примитивная - включить/выключить.
А безопасность в лифтах заключается лишь в том чтобы остановиться при любой проблеме и стоять. Умрете ли вы там от голода ожидая техников или получите инфаркт пока откроются двери в наставлении по безопасности не прописано. Поэтому безопасность там делается элементарно на обходе последовательной цепью всех концевиков и заходом на контакторы расцепления питания тормозов и мотора. Все! И Arduino никакого отношения к этому не имеет. Максимум лампочку может зажечь красную.
Да не для чего он не хорош кроме самых примитивных функций.
Включить-выключить что-то по времени и вывести в порт - все!
Ну может быть еще измерить и только после этого включить-выключить.
Достаточно посмотреть на API Arduino
Какие принтеры? Какие умные дома?
Там в помине нет таких функций. Там даже крутить BLDC моторчик нет функций. Уже не говорю про чтобы крутить по траектории.
Другое дело что это API Arduino может лежать поверх mbed
А вот там уже все серьезней.
Но зачем нужен API Arduino если освоен mbed понять трудно.
С другой стороны SDK под IDE Arduino с базовым Arduino API теперь Claude Sonnet или Opus может слепить за день для любой платы.
Но опять вопрос. Если есть Claude Sonnet, то зачем ограничивать себя Arduino API?
Сам можеш разработать себе API по вкусу.
Что-то очень мало.
Микроконтроллеров делают разных по 35 миллиардов в год.
Я бы задумался об обратном как раз. Почему Arduino занимает так мало места в embedded.
Почему так и не вышла за рамки DIY. Почему такая слабая инфраструктура отладки.
Почему embedded до сих пор такая сложная область разработки.
А видел любителей аrduino, которые при огромном желании так и не поднялись до разработки промышленных решений.
А не являетя ли Arduino ловушкой? Обещанием быстрого успеха. Как курсы по IT. Они же эти обещания так легко продаются. А потом фрустрация и выгорание.
Думаю это потому что во взрослом embedded уже никто не заинтересован, чтобы у вас быстро включалась лампочка и закрутился моторчик. Чем больше потратите сил на освоение, тем больше заработают на вас. И в консолидации технологий ни у кого нет интереса.
Может ИИ порвет эту порочную схему.
Ок, в АЦП для частотников вы не сильны.
Но вот там в статье на рисунке
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.