В этой статье хочу поделиться с вами своим опытом в разработке электронных устройств. Естественно, мой опыт не претендует на универсальность и подойдет далеко не всем.
Входной барьер для разработки электронных устройств высок, чаще всего это связано с образованием. Для разработки электронных устройств нужны техническое образование и особый творческий склад ума. Многие разработки придется делать в условиях сильной неопределенности и очень часто рисковать используя новые узлы, схемы или микросхемы. Первые прототипы будут гореть/взрываться/отказываться работать, но, вооружившись паяльником вы все исправите, со временем, или в следующей итерации. Не все в этой профессии задерживаются - уходят в программисты или менеджеры по продажам.
Для начала вам понадобится компьютер/ноутбук, желательно не старый. Опытный фулстек разработчик установит следующие среды разработки: Altium Designer, Компас-3D, IAR Workbench и бесплатный VisualStudio, узкоспециализированный или начинающий разработчик - только Altium Designer. Вышеперечисленные среды разработки стоят недешево и имеют более дешевые/дорогие аналоги, но чем более профессиональные инструменты вы используете для работы, тем дороже будете стоить на рынке труда. Также для расчетов рекомендую установить бесплатную математическую программу MathStudio.
И вот, наконец, вы получаете техническое задание на разработку электронного устройства от своего непосредственного руководителя или стороннего заказчика. Далее по тексту будем называть его заказчиком. Редко техническое задание представляет собой объемный труд, оформленный по ГОСТ со списком всех требований и чаще всего это страница оформленная в MS Word или google документах, для современных быстро изменчивых условий это нормально и с этим можно работать.
После получения технического задания НИКОГДА не озвучивайте - сроки и трудоемкость выполнения этого задания. Правильно оценить вы их не сможете - возьмите паузу на один-два дня. За это время разработайте концепт решения каждого пункта технического задания, функциональную схему устройства и план работ. Выясните важные для заказчика параметры. Например, для "летающих" устройств - это вес, для батарейных - время автономной работы и т.д. Важные параметры должны быть проработаны в концепте максимально детализировано. В план следует закладывать как минимум две итерации разработки. Вторая итерация нужна для исправления ошибок и добавления мелких правок от заказчика.
Когда вы будете готовы обсудите с заказчиком концепт решения, функциональную схему и план работ. Это очень важный этап разработки, который позволит синхронизировать ожидания заказчика и ваши возможности. Бывает и такое, что после этого заказчик перестает с вами выходить на связь или обращается к другому исполнителю. Это риск, но с этим придется жить и работать.
Всё. Сомнения ваши и заказчика развеяны, вы наполнены мыслями и рветесь в бой.
Для начала создадим структуру каталога нашего проекта. Необходимо позаботиться в самом начале о культуре наименований. Согласно моему 20-ти летнему опыту, наиболее оптимальная структура выглядит следующим образом:
Для фулстек разработчика рабочие пространства необходимо разделять: PCB (Altium Designer), Case (Компас-3D) и Software (IAR и Visual Studio), потому что при разработке конструкторской документации будут образовываться сложные взаимосвязи, в парадигме которых "ссылочные переменные" будут более предпочтительнее.
По предложенной структуре у каждого проекта Altium Designer есть трехзначное цифровое обозначение и краткое описание справа от него. В большинстве случаев диапазон от 000 до 999 охватят весь жизненный цикл разработчика и среднего предприятия. Версии проекта кодируются двухзначным числом после точки.
Не используйте русские буквы в структуре каталогов, потому что они не всегда корректно перевариваются некоторыми программами.
Такая структура позволяет иметь все версии плат под рукой (это удобно с точки зрения поддержки) и рабочий каталог не превращается в болото, когда "нормальные" названия плат заканчиваются.
Если разработчики работают в группе, очень хорошими практиками являются обязательное использование базы данных Access и встроенной в Altium Designer систему контроля версий SVN. Сторонние системы контроля версий лучше не использовать, потому что вы потеряете возможность сравнивать разные версии схем и плат в "человеческом" виде.
Для каждого проекта в Altium Designer требуются библиотеки электронных компонентов. Разработчики их создают самостоятельно из документации или скачивают из специализированных сайтов. Во избежание ошибок при добавлении нового компонента в библиотеку символ и посадочное место всегда нужно сверять с документацией этого компонента, будет очень обидно, если при монтаже обнаружится что микросхема не встает на посадочное место. Обязательно используйте детализированные 3D модели. При необходимости создавайте их самостоятельно в Компас-3D.
Чтобы закончить проект необходимо создать до 50 компонентов - это тяжелая работа, которую кто-то должен сделать, но есть способ этот этап пропустить, он называется Concord Pro.
Символы в библиотеке рекомендую всегда рисовать в шаге 100 mil, если вы не хотите переделывать внешние библиотеки при импорте в ваш проект.
Вполне достаточно у компонентов использовать поле Comment для отображения короткого обозначения компонента (Например, 10k, 0.1u и AXP202) и параметр BOM для вывода спецификации платы.
Используя широко известный в программирования принцип Don’t repeat yourself (DRY - «не повторяйся») проекты в Altium Designer делаем иерархическими и при необходимости многоканальными.
На первом листе схемы (файл Schematic.SchDoc) разместим формализованную функциональную блок-схему, по которому определяются функциональные блоки и взаимосвязи между ними. Она похожа на ту функциональную схему, которую вы делали для заказчика, но более детализированная и локализованная для Altium Designer.
Из эстетических соображений при выборе размеров блоков будем придерживаться правила "золотого сечения". Также ваши схемы будут чуть-чуть красивее если стороны прямоугольников УГО микросхем с небольшим количеством ножек будут подчиняться этому же правилу. "Внешние" разъемы также следует располагать на первом листе.
После завершения схемы она проверяется через Project » Compile PCB Project и передается в плату через кнопку Design » Update PCB Document.
На этом этапе фиксируется контур электронного устройства. Обычно контур создается в механическом CAD (например, в Компас-3D).
После этого начинается этап компоновки. Плата до разводки выглядит хаотично. Иногда, с особенно большими платами, из-за этого возникает депрессия и начинаешь подозревать в себе синдром "самозванца". В этом момент появляется желание проклясть себя и заказчика. Приходится заставлять себя раз за разом расставлять компоненты группируя их согласно их datasheet. Но постепенно, начинаешь втягиваться и все лучше себя чувствовать, а потом просто доходит до автоматизма.
Для окончательной проверки печатной платы создайте специальный проект MultiBoard, совмещая в нем все платы и корпус. На этом этапе можно выявить очень много досадных ошибок.
Сопровождающему проект конструктору полезным будет отправить 3D модель готовой платы на проверку, а программисту - схему в pdf, чтобы он проверил правильность RX/TX UART, SDA/SCL I2C, конфигурацию ножек микроконтроллера (например, в STM32 CUBE MX) и т.п.
Скриншоты 3D модели отправляйте заказчику. На данном этапе он еще может повлиять на получаемое устройство (цвет плат, расположение и распиновку соединителей, корпус и т.д.). Скрупулёзно запишите все замечания и комментария заказчика и по каждому пункту дайте ему свой обоснованный ответ: как будете исправлять или почему не будете исправлять. Нужно быть готовым к изменениям, часть правок нужно сделать сейчас, а более длительные правки оставить на следующую итерацию разработки.
Для выгрузки документации следует воспользоваться OutJob файлом.
В минимальный список документации входят: гербер файлы, монтажная схема (в Draftsman) и BOM. По этой документации любое контрактное производство возьмется за изготовление вашего электронного устройства. Для автоматизированного монтажа дополнительно понадобятся Pick & Place файлы.
По моему опыту, впервые разработанный прототип изготовить в количестве не более 3 штуки. На большее лучше не рассчитывать, потому что разработчик может исправить свои ошибки на не более 1-2 платах. При больших количествах плат разработчик начинает впадать в депрессию.
Лучшей практикой будет заказать комплектующие 3-х кратным запасом, а сложные микросхемы - с 10-ти кратным.
У большинства заказчиков появляется желание сэкономить на этом этапе и сделать ручной монтаж с помощью фена, паяльника и монтажницы. Не ведитесь, это ловушка! Статистика показывает, что 50 % плат после этого вообще не запускается, а остальные ведут себя по разному и с этим вам придется разбираться. Часто из-за этого первоначальная отладка затягивается, а терпение заказчика подходит к концу. Чтобы избежать этого настаивайте на трафарете и конвекционной пайке оплавлением в печи с соблюдением температурного профиля пайки. Всем от этого будет лучше, время - это самый ценный ресурс разработчика. Экономить надо время и в итоге деньги тоже будут в сохранности.
Во время первоначальной отладке все ошибки и как они исправлялись записывайте в confluence или google документ. Эти ошибки надо будет проанализировать, продумать как их не допускать в будущем, т.е. провести ретроспективу - это поможет вам стать лучшим разработчиком в своей области.
Фулстек разработчики на этом этапе не останавливаются и начинают писать программные обеспечения для микроконтроллера и компьютера для общения с устройством. Это довольно сложно, потому что может занять 10 раз больше времени чем разработка печатной платы, но я верю, что фулстек разработчик это сделает более качественно чем "чистый программист", потому что разработчик может досконально изучить регистры микроконтроллера и периферийных микросхем и выжать из них максимум полезных функций. "Чистые" программисты могут не обращать внимание на очевидные для разработчика вещи, например, на переходные процессы, и устройство может работать нестабильно.
Однако, "чистый" программист код пишет гораздо быстрее и его код легче поддерживать. Поэтому лучше избегать прямой конкуренции с ними, она будет не в вашу пользу.
Прототипы готовы, они работают как задумывалось и даже чуть лучше. Проводим демонстрацию работы прототипа перед заказчиком. Возможно, он попросит сделать это в "боевых" условиях. На это надо соглашаться, потому что на данном этапе проблемы и слабые места относительно безболезненно можно исправить.
Также запишите все замечания и комментария заказчика и по каждому дайте ответ. Это позволит вам поднять авторитет как профессионального разработчика и адекватного исполнителя.
Бывает, что прототип не удовлетворяет всем ожиданиям заказчика и он недоволен результатом. Тогда обсудите с ним следующую итерацию. Помните, что изменение требований приветствуется, даже на поздних стадиях разработки. Ведь цель разработки - произвести конкурентоспособный и нужный рынку продукт.
