Comments 32
Claude ничего этого про меня не знал и практически сразу вывел на Artery AT32F435. Чип содержит Cortex-M4F на 288 МГц, имеет 1 МБ флеша, 384 КБ ОЗУ и корпус LQFP64. Совершенно непонятное для меня семейство, как будто клон STM32, но непонятно, насколько полный клон. Сам бы такое не выбрал
А вот интересно, не в Вашем теперешнем случае, а в принципе - можно ли "подмазать" эту Claudю для роста продаж?)))
Очень Интересный опыт!
Недавно пытался при помощи LLM спроектировать аналоговый ЛБП с претензией на прецезионность. Использовал ChatGPT.
Ну не очень как. Он прямо сам признавал. По каким-то узлам на вопросы давал толковые советы. Но вот целиком сделать схему не смог.
Модет аналог просто сложнее?
Нет, просто LLM работает не так, как вы от неё хотите. Алгоритм Трансформера не способен думать и размышлять. Он способен только сопоставить семантику вашего запроса со своими обученными весами и подобрать наиболее вероятное ассоциативное продолжение для этого запроса. Если обучить модель на том, что миром правят рептилоиды, то она и будет подбирать ассоциацию "кто миром правит? рептилоиды".
В качестве исходных данных для обучения в модель могли засунуть учебники, научные статьи, ветки форумов. Собственно при запросе в качестве ответа модель и выдаёт средневзвешенное наиболее вероятное "best practice" решение на основе наиболее встречающихся вхождений. Скорее всего в исходных данных много информации о том, как например устроены цепочки обратной связи, какие ОУ туда лучше подобрать, какое питание соорудить, или о том, как устроены цепи самого силового преобразователя, какие компоненты туда подобрать.
Но как только задаётся какая-то более комплексная задача, скорее всего кончается контекстное окно. Потому что слишком много всего нужно сопоставить, слишком глубоко залезть в различные решения.
Поэтому самым эффективным, в данном случае, будет в одном чате спросить про общую топологию, попросить декомпозировать, в других отдельных чатах подробно проработать каждый узел (при этом разобраться самому! и при этом прикинуться самым глупым и выступать самым строгим критиком) и в третьих отдельных чатах уточнить, как один узел срастить с другим. Только так ИИ становится помощником, а не вредителем, разлагающим мышление и приводящим к ошибкам.
То, что ИИ заменил кодеров, уже ясно.
Пока не заменил даже кодеров, не говоря уже о программистах.
Блин, я думал будет хоть какая-то аналитика, комментарии по типу "вот тут ИИ сделал правильно, а тут - неправильно", выводы. А это просто статья с описанием шагов и действий, ценность сомнительная.
Плюс ко всему, в статье категорически не хватает описательной части самого проекта. Не очень понятно, что это такое. Это девборда для радара? Зачем тогда доп. компоненты и мощный МК, если всё равно всё взаимодействие и обработка происходят через 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, подобрать что-то другое не проблема.
Из статьи лично я могу составить вывод, что экспириенс получился хоть и интересный, но электронщиков ещё не скоро заменят, а опыт и умение думать своей головой продолжат цениться больше всего. ИИ всё ещё остаётся помощником, за которым нужно очень и очень много следить.
А там и без соплей топология такая, что оно и не должно работать.
Согласен, что не описал в подробностях, что именно плата будет делать, кому я её продаю и почём. Из-за этого вам приходится гадать. Сожалею.
Но я действительно никогда не делаю устройства только для одной функции. Чем больше функций удаётся реализовать, тем лучше я считаю результат.
Что касается DC/DC, вы упустили из виду наличие интерфейса расширения. На него предполагалось подключать целую гирлянду внешних модулей, и там даже двух ампер может не хватить. В частности, предполагалось подключать длинную LED-ленту на адресных светодиодах и делать цветомузыку.
Тогда лучше эту гирлянду питать от собственного dcdc
Ну и хорошо, что я упустил расширение, потому что это совсем другой разговор. Чёрт с ними с супрессорами на разъёме (которых кстати и на USB нет! А это очень плохо!)
Но никогда не смешивайте дежурку, т.е. собственное питание управляющей схемы, вместе с питанием модулей.
Только не говорите ещё, что собирались с USB-C снимать эти пару ампер, пока "сервисный USB подключен и подаётся сигнал DCDC_OFF ".
В любой системе, где предполагается какая-либо модульность, в любом разъёме, низковольтное питание, которое, казалось бы, идеально подойдёт для запитки системы, существует там либо для согласования уровней, либо для совсем маломощных потребителей.
В стандарте питания ATX дежурка материнки (+5VSB) снимается с отдельного трансформатора. В ethernet нет питания. В RS232 (в DB9) нет питания. В LPT нет питания. Любой нормальный программатор никогда не запитывает Target.
Должно быть разделение ответственности. В идеале на колодку выводится входное напряжение (либо первичная дежурка типа 12/24В), а модуль уже разбирается с этим сам.
В более простых случаях список модулей должен быть конечным и ограниченным, каждый модуль должен быть посчитан, а на объекте доступ к подключению модулей должен быть выдан только штатному сервисному инженеру, который понимает, что делает и которому выданы все инструкции и изложены последствия.
И то, в таком случае, я бы делал "бутерброд" из отдельной платы питания, с мониторингом и защитами, основной управляющей доски и сверху модулями. И то, там бы всё равно было разделение на отдельные дежурку и на питание модулей.
Есть куча ситуаций, где общее питание на управляющей плате может навредить всей схеме. Уход в защиту основного регуля из-за КЗ или переполюсовки на каком-то из модулей (проц не запустится и не увидит косяк). Перегрузка основного регуля по току из-за модулей. Пробой из-за перегрузки основного регуля с последующим прогаром на плате (системную плату восстанавливать дороже, чем плату дистрибуции питания). Пробой основного регуля, а вслед за ним каскадный пробой LDO, потому что ams1117 не сдюжит 24, а если бы и сдюжил, то падение 19 вольт при тех же 0.5А нагрузки моментально бы его выжгло.
Вы позиционируете одно из назначений своей железки как СКУД, так вот там вообще тогда плохое питание можно назвать одной из поверхностью атаки. Даже банального предохранителя нет ни по входу. А ещё вы адреску упомянули, это так вообще мрак, там хаотично скачущий по значению ток, плюс каждый диод коммутируется на достаточно низкой частоте, что тащит за собой и выбросы. Вы обалдеете чистить питание для аналогового радара, если будете питать это с одной шины.
Ну отходите уже от концепции ардуино шильдов, которые от одного несчастного USB питаются, и стройте топологию нормально, с учётом всех мер безопасности.
А ещё касаемо SPI, который не завёлся, я на 100% уверен, что дело в соплях, а не задержках.
Еще могут быть программные проблемы. Особенности работы DMA контроллера, или настройки микросхемы радара
At speeds above 25 MHz, you must enable High-Speed Mode (by setting the register SFCTL:MISO_HS_RD = 1). This mode changes how data is sent to give your microcontroller extra time to read the sensor without errors.
В общем, ошибок и косяков столько, что цена их исправления перекроет весь ваш выигрыш в скорости.
Можно попробовать также открытые проекты. В этом случае модель даже может проникнуть в исходники и уловить суть протколов
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, можно сгенерировать Питон который также нарисует схему или взять готовый например тут. Вплоть до использования локального автороутера который пробрасывает провода на схеме как если бы это была печатная плата. Достаточно расставить компоненты и соединить их по нетлисту (примерно как в Симулинке Матлаба при протаскивании и оптимизации).
Интересно узнать в каком формате Claude кушал схему для проверки соединений? Чистый netlist?
Нет, Claude получал схему в pdf файле , он ее преобразовывал просто в растровый png файл когда анализировал.
Но у меня схема так сделана, что на ней легко идентифицируются отдельные узлы. Это кстати тоже лайфхак. Надо наверно было написать.
И вот по такому рисунку он мне спокойно указал на несоответствие назначения выводов на схеме и назначения выводов в табличе Excel и корректировал Excel.
Наверное комментарий аналогичен предыдущим, но все же Не совсем понимаю ценность ии (в данном случае ад Fable 5, которая стоит 50 баксов за 1м выходных токенов, что сопоставимо со стоимостью производства проекта) Выбирать МК по совету ии без сводных табличек, явных преимуществ и недостатков звучит так себе, да и выбор пал на клон STM, мне кажется в первой итерации проще использовать оригинал STM, с софтом проще в случае чего. Ну и не совсем ясны обьективные причины почему ESP не подойдет, ведь лимитирующий фактор в статье приводится как скорость работы, а не наличие того же CAN. При том радар требует 50Мгц SPI, что ESP/RP выдадут спокойно Кмк слепо верить ИИ - такое себе На счет библиотек и скриптов, хз, недавно попадался altium mcp, возможно он был бы профитнее в этом случае, чем писать скрипты и их дебажить. Ну или просто натягать компоненты со snapeda %) Ну и немного настораживает трассировка, вернее кол-во виа на линию, кажется что можно сделать оптимальнее
А почему ИИ хуже snapeda? И там и там может вылезти ошибка цена которого будет нерабочий проект. В целом использовать ии для выбора не самое лучшее решение, но никто не мешает попросить сделать сводную таблицу и проверить уже наиболее подходящий вариант. Это действительно ускорит процесс разработки.
Тут конечно сугубо мое мнение, но шанс того что ии допустит ошибку наверное больше, чем шанс того что на снепе ошибка, которую не заметили, во втором случае есть шанс что до тебя ее заметили и зарепортили Но в любом случае, УГО и футпринты дело достаточно критическое, как по мне их всегда стоит самому проверять, уж слишком большой цена ошибки может быть Про сводные таблицы от ии я ничего против не имею, сам пользуюсь, мой тейк был больше про то что бы все же сравнить разные варианты
Мне STEP модели и посадоные места рисовал Fable и Opus.
Рисовали прямо по скриншотам из pdf. Рекомендую.
Получаются гораздо приятнее и точнее чем из snapeda.
Хмм, вот это полезно весьма, попробую Иногда есть прямо проблемы с поиском моделей Спасибо!
расскажите, если несложно, как вы генерировали STEP модели через АИ? Сейчас спросил у Fable про это, а он мне говорит, мол извини, я такого напрямую делать не умею, но если вы мне дадите чертеж, то я сгенерирую скрипт на питон под компас 3Д и он уже сгенерирует готвую 3 Д модель.
Согласен что 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.
Если в подписке, то вопрос цены снимаю полностью Про таблички я не имел ввиду детальные сравнения, просто в статье выбор описан как «мне сказал фейбл, я взял», если это просто демонстрация возможностей ии в электронике на данный момент, то вопросов нет, но как продуктовое решение, наверное рисково без сравнений Касаемо трассировки и виа, тут скорее было очень личное мнение и профдеформация после работы в телекоме, ну и особо никогда не было страха перехода к программированию, так как это не моя работа Про mcp сказал просто как замену, что можно не тратить токены на написание скриптов, а взять готовое и дать нейронке уже интерфейс взаимодействия, просто что бы не делать то, что уже кто то сделал И хотел по поводу облачного бесплатного ренесас альтиума спросить, а есть ли какая то инфа/новости по этому? Последнее что помню только выкуп альтиума ренесасом, но что бы они что то бесплатное обещали… По поводу spi, после заброса инфы ChatGPT, он сказал что у esp-s3 вполне гибкий SPI, а на rp2350 можно почти что угодно сделать на PIO блоках В любом случае статья интересная Хотел еще спросить, не пробовали ли фейблом ревьювить проекты? С чатом проверяю такое почти каждое обновление, но вроде как еще не эволюционировал до того, что бы корректно считать большую схему и показать ошибки уровня человеческого фактора
Ревью проектов я не делаю. Так как сам по себе.
Я проекты сразу в производство отдаю. Если что не так - то тюниг.
Не помню ошибок которых не мог бы тюнингом выправить.
По Altium.
Сейчас они дают скачать некий обрезанный тулс с названием Altium Designer DEVELOP. По сути тот же десктопный Altium. Но API не видно нигде
Мне скачало бесплатно потому что я и так имею лицензию. Правда старую и не дающую право на обновление. И это сам по себе момент интересный.
Причиной ошибки стали
отсуствие нормоконтроля и подписи на чертежах (сарказм)
За перевернутый футпринт и монтаж WQFN проволочками сразу лойс!
Расстановка компонентов и трассировка платы пока выполняются вручную. Для этих этапов я не нашёл подходящего применения ИИ
А как же quilter? Даже есть бесплатные прогоны. Правда там получается ну очень инопланетная расстановка компонентов и нормально это работает только для 4-слоек с очень низкой плотностью, но всё же
Скрытый текст
Для автоматического проектирования электроники не нужны нейросети! Запишите передаточную функцию и задайте точность, и этого будет достаточно чтобы автоматически всё сгенерировать, окололинейным алгоритмом.
Выбор микроконтроллера Artery AT32F435 странный. Если основной критерий мощность, то есть много популярных вариантов: esp32 s3, esp32 p4, STM32H7, teensy. Мне кажется брать мало популярный контроллер крайне плохо и это сильно усложнит разработку.
Угадала ли нейросеть с выбором?
Статья о том, что выбор микроконтроллера на сегодня вообще никак не влияет на сложность разработки.
Сложность разработки может быть повысит выбор модулей типа teensy. Потому что они хуже документированы и тестированы и вносят свой слой косяков разработчиков модулей. Для AI модули затрудняют анализ схемотехники.
esp32 p4 и других подходящих esp не было в продаже на LCSC. А STM32 гораздо дороже.
Я уверен что Claude сделал оптимальный выбор, даже с учетом его косяка с анализом гибкости настроек SPI.
Скоростная разработка электроники