То, что ИИ заменил кодеров, уже ясно. А электронщиков ещё нет. Или уже?
Я решил проверить, какова ситуация сейчас, и применил ИИ везде, где смог, при разработке универсального сенсора присутствия.
Я сделал плату с радаром на 60 ГГц и прошивку к ней, и почти на каждом шаге использовал Claude, чаще всего Fable 5. Он подбирал мне микроконтроллер, планировал функции выводов, анализировал комплектацию, писал скрипты для Altium, драйверы и прикладной код. И знаете, практически получилось с первой итерации!
Исходники платы и прошивки опубликованы в отдельном репозитории.
Что делает эта плата
Это универсальный контроллер доступа и безопасности. На борту дисплей, джойстик, CAN, USB, 1-Wire (он же Dallas) для контактных и бесконтактных ключей, шина расширителей ввода-вывода и аудиоусилитель. И главная фишка: радарный чип BGT60TR13CE6327XUMA1.
Детекция присутствия человека критически важна во многих промышленных системах, а плата разработана именно для промышленного применения. Но и в умном доме такая плата очень полезна, вплоть до того, что она может детектировать дыхание ребёнка и его движения либо жизнеспособность пациентов в больницах. А может у качка в спортклубе после тяжёлого подхода измерить дыхание, пульс и тремор.
Выбор микроконтроллера
Обслуживание радара типа BGT60TR13 и всей намеченной периферии требует значительных вычислительных ресурсов. Тут не обойтись чем-то вроде ESP32 или RP2350. Надо было искать более тщательно. С самого начала я решил, что отдам плату на сборку в JLCPCB, поэтому поиск дополнительно ограничивался стоком LCSC. Раньше такая задача выбора микроконтроллера заняла бы неделю, не меньше. Это составление сравнительных таблиц, сравнение параметров, сравнение экосистем средств разработки, сравнение цен и складских запасов, изучение мануалов и поиск подводных камней. Сильнейшим аргументом был бы и предыдущий опыт работы с семействами микроконтроллеров. Я даже уверен, что на складе LCSC я бы либо не нашёл ничего для себя подходящего, либо взял что-то из безумно дорогого.
Claude ничего этого про меня не знал и практически сразу вывел на Artery AT32F435. Чип содержит Cortex-M4F на 288 МГц, имеет 1 МБ флеша, 384 КБ ОЗУ и корпус LQFP64. Совершенно непонятное для меня семейство, как будто клон STM32, но непонятно, насколько полный клон. Сам бы такое не выбрал. Экосистема гораздо беднее STM32, конфигуратора типа CubeMX не имеет, таких нишевых чипов вообще стараюсь избегать. Но доверился Claude.
Первое, с чего надо начать, когда выбрал новый микроконтроллер, — это создать его схемное изображение с полным перечислением функций пинов. Я так всегда делаю. Claude Fable 5 мне быстро по PDF создал полную таблицу пинов и всех их альтернативных функций в файле uC_Pin_functions_table.xlsm. На это ушло полдня.
Потом он создал мне таблицу назначения функций на пинах для оптимального подключения всей моей желаемой периферии (схемы к этому моменту ещё не было) в файле uC_Pin_planing.xlsm.
Затем я в схемной библиотеке Altium с помощью функции Symbol Wizard скопировал из специально созданной в Excel таблицы распиновку и сгенерил схемный компонент.
Создание схемы
Сначала была мысль сделать интерфейс расширения ввода-вывода на простейших сдвиговых регистрах. Claude мне за пять минут создал такую схему. Нет, не нарисовал, а написал словами, какие микросхемы и детали нужны и какие цепи к каким пинам подключить, что-то типа текстового описания схемы, применяющегося в симуляторах SPICE. Потом выяснил, что расширители ввода-вывода с I2C стоят почти так же. И бросил идею со сдвиговыми регистрами. На этот экзорцизм (изгнание беса экономии на спичках) ушёл день. Дальше дело пошло быстрее. Вся остальная обвязка в принципе стандартная. Копипастилась из предыдущих схем.
Подбор комплектации
Схему создал поначалу на деталях из своих библиотек, довольно архаичных, созданных на предыдущих проектах. Тут ожидается неприятная рутина, и её всё время хочется отложить или пропустить. Начинается, когда надо всем мелким резисторам и конденсаторам точно расставить уникальные идентификаторы производителей. Это прямо бич начинающих электронщиков: поставить номинал на резистор и забыть о нём. Ни его точность, ни его механические свойства, ни его паразитные свойства, ни мощность: ничего не известно. Есть сборщики, которые сами поймут, что там должно быть, но JLCPCB не такие. Малейшая неточность — и молчаливый отказ портала, либо запаяют абсолютно не то.
Удалось неплохо автоматизировать этот процесс с помощью ИИ.
Сначала Claude написал мне программу на скриптовом языке Altium. Она обходит все компоненты схемы и выгружает в CSV десигнатор и все пользовательские параметры каждого. AltiumParamExport.pas, 6 килобайт.
Потом расширение Claude прямо в Excel подобрало замены по стоку LCSC. По каждой позиции: найти то же самое, проверить, что оно есть на складе прямо сейчас, и если нет, подобрать замену с тем же корпусом, номиналом, вольтажом, допуском и диэлектриком.
А потом второй скрипт залил новые партномера обратно в схему. AltiumParamImport.pas, 10 килобайт. Altium отдал схему в Excel и получил её обратно уже пересобранной под склад.
Не всё, честно сказать, Fable 5 мне нашёл в LCSC. Некоторые вещи нашёл, но они реально отсутствовали на складе. Это можно объяснить тем, что я не использовал API LCSC. И как искал Fable, остаётся лишь догадываться.
Структурная схема
Сначала вся плата одной картинкой:
В центре AT32F435, вокруг него периферия. Шину SPI1 делят радар и EEPROM, причём радар живёт на 1,8 В и общается через трансляторы уровней. Дисплей — на отдельной SPI3, и работает она только на запись. Джойстик — это пять обычных GPIO. USB-C служит сервисным портом, CAN связывает плату с остальным оборудованием, USART2 работает мастером 1-Wire, ЦАП через усилитель выводит звук на динамик, и наружу уходит шина расширителей ввода-вывода.
Дерево питания
На входе — 24 вольта от внешнего питания. Дальше по цепочке:
защита входа: диод Шоттки
PDS760-13от переполюсовки и супрессорSMBJ28Aот выбросов;импульсный
XL1509-5.0E1с дросселем 47 мкГн даёт 5 В;линейный
AMS1117-3.3даёт 3,3 В;линейный
RT9013-18GBдаёт 1,8 В радару.
Сигнал DCDC_OFF позволяет микроконтроллеру через вывод PA1 отключить 24-вольтовый преобразователь. Это нужно при питании платы от USB через сервисный разъём, а также для перезапуска периферии при сбоях, которые нельзя устранить программным сбросом, например при защёлкивании портов. Высокий уровень на PA1 отключает питание платы, что отмечено в таблице пинов.
Монтажные отверстия H1–H4 соединены с землёй схемы через перемычку R19 номиналом 0 Ом. При необходимости её можно выпаять и отключить корпус от земли схемы, например при возникновении контура заземления.
Узел радара
Радар работает от 1,8 В, а микроконтроллер — от 3,3 В. Поэтому нужны:
стабилизатор
RT9013-18GBдля шины 1,8 В;два транслятора уровней
SN74AVC4T245RSVRмежду SPI микроконтроллера и радара;опорный генератор на 80 МГц.
Радар имеет шесть отдельных выводов питания: VDD_D, VDD_A, VDD_RF, VDD_PLL, VDD_VCO и VDD_LF. Каждый подключён к шине 1,8 В через отдельную ферритовую бусину. Седьмая бусина фильтрует питание опорного генератора.
Пять бусин имеют импеданс 600 Ом на 100 МГц. Для VDD_RF и VDD_VCO применены бусины на 120 Ом, поскольку эти цепи потребляют больший ток и требуют меньшего падения напряжения.
Шум в цепях питания VCO и PLL вызывает фазовый шум зондирующего сигнала. Он снижает точность измерения малых перемещений, поэтому эти цепи требуют отдельной фильтрации.
В качестве опорного генератора выбран KC2016Z80 от Kyocera AVX с точностью ±20 ppm. Генераторы на 80 МГц в корпусе 2016 отсутствовали среди доступных недорогих компонентов.
Дисплей и джойстик
Пользовательский интерфейс состоит из дисплея и пятипозиционного джойстика.
Дисплей ZJY имеет диагональ 1,54 дюйма, разрешение 240 × 240 точек, матрицу IPS и контроллер класса ST7789. Модуль устанавливается в разъём X5 с шагом 2,54 мм. Интерфейс SPI3 работает только на запись, поскольку линия MISO отсутствует. Изображение можно программно поворачивать на 0°, 90°, 180° и 270°, поэтому плату можно устанавливать в разных ориентациях.
Дополнительные сигналы управляют сбросом, выбором между командами и данными, а также подсветкой. При запуске дисплей удерживается в состоянии сброса до инициализации драйвером. Подсветка подключена к каналу таймера, но в текущей прошивке используется только включение и выключение.
Джойстик ALPS SKRHABE010 поддерживает четыре направления и нажатие по центру. Общий вывод подключён к земле, а внутренние подтяжки микроконтроллера позволяют обойтись без внешних резисторов. Дребезг контактов обрабатывается в прошивке. Имена цепей NAV_SW1…NAV_SW5 не соответствуют физическим направлениям, поэтому их назначение задано таблицей в прошивке по результатам проверки платы.
Сама плата
Плата спроектирована в строгом соответствии с технологическими требованиями стандартной услуги Standard PCB/PCBA компании JLCPCB для плат из FR-4. Её изготовление и монтаж не требуют специальных технологических процессов или расширенных производственных опций.
Изготовление пяти печатных плат обошлось в 63 евро.
Итого: 80 на 70 мм, четыре слоя, толщина 1,645 мм, 142 компонента, 380 связей, разведено на 100%. Дорожки в основном 0,15 мм, переходных отверстий 309 штук по 0,3 мм, всего отверстий 393.
Расстановка и трассировка в Altium
Расстановка компонентов и трассировка платы пока выполняются вручную. Для этих этапов я не нашёл подходящего применения ИИ. Однако Altium упрощает работу с помощью интерактивной трассировки, автоматического раздвигания проводников, выравнивания дорожек и проверки правил в процессе работы.
Дисплей установлен на контактной колодке, поэтому при необходимости его можно снять. Он расположен над центральной частью платы и не перекрывает поле обзора радара. В рендере стекло дисплея сделано полупрозрачным, чтобы показать процессор и трансляторы под ним.
Снизу пусто. Все 130 с лишним SMD-компонентов сидят на верхней стороне, а на нижней — только пять сквозных разъёмов: питание, CAN, 1-Wire, динамик и шина расширителей ввода-вывода. Это осознанно: одна сторона рефлоу вместо двух — дешевле и быстрее в сборке.
И она же целиком, со всех сторон:
Внутренние два слоя — это сплошные полигоны, наружные тоже залиты землёй. Для платы с радаром на 60 ГГц это не роскошь.
Роковая ошибка
Я передал Claude на проверку распиновку микроконтроллера и подключение его сигналов, но не всю законченную схему. Поэтому ошибка в трансляторах уровней U3 и U4 осталась незамеченной.
Для SN74AVC4T245 я использовал посадочное место и нумерацию выводов корпуса RGY, а в спецификацию добавил SN74AVC4T245RSVR в корпусе RSV. Эти корпуса имеют разную распиновку:
Сигнал |
Корпус RGY |
Корпус RSV |
|---|---|---|
VCCA |
1 |
3 |
1DIR |
2 |
4 |
1A1 |
4 |
6 |
1B1 |
13 |
15 |
1OE |
15 |
1 |
VCCB |
16 |
2 |
В корпусе RSV назначение сигналов смещено на два вывода относительно RGY. В результате контакты питания и данных на плате не совпали с выводами установленных микросхем.
После обнаружения ошибки Claude предложил, как повернуть U3 и U4, чтобы сократить длину проводников и упростить пайку. Для этого он также скорректировал схему подключения сигналов. Микросхемы установлены выводами вверх и вручную соединены с платой тонкими проводниками. Соединения закреплены термоклеем.
Причиной ошибки стали спешка и отсутствие установленной процедуры проверки всей схемы с помощью ИИ перед заказом платы. А я почему-то не дал ИИ проверить всю схему, хотя спокойно отдал ему на проверку схему подключения микроконтроллера, и он успешно находил там неточности. Тут меня подвело недоверие.
Первый день разработки прошивки
Исходный код прошивки находится в том же публичном репозитории, что и проект платы.
9 июля, в день получения платы, я сделал 23 коммита:
11:46...12:24 структура проекта, таблица пинов, карта памяти и пакет поддержки AT32F435 12:42 ThreadX 6.5.1 12:49 SEGGER RTT 13:25 USB CDC-ACM и телеметрия 14:49 дисплей 15:12 EEPROM и параметры 17:48 клиент телеметрии в браузере 23:55 джойстик и оконный менеджер
Сначала я проверил назначение выводов, настроил отладчик, ThreadX, журнал и телеметрию. После этого начал добавлять функции устройства.
Управляющий блок SEGGER RTT закреплён линкером по адресу 0x20000000. RTT Viewer подключается по известному адресу без сканирования RAM.
Лучше полдня потерять, но начать пилить фичи уже на платформе, полностью вооружённой отладочными каналами.
Распределение оперативной памяти
Внешней RAM на плате нет, а микроконтроллер имеет 384 Кбайт внутренней SRAM. Из неё 115 200 байт занимает кадровый буфер дисплея, около 46 Кбайт требуется библиотеке определения присутствия. Остальная память нужна для данных радара, USB, стеков ThreadX и других задач. Поэтому от распределения RAM зависит, какие функции могут работать одновременно.
Секция FREE_MEM размещена последней в RAM, а символ __ram_end__ указывает на конец памяти. Область между занятыми секциями и концом RAM передаётся пулу ThreadX. При изменении размера .bss границу пула пересчитывает линкер.
Стеки семи потоков выделяются из пула при запуске и затем не освобождаются. Единственный статический стек используется GUIX и занимает 2 Кбайт. Если памяти для задачи недостаточно, она не создаётся, причина записывается в журнал, а остальные задачи продолжают работать.
Пул занимает область от 0x2003A2A0 до 0x20060000: 154 976 байт, или 39% RAM. Стеки семи потоков используют менее 8 Кбайт. Кадровый буфер дисплея размером 115 200 байт выделяется до создания пула.
Мелкое, но неприятное упущение
Это упущение возникло на этапе составления схемы, когда Claude анализировал и распределял функции выводов микроконтроллера. При выборе интерфейса для радара не были учтены доступные делители частоты и задержка транслятора уровней. В результате SPI1 оказался не самым удачным выбором, а после изготовления платы проблему пришлось решать программным снижением частоты APB2.
При запуске радара обмен по SPI на расчётных частотах оказался нестабильным. Радар работает с уровнями 1,8 В, микроконтроллер — с 3,3 В, поэтому сигнал MISO проходит через транслятор уровней. Его задержка ограничила максимальную частоту интерфейса.
SPI на 48 МГц не работает, а на 36 МГц получено 10 ошибок в 10 циклах. На 24 МГц обмен стабилен.
Частота SPI1 формируется делением частоты APB2. При частоте микроконтроллера 288 МГц стандартная настройка APB2 даёт 144 МГц. Делители SPI у AT32: 2, 3, 4, 8, 16 и далее. Получить 24 МГц от 144 МГц нельзя, поэтому для APB2 установлено 72 МГц. Деление на 3 даёт требуемые 24 МГц. Других потребителей APB2 на плате нет, а АЦП тактируется от другой шины.
Определение и настройка радара выполняются на 9 МГц. Рабочая частота составляет 24 МГц, при ошибках драйвер BGT60TR13C снижает её до 18, затем до 9 МГц.
К драйверу шины SPI1 также подключена EEPROM. Радар работает на 24 МГц, а EEPROM — на 9 МГц при допустимом максимуме 16 МГц. Доступ к шине защищён мьютексом с наследованием приоритета. Перед каждой транзакцией драйвер при необходимости изменяет делитель.
Как работает FMCW-радар
FMCW (Frequency-Modulated Continuous Wave) — это радар с непрерывным излучением и частотной модуляцией. Он формирует чирп от 61,02 до 61,48 ГГц с полосой 460 МГц. Задержка отражённого сигнала преобразуется в разностную частоту. После фильтрации и БПФ получается профиль дальности. При такой полосе шаг профиля составляет 32,6 см.
Кадр содержит 128 отсчётов на чирп, 16 чирпов и данные трёх приёмных антенн: всего 6 144 отсчёта. Частота кадров составляет 50 Гц, период равен 20 мс. После команды запуска радар формирует кадры по своему таймеру, выдаёт прерывание, а задача радара забирает данные по DMA.
Радар работает непрерывно. Повторный запуск требует стабилизации PLL и добавляет джиттер в данные.
Детектор присутствия
Основной детектор использует библиотеку Infineon и занимает около 46 Кбайт памяти из пула. Библиотека анализирует изменение профилей дальности во времени и отдельно определяет крупные и малые движения.
Если память для библиотеки выделить не удаётся, модуль обработки радара записывает ошибку в журнал и переключается на резервный детектор. Он хранит отдельную базу для каждого бина дальности. Вверх база изменяется с коэффициентом 0.005 и постоянной времени около 11 секунд, вниз с коэффициентом 0.05 и постоянной около 1 секунды. Активный алгоритм указывается в телеметрии.
При полосе 460 МГц физическое разрешение по дальности составляет 32,6 см. Параболическая интерполяция по максимальному бину и двум соседним позволяет оценить положение одиночной цели с шагом около 3...5 см, но не позволяет разделить близкие цели в одном бине.
Дисплей и телеметрия в браузере
Дисплей 240 × 240 точек подключён по SPI со скоростью 36 Мбит/с. Второй буфер потребовал бы ещё 115 200 байт RAM, поэтому двойная буферизация не используется. DMA не применялся: при частичном обновлении экрана программная передача поддерживает полную скорость SPI, а асинхронная передача потребовала бы дополнительной синхронизации единственного кадрового буфера.
Графическая библиотека GUIX обновляет только изменившуюся область экрана. Драйвер дисплея ожидает освобождения передающего регистра SPI перед записью следующего байта, а полного завершения обмена — один раз в конце блока. По сравнению с ожиданием завершения каждого байта это увеличило скорость заливки примерно в три раза.
Поток графики имеет приоритет 20, а задача радара имеет приоритет 13. Поэтому радар может прервать отрисовку.
Адрес буфера кадра добавлен в таблицу телеметрии. Браузер считывает через USB 115 200 байт частями и формирует снимок экрана. Отдельная команда не требуется: протокол поддерживает чтение областей памяти.
WebDevLink
WebDevLink — браузерное приложение для настройки и диагностики контроллера. Оно открывается непосредственно из файла index.html в Chrome или Edge и подключается к виртуальному COM-порту платы через Web Serial API, поэтому устанавливать отдельную программу не требуется. При первом подключении пользователь выбирает порт, а при следующих запусках приложение может восстановить соединение автоматически.
Интерфейс состоит из перемещаемых и изменяемых по размеру панелей; их расположение сохраняется в браузере. В них можно читать и записывать параметры энергонезависимой памяти, наблюдать профиль дальности, положение цели, частоту дыхания и другие диагностические данные, а также получать снимок дисплея платы. Границы зоны присутствия изменяются мышкой, новые значения передаются в плату и применяются примерно за 0,3 секунды. На дисплее платы выводится текст, а подробные графики отображаются в браузере.
Подключение к Infineon Radar Fusion GUI
Infineon Radar Fusion GUI работает с отладочными платами через протокол Strata. Для подключения моей платы в прошивку добавлен мост этого протокола через USB. Он позволяет программе управлять радаром и записывать необработанные данные.
Мост занимает 3 720 строк кода. Его буфер рассчитан на кадр размером 128 × 32 × 3, то есть 12 288 отсчётов.
Мост и библиотека определения присутствия не могут одновременно использовать доступный пул памяти. При переходе в режим моста библиотека освобождает около 46 Кбайт. Эти режимы работают поочерёдно.
Мост записывает кадры с временными метками. Затем одни и те же данные можно многократно обрабатывать офлайн и проверять изменения алгоритма без повторения измерений.
Занятость Flash и RAM
После сборки прошивка занимает 335 686 байт Flash: 181 487 байт кода и 154 199 байт константных данных. Это 32,0% доступного объёма в 1 Мбайт. Статические данные занимают 238 249 байт, или 60,6% от 384 Кбайт RAM. Оставшаяся RAM используется динамическим пулом ThreadX.
В обычном режиме, когда на дисплее открыто основное окно приложения, свободными остаются около 98 Кбайт RAM. При работе моста Strata с Infineon Radar Fusion GUI дополнительная память расходуется на буферы необработанных радарных кадров и USB-обмена, поэтому свободный объём сокращается примерно до 45 Кбайт.
Таймлайн проекта
Разработка платы заняла восемь дней. Разработка прошивки заняла пять дней. Между отправкой платы на производство и началом работы с прошивкой прошло двадцать дней.
Итог
Итог, надо сказать, вдохновляющий. Скорость разработки точно выросла в несколько раз. За всё время разработки софта ни разу не пришлось прибегнуть к ручной отладке. Через канал USB агент Claude в VS Code сам мог получать логи и делать исправления. Да, алгоритм ещё сыроват для продукции. Не хватает проверки на краевые условия, помехи, климатику, электромагнитную совместимость. До сертификации здесь как до Луны. Но это уже другая тема.
Комментарии (24)
select26
15.07.2026 16:57Очень Интересный опыт!
Недавно пытался при помощи LLM спроектировать аналоговый ЛБП с претензией на прецезионность. Использовал ChatGPT.
Ну не очень как. Он прямо сам признавал. По каким-то узлам на вопросы давал толковые советы. Но вот целиком сделать схему не смог.
Модет аналог просто сложнее?
yasnolesskiy
15.07.2026 16:57Нет, просто LLM работает не так, как вы от неё хотите. Алгоритм Трансформера не способен думать и размышлять. Он способен только сопоставить семантику вашего запроса со своими обученными весами и подобрать наиболее вероятное ассоциативное продолжение для этого запроса. Если обучить модель на том, что миром правят рептилоиды, то она и будет подбирать ассоциацию "кто миром правит? рептилоиды".
В качестве исходных данных для обучения в модель могли засунуть учебники, научные статьи, ветки форумов. Собственно при запросе в качестве ответа модель и выдаёт средневзвешенное наиболее вероятное "best practice" решение на основе наиболее встречающихся вхождений. Скорее всего в исходных данных много информации о том, как например устроены цепочки обратной связи, какие ОУ туда лучше подобрать, какое питание соорудить, или о том, как устроены цепи самого силового преобразователя, какие компоненты туда подобрать.
Но как только задаётся какая-то более комплексная задача, скорее всего кончается контекстное окно. Потому что слишком много всего нужно сопоставить, слишком глубоко залезть в различные решения.
Поэтому самым эффективным, в данном случае, будет в одном чате спросить про общую топологию, попросить декомпозировать, в других отдельных чатах подробно проработать каждый узел (при этом разобраться самому! и при этом прикинуться самым глупым и выступать самым строгим критиком) и в третьих отдельных чатах уточнить, как один узел срастить с другим. Только так ИИ становится помощником, а не вредителем, разлагающим мышление и приводящим к ошибкам.
trueKapitoshk
15.07.2026 16:57То, что ИИ заменил кодеров, уже ясно.
Пока не заменил даже кодеров, не говоря уже о программистах.
yasnolesskiy
15.07.2026 16:57Блин, я думал будет хоть какая-то аналитика, комментарии по типу "вот тут ИИ сделал правильно, а тут - неправильно", выводы. А это просто статья с описанием шагов и действий, ценность сомнительная.
Плюс ко всему, в статье категорически не хватает описательной части самого проекта. Не очень понятно, что это такое. Это девборда для радара? Зачем тогда доп. компоненты и мощный МК, если всё равно всё взаимодействие и обработка происходят через USB. Это девборда для СКУД? Тогда требования по безопасности там несколько другие. Или это всё-таки сенсор присутствия? Зачем тогда 1-wire и остальное, если подобные сенсоры, как правило, устанавливаются незаметно. Непонятно, зачем CAN, к какому оборудованию он будет подключаться. CAN это вообще отдельная область, где надо правильно согласовывать земли, а где-то вообще их гальванически развязывать.
Короче, непонятна мотивация проекта. Какую проблему он решает, какая цель его создания, какие задачи мы ставим перед проектом. Ещё перед тем, как открыть ECAD и IDE, всегда должна быть проработана методология. Если это чисто взять типовую периферию и посмотреть, как с ней справится ИИ, то это одно. Но ведь и этого не заявлено! А другое - это если эта периферия и остальная топология проекта навязана ИИ, вот тут вообще вопросики возникают к прокладке между клавиатурой и монитором.
Начать можно с того, что выбор конкретно этого чипа - это из пушки по воробьям. Если цель это получение дискретных данных о присутствии, то есть куча готовых mmWave радарных модулей, начиная с примитивных RCWL-0516, HB100, заканчивая как более продвинутыми модулями от Waveshare (копеечными), так и более дорогими, но в то же время более функциональными модулями от Seeed Studio. Они все выдают либо дискретные сигналы, либо какие-то данные по UART. Для их обработки хватает либо Cortex-M0+, либо, если нужна доп. периферия типа CAN/USB - Cortex-M3. Выбранный чип же, скорее подходит под какие-то сверхуниверсальные задачи, где вот прям сырые данные нужны, по типу обработки жестов, как например в Pixel 4.
Вряд ли устройство сегодня занято обычным presence check, завтра перенесено в палату и программно переключено в измерение пульса и дыхания, а послезавтра переключено в считывание жестов. Если это приложение однозадачное, если установка стационарная, то использование чего-либо выше, чем готовые модули, это реально экономически нецелесообразно.
Ну окей, выбрано такое железо. В статье не сказано о том, как подавались промпты, в виде комплексной задачи, либо же с разбиением на подзадачи. Проблема электронного болвана в том, что его контекстное окно видит ситуацию "сверху", и не позволяет без дополнительных запросов докопаться до мышей и выяснить целесообразность и корректность того или иного решения. Выбор датчика тому пример.
В частности, стоит взять этот чип и заглянуть в PCB Layout Guidelines, это вообще база для любой разработки, чего ИИ сделать не в состоянии. 4-слойка, полигоны земли, 0402 - это всё отлично. Но насчёт трассировки дорожек ничего сказать не могу, так как делать это было лень, однако есть важный утерянный момент.
Помнится, одним из первых моих коммерческих проектов было создание трекера движений человека на базе IMU. И тогда ничего не понимающий я первокур зафигачил все IMU на длиннющие провода. По итогу эти провода ловили всё, что попало, встроенный ADC в IMU выдавал какой угодно бред с дичайшим шумом, а не данные. Ну, магистранты на этом всём по итогу модель обучили, какую-то даже минимальную точность оно выдавало, проект с натягом завершили, деньги получили, забыли. Спустя несколько лет я снова столкнулся с IMU, на этот раз в разрезе dead reckoning, и тут очень сильно заморочился на тему качества исходных данных. Потому что они блин очень важны! Ты, в конце концов, не будешь понимать, дело в кривых алгоритмах, в фильтрах, или банально в том, что полезных без шума данных всего 4-5 бит.
Так вот, смею предположить, исходя из того, что не знаю предназначение проекта, что это всё затеяно скорее ради поиграться с радаром. На этот случай в layout guidline крайне рекомендуется положить на плату "electromagnetic bandgap (EBG)" - специальную сеточку из заземлённых падов и via, чтобы заэкранировать радар от шумов платы. Избавляться от сеточки, при этом - компромисс либо в размерах платы, либо в потере чувствительности там, где она и не нужна (например при грубой классификации при подвесе не потолке). Как я понимаю, лимитов по размеру платы особо не было, структуры не были посчитаны и не были размещены, а это тот самый халявный импрувмент, без которого может значительно пострадать программная часть.
Не могу сказать, 8 дней на плату это много или мало, но есть ощущение, что с набранным ритмом и набитой рукой подобный проект за несколько вечеров раскидать можно. Но тут у каждый работает по-своему, для кого-то это ускорит процесс, а кому-то сильно затормозит.
Однако не стоит отрицать того, что с прошивкой оно достаточно быстро разобралось, не имея собственных бойлерплейтов можно быстро собрать прототип, но на продакшн это ни в коем случае тянуть не может.
Что касается применения МК - Artery это широко известная в узких кругах фирма, они стоят копьё, вроде бы даже в РФ официально возятся (но по поставкам сейчас сложно сказать, ибо у Компэла и STM32 появились в оптовых объёмах по приемлемым ценам). Но честно говоря работа с непривычным семейством всегда выливается в сложность адаптации и дальнейшей поддержки, потому что с ростом проекта кончается контекстное окно и в код льётся кучу повторений и артефактов. ИИ это обычно весьма податливое существо и надо было заставить обосновать выбор МК и продавить привычное.
А ещё касаемо SPI, который не завёлся, я на 100% уверен, что дело в соплях, а не задержках. 74AVC по спекам спокойно жмут до 500 МГц. Потыкайте осциллографом на той частоте, на которой не работает, и увидьте потерю формы сигнала.
Выбор питания тоже весьма странный. LDO следует применять с умом, а в каскадах вообще не стоит применять. Как минимум, в каскаде квадратично складывается собственный тепловой шум, что ухудшает шумовые характеристики. Задача LDO же наоборот, задавить ВЧ-помехи. Как максимум, самый первый LDO в цепочке получает кааапец какую тепловую нагрузку, потому что проходные токи складываются. Дело в том, что у LDO ток входа равен току потребления на выходе, а разница напряжений уходит в тепловое рассеивание, на то это и линейник. У радара максимальное потребление заявлено в 200 мА, которые переходят на 3-вольтовый LDO. МК тоже под 200 мА может кушать. А ещё на 3.3 висит дисплей, который под 100 мА может кушать. Итого 0,5А на ровном месте, которые на 3-вольтовом LDO превращаются в (5,0-3,3)*0,5 = 0,85 Ватт тепла, что превышает штатные 0,8 Вт для AMS1117, температура кристалла, при этом, будет минимум 50 градусов, что достаточно много для одного МК, экранчика и датчика. Флешку и остальную ерунду не учитываем, они мизер кушают.
Плюс мы работой грузим регуль 24->5, который вынужден эти 0,5А преобразовывать на сжигание в тепло. А сам регуль XL1509E супер древний, огромный, с низкой рабочей частотой (намоточные изделия крупнее). Это решение не эффективно в 2к26 году.
Я попытался уложиться в 0.5 бакса (XL1509E+AMS1117 на LCSC). В идеале питание должно быть следующим:
1. 24->5, это у нас CAN и 1-wire. CAN будет кушать до 50-100 мА (с запасом), 1-wire не кушает ничего.
(под 1-wire, кстати, можно было не изобретать велосипед, а взять готовый драйвер)
2. 24->3.3, это будет отдельная цепочка, потому что а почему нет. Токи там, как мы знаем, до 0,5А.
3. 3.3-1.8, в идеале, конечно, для лучшего PSSR и снижения теплорассеивания подбирать входное у LDO максимально близко к его dropout, типа 2.5 вольта, но нам оно тут на плате и не требуется.Итого на 24->5 и на 24->3.3 можно повесить, например пару RY8401 (C2912960), это синхронный бак на 800 кГц, 42В предельно по входу, 600 мА выходного тока. Корпус мизерный, SOT-23-6. Стоят по $0.1, плюс к ним пару индукторов на 4.7 мкГн (ещё по $0.05), в обвязку пару резиков и 3 кондёра.
Можно помощнее - HM8342T (C48982461), 1.7А, но 500 кГц.
На 3.3-1.8 LDO можно оставить как есть, хоть RT9013 и EOL, подобрать что-то другое не проблема.Из статьи лично я могу составить вывод, что экспириенс получился хоть и интересный, но электронщиков ещё не скоро заменят, а опыт и умение думать своей головой продолжат цениться больше всего. ИИ всё ещё остаётся помощником, за которым нужно очень и очень много следить.
Brazil Автор
15.07.2026 16:57Согласен, что не описал в подробностях, что именно плата будет делать, кому я её продаю и почём. Из-за этого вам приходится гадать. Сожалею.
Но я действительно никогда не делаю устройства только для одной функции. Чем больше функций удаётся реализовать, тем лучше я считаю результат.
Что касается DC/DC, вы упустили из виду наличие интерфейса расширения. На него предполагалось подключать целую гирлянду внешних модулей, и там даже двух ампер может не хватить. В частности, предполагалось подключать длинную LED-ленту на адресных светодиодах и делать цветомузыку.
slog2
15.07.2026 16:57В общем, ошибок и косяков столько, что цена их исправления перекроет весь ваш выигрыш в скорости.
TimurZhoraev
15.07.2026 16:57Можно попробовать также открытые проекты. В этом случае модель даже может проникнуть в исходники и уловить суть протколов
1. KiCAD - схемы и платы
2. FreeCAD - 3д модельки
3. Python+C/Java+shell - классика на которой тренируются все модели (По опыту Паскаль, bat/powershell и прочие - довольно плохо генерируются ввиду недостатка датасетов и хороших примеров)
4. LayoutEditor имеет в комплекте автороутер (запускается через java jar) он же FreeRouting - можно делать do-файлы Specctra. Роутит качественно, при должном указании атласа цепей ручная корректировка практически минимальна. Также можно попросить залить полигоны под процессорами, источниками питания итд
5. kipart - отличная штука, понимаемая многими моделями вплоть до генерации распиновки по картинке
6. локальный RAG на преобразователе pdftotext -layout input.pdf output.txt - нет ничего проще, формируется файл который можно отправить в qdrant создав векторную БД для модели (например на эмбеддере BAAI/bge-m3), читает даташиты и понимает что там написано для любой микрухи
7. Формат схематика для KiCAD - открытый, не нужно дополнительно пинать доки по API-Delphi для Altium, можно сгенерировать Питон который также нарисует схему или взять готовый например тут. Вплоть до использования локального автороутера который пробрасывает провода на схеме как если бы это была печатная плата. Достаточно расставить компоненты и соединить их по нетлисту (примерно как в Симулинке Матлаба при протаскивании и оптимизации).
AlexMiller001
15.07.2026 16:57Интересно узнать в каком формате Claude кушал схему для проверки соединений? Чистый netlist?
Brazil Автор
15.07.2026 16:57Нет, Claude получал схему в pdf файле , он ее преобразовывал просто в растровый png файл когда анализировал.
Но у меня схема так сделана, что на ней легко идентифицируются отдельные узлы. Это кстати тоже лайфхак. Надо наверно было написать.
И вот по такому рисунку он мне спокойно указал на несоответствие назначения выводов на схеме и назначения выводов в табличе Excel и корректировал Excel.AlexMiller001
15.07.2026 16:57Хм. Хочется поискать проект где ИИ может читать схему как таблицу или код. Все же для LLM это более нативный формат
g992
15.07.2026 16:57Наверное комментарий аналогичен предыдущим, но все же Не совсем понимаю ценность ии (в данном случае ад Fable 5, которая стоит 50 баксов за 1м выходных токенов, что сопоставимо со стоимостью производства проекта) Выбирать МК по совету ии без сводных табличек, явных преимуществ и недостатков звучит так себе, да и выбор пал на клон STM, мне кажется в первой итерации проще использовать оригинал STM, с софтом проще в случае чего. Ну и не совсем ясны обьективные причины почему ESP не подойдет, ведь лимитирующий фактор в статье приводится как скорость работы, а не наличие того же CAN. При том радар требует 50Мгц SPI, что ESP/RP выдадут спокойно Кмк слепо верить ИИ - такое себе На счет библиотек и скриптов, хз, недавно попадался altium mcp, возможно он был бы профитнее в этом случае, чем писать скрипты и их дебажить. Ну или просто натягать компоненты со snapeda %) Ну и немного настораживает трассировка, вернее кол-во виа на линию, кажется что можно сделать оптимальнее
AlexMiller001
15.07.2026 16:57А почему ИИ хуже snapeda? И там и там может вылезти ошибка цена которого будет нерабочий проект. В целом использовать ии для выбора не самое лучшее решение, но никто не мешает попросить сделать сводную таблицу и проверить уже наиболее подходящий вариант. Это действительно ускорит процесс разработки.
g992
15.07.2026 16:57Тут конечно сугубо мое мнение, но шанс того что ии допустит ошибку наверное больше, чем шанс того что на снепе ошибка, которую не заметили, во втором случае есть шанс что до тебя ее заметили и зарепортили Но в любом случае, УГО и футпринты дело достаточно критическое, как по мне их всегда стоит самому проверять, уж слишком большой цена ошибки может быть Про сводные таблицы от ии я ничего против не имею, сам пользуюсь, мой тейк был больше про то что бы все же сравнить разные варианты
Brazil Автор
15.07.2026 16:57Мне STEP модели и посадоные места рисовал Fable и Opus.
Рисовали прямо по скриншотам из pdf. Рекомендую.
Получаются гораздо приятнее и точнее чем из snapeda.g992
15.07.2026 16:57Хмм, вот это полезно весьма, попробую Иногда есть прямо проблемы с поиском моделей Спасибо!
sami777
15.07.2026 16:57расскажите, если несложно, как вы генерировали STEP модели через АИ? Сейчас спросил у Fable про это, а он мне говорит, мол извини, я такого напрямую делать не умею, но если вы мне дадите чертеж, то я сгенерирую скрипт на питон под компас 3Д и он уже сгенерирует готвую 3 Д модель.
Brazil Автор
15.07.2026 16:57Могу дать только скриншот месячной давности.
Может теперь Fable и по другому работает
Brazil Автор
15.07.2026 16:57Согласен что Fable 5 дорог. Но до 19-го он еще включен в план. Поэтому нормально.
Выбор MK по табличкам, я уже склонен считать самообманом. Я это проходил.
Ну не может человек в голове деражать десятки критериев, записывать их в таблички. Искать оптимум. А тот оптимум оказывается в долях процента от среднего.
И все равно кто нибудь из-за плеча уверенно скажет что мог бы это сделать на ESP.
Руководство вооще скажет, что конкуренты на реле делают и хорошо живут.
Классика жанра.
Вся статья о том что "проще" и "оригинал" теперь не имеют значения. Я создал полнофункциональную прошивку вообще не заглядывая в даташит AT32F435 . Что может быть уже проще!
Про SPI на 50 Мгц вопрос коварный. Советую проконсультироваться у Fable 5. Он вам построит бюджет задержек и на пальцах покажет, что дело не в частоте клока и не в согласовании линий, а в том что ваша периферия SPI не умеет постраивать точку выборки. А у радара специфически смещены фронты. И нужна более навороченная периферия SPI. Такая есть у чипов Infineon. И с ними та же схема работает отлично. Но это я уже потом понял.
Про via тоже вопрос про дельту отимальности. Вы чуть уменьшите овершутинги , и вообще не почуствуете разницы, и плата дешевле не станет. Но потратите лишний день.
Такое и со мной бывало. Я это вижу как прокастринацию. Боязнь перехода к более сложному этапу - программированию.
Про MCP-серверы для Altium Designer не слышал. ChatGPT говорит что просто теже наборы Delphi скриптов. Это тот же мой подход. Я и сам пог собрать свои скрипты вместе и назвать их MCP сервером.
Настоящее же API ребята из Altium продают очень задорого. Я жду когда Renesas уже откроет бесплатный движок Altium в облаках. Правда тогда придется плото сесть на семейство RA8.g992
15.07.2026 16:57Если в подписке, то вопрос цены снимаю полностью Про таблички я не имел ввиду детальные сравнения, просто в статье выбор описан как «мне сказал фейбл, я взял», если это просто демонстрация возможностей ии в электронике на данный момент, то вопросов нет, но как продуктовое решение, наверное рисково без сравнений Касаемо трассировки и виа, тут скорее было очень личное мнение и профдеформация после работы в телекоме, ну и особо никогда не было страха перехода к программированию, так как это не моя работа Про mcp сказал просто как замену, что можно не тратить токены на написание скриптов, а взять готовое и дать нейронке уже интерфейс взаимодействия, просто что бы не делать то, что уже кто то сделал И хотел по поводу облачного бесплатного ренесас альтиума спросить, а есть ли какая то инфа/новости по этому? Последнее что помню только выкуп альтиума ренесасом, но что бы они что то бесплатное обещали… По поводу spi, после заброса инфы ChatGPT, он сказал что у esp-s3 вполне гибкий SPI, а на rp2350 можно почти что угодно сделать на PIO блоках В любом случае статья интересная Хотел еще спросить, не пробовали ли фейблом ревьювить проекты? С чатом проверяю такое почти каждое обновление, но вроде как еще не эволюционировал до того, что бы корректно считать большую схему и показать ошибки уровня человеческого фактора
Brazil Автор
15.07.2026 16:57Ревью проектов я не делаю. Так как сам по себе.
Я проекты сразу в производство отдаю. Если что не так - то тюниг.
Не помню ошибок которых не мог бы тюнингом выправить.
По Altium.
Сейчас они дают скачать некий обрезанный тулс с названием Altium Designer DEVELOP. По сути тот же десктопный Altium. Но API не видно нигде
Мне скачало бесплатно потому что я и так имею лицензию. Правда старую и не дающую право на обновление. И это сам по себе момент интересный.
sergyk2
15.07.2026 16:57Причиной ошибки стали
отсуствие нормоконтроля и подписи на чертежах (сарказм)
VO_Obsidian
15.07.2026 16:57За перевернутый футпринт и монтаж WQFN проволочками сразу лойс!
Расстановка компонентов и трассировка платы пока выполняются вручную. Для этих этапов я не нашёл подходящего применения ИИ
А как же quilter? Даже есть бесплатные прогоны. Правда там получается ну очень инопланетная расстановка компонентов и нормально это работает только для 4-слоек с очень низкой плотностью, но всё же
Скрытый текст
Это я в производство пускать явно не буду
nv13
А вот интересно, не в Вашем теперешнем случае, а в принципе - можно ли "подмазать" эту Claudю для роста продаж?)))