AI Bench Automation

О том, как локальный агент на Windows перестаёт быть просто умным собеседником и становится участником реальной работы с железом

Обычно, когда говорят про AI в инженерии, имеют в виду довольно скромный набор вещей: помочь с кодом, объяснить документацию, подсказать гипотезу, накидать архитектуру. Всё это полезно, но всё ещё остаётся по одну сторону экрана. Настоящий перелом начинается в тот момент, когда агент получает доступ не только к тексту проекта, но и к самой лабораторной среде: к прошивке, к программатору, к helper-плате, к логическому анализатору и к живому устройству на столе.

Вот тогда разговор заканчивается, и начинается работа.

В чём здесь главный смысл

Ценность такого стенда не в том, что AI один раз может:

• собрать проект;
• прошить микроконтроллер;
• нажать условную кнопку;
• снять лог по UART или SPI.

Это уже само по себе удобно, но по-настоящему интересно другое: агент получает возможность работать циклически. Не как “советчик на один запуск”, а как инженер, который может много раз подряд повторять один и тот же лабораторный цикл, наблюдать результат и шаг за шагом дожимать систему.

Именно это превращает AI из инструмента для текста в инструмент для доводки реального железа.

Что такое “циклическая работа” в реальности

Если говорить простыми словами, то речь идёт о таком режиме:

1. агент читает контекст проекта и текущую логику прошивки;
2. вносит изменение в код;
3. собирает и шьёт устройство;
4. переводит устройство в нужный режим через helper-плату;
5. запускает захват на логическом анализаторе;
6. получает реальный обмен по UART, SPI и GPIO;
7. сравнивает текущее поведение с прошлым прогоном;
8. корректирует параметры;
9. повторяет цикл снова.

Не один раз. Столько, сколько нужно.

И вот в этот момент появляется новая возможность: не просто “что-то проверить”, а методично улучшать качество работы устройства, пока результат не выйдет на нужный уровень.

Почему это особенно сильно для embedded и радиосистем

В обычной программной разработке многие вещи можно проверить тестами или симуляцией. В embedded, особенно если речь идёт о сигналах, радиотракте, адаптивных алгоритмах, нестабильных внешних условиях или чувствительности приёма, всё становится гораздо жёстче.

Там мало написать красивую логику. Нужно увидеть:

• как реально меняются тайминги;
• как реагируют GPIO-линии;
• что на самом деле идёт по UART или SPI;
• как система держится на слабом сигнале;
• как быстро она адаптируется;
• где начинаются ложные срабатывания;
• где поведение уже хорошее, а где ещё сырой компромисс.

В таких задачах главный ресурс — это не просто “умение программировать”, а способность много раз прогонять один и тот же физический эксперимент, каждый раз с немного лучшей гипотезой.

И вот именно этот кусок работы обычно очень дорогой по времени.

Что именно стало возможным

В этой конфигурации локальный агент в Codex app на Windows умеет не только писать код, но и участвовать в реальном bench-цикле.

Он может:

• работать с локальными файлами проекта;
• использовать shell и developer-инструменты на рабочей машине;
• собирать и прошивать STM32-проекты в Keil;
• управлять helper-платой по UART;
• запускать Saleae Logic 2 через MCP как управляемый прибор;
• ставить marker-события перед действием;
• читать живые данные с линий;
• анализировать результаты и запускать следующую итерацию.

То есть агент уже не просто объясняет, “что, вероятно, происходит”, а наблюдает, что произошло на самом деле.

Что здесь за инструменты

Codex app

Здесь важен не просто сам факт использования модели GPT. Важна среда. Codex app на Windows даёт агенту доступ к локальной рабочей машине: к shell, к проектам, к сборке, к внешним утилитам и к подключённым инструментам.

Именно из-за этого агент перестаёт быть только интерфейсом вопрос-ответ и превращается в участника процесса.

Keil

Keil — это среда разработки для ARM-микроконтроллеров, в которой собираются реальные прошивки под STM32. Для embedded-инженера это обычная рабочая среда, где проект превращается не в абстрактный бинарник, а в код, который реально заливается в устройство.

Важно то, что агент работает не с учебным примером, а с настоящими боевыми проектами, которые дальше идут в железо.

Saleae Logic 2

Saleae Logic 2 — это программа для логического анализатора. Логический анализатор — это прибор, который смотрит на цифровые сигналы в проводах и показывает, что реально происходило на линии: какие были импульсы, какие байты прошли по UART, что происходило на SPI, кто когда переключался.

Обычно человек вручную запускает захват и сам глазами ищет интересный момент. В нашем случае анализатор встроен в автоматизированный цикл: агент может запустить capture, подать marker, получить сырой захват и затем разбирать его уже как данные.

MCP

MCP здесь нужен как мост между агентом и Logic 2. Благодаря ему анализатор становится не просто GUI-приложением, а управляемым инструментом. Это критически важно: без этого пришлось бы снова возвращаться к полу-ручному режиму.

USB-TTL и helper-плата

USB-TTL — это простой адаптер, который позволяет общаться с микроконтроллером через обычный UART как через COM-порт. Через него агент управляет helper-платой.

Сама helper-плата — это небольшой отдельный STM32F030-контроллер, который выполняет роль физического исполнителя:

• даёт импульсы на нужные линии;
• имитирует нажатия;
• выставляет marker для Saleae;
• переключает дополнительные сервисные выходы.

Иными словами, helper-плата — это маленькая физическая рука агента.

Почему здесь использовалась именно STM32F030

STM32F030 здесь важна не потому, что это какой-то “лучший в мире микроконтроллер”, а потому, что это уже знакомая, освоенная и рабочая платформа.

Под “знакомой” в данном случае имеется в виду очень практичная вещь:

• под этот микроконтроллер уже есть реальные проекты;
• уже понятна схема питания и включения;
• уже известны особенности UART, таймеров, GPIO и сна;
• уже есть рабочая привычка писать под него код;
• уже есть живые платы, которые можно использовать сразу, без отдельной новой экосистемы.

Поэтому здесь победил не более “красивый” путь через тяжёлую dev-board и сложный USB stack, а гораздо более зрелый инженерный выбор: взять знакомую STM32F030-платформу и превратить её в компактный helper-инструмент для bench automation.

Почему это ощущается как будущее

Потому что раньше физический цикл разработки выглядел так:

• инженер меняет код;
• инженер шьёт плату;
• инженер запускает анализатор;
• инженер руками переводит устройство в нужный режим;
• инженер пытается глазами поймать важный момент;
• инженер потом вручную сопоставляет импульсы, байты и поведение устройства.

Теперь этот цикл может выглядеть по-другому:

1. агент читает проект;
2. агент меняет логику;
3. агент шьёт устройство;
4. агент запускает анализатор;
5. helper-плата даёт физическое действие и marker;
6. агент получает реальный цифровой след реакции устройства;
7. агент корректирует следующую итерацию.

Это и есть тот момент, когда AI перестаёт быть “умной клавиатурой” и начинает становиться частью инженерного цикла.

Самое интересное: дело не в одной прошивке, а в целой серии итераций

Особенно хорошо это видно на задачах, где нельзя просто сказать “прошивка работает” или “не работает”. Например:

• адаптивный приём;
• подстройка чувствительности;
• выбор порога детекции;
• баланс между скоростью реакции и устойчивостью;
• работа при слабом или нестабильном внешнем сигнале;
• анализ ложных срабатываний;
• доводка алгоритма удержания сигнала.

В такой задаче мало выполнить один удачный запуск. Нужно пройти десятки маленьких итераций, где каждая следующая версия становится чуть лучше предыдущей.

Именно здесь такой стенд начинает раскрывать свою настоящую силу.

Если у системы есть понятный внешний источник сигнала и воспроизводимая схема эксперимента, агент может сидеть в этом цикле столько, сколько потребуется:

• менять параметры;
• снова шить;
• снова запускать прогон;
• снова снимать результат;
• снова сравнивать поведение;
• снова улучшать алгоритм.

Не в смысле “вечной магии”, а в смысле реальной инженерной итерации до тех пор, пока качество не выйдет на нужный уровень.

Из чего состоит этот стенд

Целевой STM32-проект

Это обычная рабочая прошивка, живущая в Keil.

Helper-плата на STM32F030

Отдельный минимальный исполнительный контроллер для физических действий и marker-сигналов.

Saleae Logic 2

Управляемый логический анализатор, который фиксирует, что реально происходит на линиях.

Codex app

Среда, в которой агент может склеить всё перечисленное в единый рабочий цикл.

Что уже было подтверждено живьём

На этом стенде уже были реально подтверждены:

• сборка и прошивка STM32-проектов;
• работа helper-платы через USB-TTL;
• генерация marker и action-импульсов;
• запуск захватов в Saleae Logic 2 через MCP;
• считывание и декодирование живых UART-данных;
• сопоставление прошивки, действия и сигнального результата в одном цикле.

Это важно подчеркнуть отдельно: речь идёт не о концепте, а о реально работающем лабораторном инструменте.

Что в этом особенно ценно

Самое ценное здесь не конкретная плата, не конкретный программатор и даже не конкретный анализатор.

Самое ценное — это новый способ работы:

• агент не оторван от железа;
• анализатор не отделён от прошивки;
• helper-плата не просто мигает выходами, а становится частью сценария;
• человек перестаёт быть единственным мостом между кодом и физическим устройством.

Не “AI помогает писать код”, а:

AI начинает участвовать в живом embedded-цикле от гипотезы до физически измеримого результата.

Почему всё это сделали именно так, а не “красивее”

Потому что в реальной лабораторной практике побеждают не самые академичные решения, а самые живучие.

Можно было строить громоздкую архитектуру, сложный USB stack, абстрактный framework и тяжёлую dev-board-систему. Но по факту победил более зрелый вариант:

• знакомая STM32F030-платформа;
• компактный helper-runtime;
• обычный UART;
• несколько полезных линий;
• логический анализатор;
• понятный bench workflow.

Выглядит это скромно. В работе — очень мощно.

Зачем это всё дальше

Потому что один раз собранный такой цикл потом начинает работать не на одном устройстве, а на целом классе проектов.

Если новый проект тоже живёт на STM32, имеет кнопку, сигнальные пины, UART или SPI и требует живой доводки поведения, то уже не нужно каждый раз изобретать лабораторию заново. Агенту достаточно дать:

• путь к проекту;
• контекст helper-платы;
• контекст Saleae;
• конкретную инженерную цель.

И дальше он может входить в процесс не как “консультант”, а как участник итерационной доводки.

Короткий итог

Это не история про то, как AI красиво пишет код.

Это история про то, как AI начинает работать с реальным устройством в одной цепочке с прошивкой, анализатором, сигналами и физическим экспериментом.

И когда один раз видишь, что агент действительно может не только советовать, но и участвовать в реальном цикле доводки железа, становится понятно: это уже не просто удобный инструмент. Это реально наступивший кусок будущего.