Схема в ворде

Схема в ворде

Текстовый редактор Microsoft Word содержит все необходимые средства для создания схем непосредственно в самих документах. Основными инструментами для создания схем в Ворде являются векторные фигуры и объекты SmartArt. С их помощью при минимальном количестве настроек и затрат времени вы можете создавать схемы практически любой сложности и адаптировать их в соответствие с потребностями и задачами, которые решает создаваемый документ. Рассмотрим использование указанных инструментов на примерах.

Как сделать схему в Ворде с помощью объектов SmartArt
Объекты SmartArt идеально подходят для построения небольших типовых логических схем. Чтобы с их помощью сделать схему в Ворде выполните следующие шаги.

  1. Откройте документ, в котором вы будете создавать схему и перейдите в раздел Вставка в главном меню текстового редактора.
    раздел Вставка
  2. Сделайте двойной щелчок мышью по кнопке SmartArt и в открывшемся окне выберите подходящий для схемы шаблон. Нами для примера выбран иерархический блочный список. Нажмите кнопку Ок для вставки шаблона на страницу.
    выбор шаблона схемы
  3. Отредактируем шаблон, чтобы он соответствовал запланированной схеме и добавим блокам подписи. Для этого нажмите кнопку с надписью Область текста из вкладки Конструктор или просто сделайте щелчок левой кнопкой мыши по области схемы.
    редактирование шаблона
  4. Появится окно в котором можно редактировать схему как текстовый список, изменяя структуру за счет многоуровневой организации списка и добавлять надписи к блокам, которыми станут строки списка.
    иерархическая блок-схема
    Для начала приведем структуру схемы к задуманной. В результате нам нужно будет создать следующую схему.
    создаваемая схема
  5. Удалите в списке все строки кроме первой. При этом останется на схеме останется только первый начальный блок.
    редактирование схемы
  6. Используя переводы строк клавишей Enter и изменение уровней вложенности списка клавишей Tab видоизменим список в соответствие с нашей целью. Чтобы было понятней для себя можно запомнить, что сочетание клавиш Enter+Tab будет добавлять блоки в вертикальном направлении, а клавиша Enter – в горизонтальном. В результате изменений получим следующий шаблон.
    видоизмененный шаблон
  7. Остается только добавить надписи и получить готовую схему. При необходимости можно всегда изменить цветовой шаблон всей схемы и провести тонкую настройку параметров входящих в нее фигур таких как заливка, цвета линий, характеристики теней, форм и поворот фигуры и др.
    добавление подписей к блокам
    изменение цветовой схемы

Создавать схемы в Ворде с помощью объектов SmartArt очень быстро и просто. Но при этом можно столкнуться с ограниченностью доступных шаблонов, что не даст вам создать схему, отличающуюся от типовой. Именно поэтому существует другой способ создания схем с помощью векторных фигур.
Как создать схему в Ворде с помощью фигур
О том, как создавать схемы в Word с помощью векторных фигур мы рассказывали на страницах нашего сайта в соответствующей статье. Повторяться не будем и предлагаем вам ознакомиться с материалами статьи как нарисовать схему в Ворде, в которой достаточно подробно рассмотрен пример работы с фигурами и приведены необходимые иллюстрации.

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

Как разрабатывать электронные схемы

Самый эффективный метод — «сборка» нужной схемы из готовых и заранее отлаженных фрагмен­тов. Эта операция аналогична тому, как программисты «собирают» програм­мы из готовых и заранее отлаженных процедур. Каждая такая процедура есть «черный ящик», у которого есть входы и выходы для общения с другими час­тями программы, причем в общем случае вы даже не знаете, как она устроена внутри — точно так же, как вы не знаете, что именно размещается внутри микросхемы. Вы берете микросхему, подсоединяете к ней внешние элементы в соответствии с рекомендациями производителя и получаете готовый узел, который соединяете с другими подобными узлами.

Повторим, что именно на этой стадии можно сильно «залететь», если во­обще отказаться от попыток понять, как работают используемые узлы, и лишь тупо следовать рекомендациям производителя, которые по понятным причинам не исчерпывают всего разнообразия жизненных ситуаций. Лучше всего, если производитель предлагает не только описания компонентов (datasheets), но и рекомендации по их применению (application notes) — в этом случае их совсем не вредно изучить перед проектированием.

При рисовании схемы обязательно обозначайте на ней конкретные типы и зна­чения параметров элементов — не откладывайте это до выполнения практиче­ской отладки схемы. Изменить эти параметры вы всегда сможете, но все, что можно посчитать, нужно посчитать заранее — это сохранит вам очень много времени. Когда вы берете, наконец, паяльник в руки, то не следует сразу соби­рать всю схему устройства целиком. Разбейте ее на как можно более мелкие самостоятельно работающие узлы и отлаживайте каждый узел по отдельности. Не верьте печатному слову и все рекомендации из литературы проверяйте на макетах (в конце концов у вас образуется библиотека таких самостоятельно отлаженных узлов, и вы будете экономить огромное количество времени). От­ладив все, обязательно нанесите на чертеж схемы полученные в результате от­ладки точные значения компонентов (те, что все еще требуют окончательной подгонки, обозначаются звездочкой), проверьте правильность соединения этих узлов и разводку питания и только затем собирайте всю схему целиком — сна­чала на макетной плате. И только убедившись в работоспособности макета схемы, переносите ее на настоящую рабочую плату.

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

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

? разработка технического задания, с возможно более подробным описанием требуемой функциональности^;

? разработка принципиальной схемы с отладкой отдельных узлов на макетах;

? изготовление полного макета и его отладка;

? разработка окончательной принципиальной схемы, подбор деталей и раз­работка печатной платы;

? изготовление опытного образца и его отладка, корректировка печатной платы;

? изготовление окончательного варианта печатной платы, корпуса и мон­таж прибора.

Отдельно стоит упомянуть составление технического описания и инструкции по эксплуатации. Я знаю, что большинство разработчиков искренне ненави­дит этот этап работы (то же относится, увы, и к программистам), но советую себя пересилить и начинать составление документации прямо сразу, одно­временно с началом проектирования. Во-первых, при попытке описать сло­вами «как это работает» в расчете на стороннего читателя обычно всплыва­ют все недостатки и упущения. Иногда на примере некоторых изделий бытовой техники или пользовательских программ отчетливо видно, что их разработчики сами никогда и не пытались взглянуть на свое творение с точки зрения того, кто это будет применять на практике, а инструкцию по эксплуа­тации писали наспех совершенно другие люди. Вот этого и следует по воз­можности избегать. Во-вторых, с уверенностью можно сказать, что через пару лет вы напрочь забудете, как у вас работал данный узел и почему выбраны именно такие компоненты. Поэтому написание технической документации нужно вам самим не меньше, чем пользователю.

Приведенный идеальный вариант последовательности разработки редко осуществим на практике — либо времени не хватает, либо денег, либо того и другого. Есть одна известная фирма, которая занимается разработкой заказ­ных электронных устройств — так там берут несколько килобаксов только за написание технического задания. И они правы! Но на практике часто получа­ется так, что макетный либо опытный образец становится и окончательным изделием. И все же по мере возможности не пренебрегайте этими промежу­точными этапами — поверьте, так получится намного быстрее, чем, зажму­рившись, собрать все сразу, а потом в лучшем случае обнаружить, что ничего не работает, а в худшем— выветривать из комнаты очень неприятный и стойкий запах горелой пластмассы. Учтите, что почти ни одна незнакомая дотоле схема никогда не работает сразу — будьте к этому готовы и заранее наберитесь терпения.

Итак, приступим.

Юрий Ревич revich@computerra.ru

Автор выражает благодарность Юрию Певзнеру за консультации и предо­ставленные тексты программ для микроконтроллеров семейства Atmel AVR.

Схемы, чертежи и фотографии компонентов подготовлены автором. Все остальные иллюстрации взяты из источников, допускающих свободное копи­рование, за исключением фотографии первого транзистора из главы 6 и порт­рета Клода Шеннона из главы 14, любезно предоставленных автору корпора­цией Lucent Technologies Inc./Bell Labs в лице ее сотрудницы Франциски Мэттьюз (Francisca Matthews).

Разработка электроники: от идеи до устройства


Сейчас намного проще найти финансирование для своего проекта, проводятся стартап-аллеи, краудфандинговые платформы пестрят новинками. Ардуино приблизило мечтателей к заветной славе. IoT технологии взяли свое и IT фирмы поняли, что не кодом единым можно жить. Не редкое явление, когда hardware проектом руководят люди, которые несколько далеки от электроники. И еще чаще они думают, что жизненный цикл software-проекта аналогичен жизненному циклу hardware-проекта. Увы, это не так.
Организация процесса разработки железа — очень важный момент. Ошибка на любом этапе может «вылезти боком» и цена может оказать непомерно высокой. При создании материального объекта нет возможности выпускать каждый день новую версию. Проектирование — самый сложный этап разработки и о нем далее пойдет речь.
Примечание 1: данный материал предназначен для людей, которые не знакомы с (реальной) разработкой, это студенты и преподаватели, стартаперы, IT-фирмы, программисты. Все изложенное — личный опыт и наблюдения. Если Вы инженер с опытом и Вам есть что добавить — пишите в комментарии.
Примечение 2: здесь речь идет о простом жизненном цикле, от идеи до железячки, но не до продажи. Почему так? Разной сложности проекты могут проходить очень многие этапы до продажи: поиск инвестора, если его нет, юридическая волокита, муляж, макет, устройство, отладка, разработки отладочных стендов (которые могут быть еще сложнее), сертификация, серийное устройство.
ПП — печатная плата;
ТЗ — техническое задание;
BOM — Bill Of Materials или перечень элементов.

Команда


Хорошая команда — неотъемлемая часть проекта. Поскольку приходится работать с разными людьми и вливаться в проекты на разных этапах, собственно затем и был описан «жизненный цикл hardware проекта». В электронике бывают разные специалисты: инженер-схемотехник, инженер-конструктор печатных плат, инженер-программист (низкий уровень, то есть микроконтроллеры, микропроцессоры, ПЛИСы), инженер-технолог, технический дизайнер, монтажник и руководитель технической части или технический директор. Есть такая категория, как Embedder это специалист, который рассчитывает схему, проектирует, программирует, паяет (и швец, и жнец, и на дуде игрец). Среди заказчиков нередко бытует мнение, что нужно нанять человека, который сделает все, но разделение труда лучшая позиция и не стоит все валить на одного человека, особенно, если речь идет о стартапе, когда нужно вписаться в сжатые временные рамки и проделать много работы.

//естественно по этому поводу начали спорить с коллегой. Мол у стартапов не много денег, но, по-моему, количество денег это уже забота не инженера или тех директора. Если хотите одного человека, то ему придется работать день и ночь, а за это нужно очень хорошо платить (дешевле брать ему помощников), кроме того, некоторое время такая работа может быть интересной, но потом может просто начаться выгорание. Специалист бросает все и уходит в закат, а у начальства горит и подгорает.

Не так давно меня спросили как же все таки формируется команда для проекта разной сложности. Собственно это зависит от очень многих факторов: временные рамки, финансовые ограничения, исходные данные (напр. предыдущие наработки), что нужно получить на выходе (муляж, макет, красивый макет, устройство, серийный вариант, etc) и от ведущего проекта. Для простого проекта, типа драйвера для некой светодиодной вещицы может хватить и одного ембедера (рассчитал схему, растрассировал, запаял, запрограммировал и в продакшн). Был медицинский проект с составом: ведущий, эмбедер для основного блока и блока передачи энергии, программист низкого уровня для работы с передачей информации, программист высокого уровня (ПО для ПК и телефона), около-инженеришка для мелкой работы (на тот далекий момент я) типа рисования библиотеки компонентов для САПР, документации, теор. расчеты, отдельный логист (он сам занимался закупками и контролем поставок), технолог и технический дизайнер. Но это с учетом того, что были предыдущие версии устройства, специалисты, которые их разрабатывали, дедлайны много раз передвигались, отладка и испытания на живых образцах (никто не пострадал). Работы было очень много, но никто не представлял на начальном этапе НАСКОЛЬКО много, хотя наработки и опыт был.
Для проекта носимых устройств мне хватает конструктора ПП, который и логистикой занимается, ембедер для расчетов и программирования, монтаж на фирме или частное лицо. Соответственно верхнее ПО/дизайн на себя берет заказчик (или по договору подыскивается человек).
Почему нет смысла валить все на одного человека/на себя любимого? Конечно, если целыми днями бьешь баклуши и у тебя один заказчик, которому сроки не горят, то делай. НО если проектов много и человек действительно ценит свое время и деньги, то рациональнее делегировать задачи другим. Например: я могу сама заняться программирование МК, но буду разбираться с этим дольше, чем инженер-программист (поскольку я лучше работаю с проектированием ПП) и я потеряю больше, чем получу, при нарушении сроков и штрафах (например) или могу вовсе потерять клиента.
В любом случае, думаю, что этот опыт формируется только в процессе работы. Так же интересно в комментариях услышать ваше мнение на этот счет.

Организационные моменты


Чтобы не было вот так ^, нужно четко и железно (как ни иронично) все распланировать.

  1. Составление ТЗ (общая концепция, функции, проработки потенциальных путей решения, сопоставление со сроками). Есть много шуток на тему «какое ТЗ — такое и решение», но лишний раз не стоит пренебречь напоминанием. Чем подробнее ТЗ, тем меньше сюрпризов будет возникать по ходу дела. Не обязательно разбираться в электронике, но более чем достаточно описать, что должно делать устройство, какие ориентировочные габариты, особые составляющие, бюджет, сроки. Если инженеры — отдельная команда, то можно оформить коммерческое предложение, где инженеры опишут ваше ТЗ с технической стороны (не бесплатно, конечно, потому что это уже серьезная работа):
    • метод реализации, например, это может быть полногабаритный макет с последующими доработками для создания опытного образца или сразу опытный образец (а такое тоже бывает, но не рекомендую);
    • выходная продукция (можно просто отдать работающее устройство, а можно и схемы/чертежи/сборочную документацию);
    • перечень задач обычно описывает жизненный цикл проекта;
    • технические требования к устройству;
    • расценки сроки и оплата.

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

  2. Разработка приблизительной концепции (картиночки для начальства/спонсоров). Чаще всего это на скорую руку подобранная элементная база и накиданная на печатную плату, чтобы получить 3D модель, примерить ее в корпус и обрадовать начальство. Но это только ориентировочная модель, в 90% случаев что-то может пойти не так (нет нужных размеров аккумулятора, например, или при трассировке просто не влазит в эти габариты и нужно буквально на пару мм увеличить, или все пошло слишком хорошо и плату можно уменьшить);
  3. Разработка диаграммы Ганта/расписания/дедлайнов. Один из важнейших моментов. Инженеру нужно оценить сроки и объем задач в комплексе. Есть промежуточные этапы демонстрации результатов, их тоже нужно оглашать, чтобы не было сюрпризов. Обязательно нужно закладывать риски. Например, один важный элемент едет из-за границы, заплатили за срочную доставку, но он где-то задержался. Кроме того, все мы знаем, что если дедлайна нет, то все это делается без всякого энтузиазма, вяло, долго и нудно;
  4. Утверждения поставленных задач с командой. Все расписано, составлено, еще раз просматриваем графики и задачи, обсуждаем спорные моменты, подписываем/не подписываем бумажки и начинаем работать.

Жизненный цикл разработки ПП

  1. Подбор элементной базы (какие компоненты будут закладываться). Анализируем цены, доступность и сроки поставки. Подбор выполняется в динамическом режиме вместе с созданием схемы. Выбор элементной базы проводится на основе схемы электрической принципиальной с учетом изложенных в ТЗ условий и требований;
  2. Прорисовка компонентов. Условно-графическое обозначение, посадочное место, 3D-модель, параметры — составляющие любого компонента. Разные инженеры по разному ведут свои библиотеки, некоторые пользуются готовыми. Для меня правило — дотошная прорисовка. 3D-модель компонента позволяет не только потом выкатить 3D-модель платы, но и проверить правильность посадочного места. Под разные технологии разные посадочные места. Разные параметры (пусть даже номинал просто отличается) — разные компоненты. Это упразняет море ошибок ручной правки;
  3. Создание схемы. Как есть правила написания читабельного кода, так есть правила создания читабельной схемы. Схему можно разделить на блоки, подписать их, расставить по пути протекания тока. Указать пины, которые можно свапать. Чем подробнее схема, тем меньше вопросов при трассировке. Если устройство состоит из нескольких печатных плат, то намного удобнее каждую схему вести отдельно, но потом обязательно нужно создать сборочную схему с указанием как платы между собой соединяются. Впрочем, все это описано в стандартах;
  4. Утверждение схемы. Еще раз проверяем элементную базу, расчеты, даташиты. Лучше лишний раз потратить 5-15 минут, чем потом резать дорожки и паять бутерброды;
  5. Правки схемы по необходимости. Внесли правки, утвердили и уже на этом этапе можно выкатить BOM (перечень элементов) и заказать ключевые микросхемы, которые наверняка меняться не будут. Мелочевка (резисторы/конденсаторы/диоды etc) может меняться;
  6. Трассировка печатной платы. При необходимости корректируется схема и элементная база. Это довольно творческий процесс, можно трассировать, трассировать, а потом забить и начать все заново. Про автотрассировщики мнение неоднозначное, все делают как считают нужным. Так же при трассировке важно учитывать и технологию производства печатной платы, потому как если я знаю, что буду делать там, где качество не блещет, то не стану делать сверхтонкие дорожки и маленькие переходные;
  7. Утверждение растрассированной ПП;
  8. Выдача 3D-модели ПП. Честно, все заказчики любят модельки, это беспроигрышный вариант, если дедлайн на подходе. Кроме того отдаем модель нашим дизайнерам и они подгоняют корпус или ворчат и просят тебя что-то изменить;
  9. Подготовка гербер-файлов для изготовления печатной платы. На производство лучше всего отправлять именно гербера. Во-первых, если вы отправите просто *.pcbdoc, то по нему можно сделать реверс инжиниринг. Во-вторых, в этом случае производитель не несет ответственности за то, как они подготовят гербера, то есть, если вы отдали *.pcbdoc и они при «конвертации» случайно удалили какой-нибудь полигон/компонент, то не их вина. Не ленитесь, подготавливайте гербера, проверяйте их в специальных программах. Особенно важно сопоставить вместе со сверловкой;
  10. Подготовка документации. Стандартный комплект документации: перечень элементов, спецификация, чертеж, топология, монтажная документация. Ее можно делать по ГОСТу, по зарубежным стандартам или по своему собственному. Если же делаете по-своему, то лучше придерживаться унификации, проще будет разобраться.
    • Перечень элементов нужен как для закупки, так и для монтажника (в основном достаточно туда вывести designator, component name, package, quantity, по наличию/желанию value, marking). Маркировку указывают не все, но это упрощает работу монтажнику, ему не приходится думать 30KOm это 303 или 304? Полнота документации наше все;
    • Спецификация — все составные части, входящие в изделие, здесь также отмечена входящая в данное изделие документация: сборочный чертеж печатной платы, схема электрическая принципиальная, перечень элементов;
    • Чертеж — это может быть габаритный чертеж или сборочный. Он может пригодится для проверки ПП после производства или для доработки купленного корпуса;
    • Топология — нужна для проверки платы. Если плата маленькая или на ней много компонентов, то лучше всего проверить все ли правильно, не ошибся ли где-то производитель;
    • Монтажная документация — контурное изображение изделия, а также данные, необходимые для его установки (монтажа) на месте применения. В состав входит: контур печатной платы, топология, изображение компонентов (вид сверху), маркировка, обозначение, иногда вид сбоку или в разрезе, если монтаж сложный. Не забываем про ключи на компонентах, это тоже очень важно, чтобы потом монтажник не устраивал истерики. Ушла как-то моя еще первая плата на монтаж с моей первой документацией и тут залетает в КБ тетенька с криком «Где тут плюс и минут у диода?». Или заказчик сам все припаял, пожаловался что ничего не работает, прислал фотографию, а контроллер-то он не так припаял.

  11. Утверждение документации

Написание программы нижнего уровня

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

  1. Анализ требований;
  2. Разработка алгоритмов (создание логики работы программы);
  3. Написание исходного кода;
  4. Компиляция;
  5. Тестирование и отладка (очень много отладки);
  6. Документация.

Стоит добавить, что все таки разработка ПО нижнего уровня и ПО верхнего уровня отличаются, поскольку все очень и очень зависит от железа. Непропаи, качество платы, компонентов, фаза луны, да что угодно могут повлиять на корректность работы программы, именно потому инженер-программист таки инженер, ему так же приходится помимо постукивания по клавиатуре тыкать паяльником в плату.

Серьезно, полоскайте своего программиста, как хотите, но он должен вести документацию. Ему вдруг предложили более лакомое место или переехал велосипедист — все. Разбираться в чужом коде, без комментариев, без алгоритма — невыносимая боль, проще писать все с нуля (а это время и деньги).
Программист, помни про карму, сдашь проект без комментиков и сам однажды в такой же попадешь!

Производство

Организация производства тоже немаловажная часть, особенно, если у вас нет своего цеха. На все про все (организацию, не само производство) лучше выделить ~месяц, далее объясняем почему.
Когда появилась утвержденная схема, пора браться за покупку компонентов, поскольку не все бывает в наличии. Пока плата не растрассирована, есть возможность без проблем внести изменения. Компоненты лучше закупать у официальных поставщиков и дистрибьюторов. Конечно, вы можете закупить в Китае, но если это китайский Китай, то половина микросхем может быть бракованная. То же касается и покупки на сайтах частных объявлений.
Поставщиков много, если у одного светодиоды стоят дешевле, то не значит, что у него все дешевле (да, есть люди, которые так думают, для них и замечание). Эффективнее всего сводить цены и сроки разных поставщиков в таблице. Закупать лучше с запасом 20-30% (была ситуация с транзисторами 0402, которые купили впритык по количеству, а при пайке их феном посдувало).

Также есть нюансы с поставками, например, требовался модуль, он есть только в Китае, нам необходимо всего пару десятков, но поставщикам не выгодно его везти (особенно в таком количестве), потому что они потратят слишком большую сумму на получение специальных документов. Потому заказывали обычной почтой, сроки там сильно плавают. Недавние грабли научили еще вот чему: держите руку на пульсе, звоните своему поставщику каждые 3-5 дней, потому что чаще всего они сами и не уведомят о том, что возникли проблемы. Товар едет из Англии, обещали 5-9 рабочих дней. Прошло две недели, окей, после долгого смущения и попыток оправдаться, оказалось, что на момент заказа товара на складе не было (хотя говорили, что все в наличии, все ок) и он только выехал и будет еще через неделю, а уже нужно запускать производство. Цирковые-поставщики.
Когда плата растрассирована, проверена, то оформляем гербер-файлы и отправляем в производство. Но, тут тоже подводный камень, на производствах обычно есть очередь.
Производители бывают разные, есть те, кто делает долго и качественно, а есть те, кто быстро и не очень качественно, но для небольшой партии макета подойдет. Все допускают ошибки, заказали платы на лучшем предприятии, все по фен-шую, но тут они приходят и на месте центрального пада одной из микрух (барабанная дробь) маркировка (шелкография). Был один вопрос: как? Сроки позволяли и нам их переделали, но в следующий раз они вообще умудрились один из полигонов удалить. Бывают разные ситуации, все риски не учесть, но стоит быть к ним готовыми.
Монтаж. Если партии большие, то есть смысл заказывать автоматизированный монтаж или если эти платы не один раз будут запускаться в производство. В любом другом случае — ручной монтаж. Предприятия берутся за мелкие партии очень неохотно, потому что это скорее убыточно.
Если ищем самостоятельно монтажников, то лучше заранее спросить чем паяет, о сложных корпусах (например, транзисторы в корпусе 0402 или LGA-14), показать монтажку (убедиться, что человек действительно в нее будет смотреть, а то один раз припаяли два вертикально и близко расположенных резистора горизонтально).
Тут еще следует упомянуть, что иногда вопрос о способе монтажа может подняться на этапе трассировки. Например, есть компонент в корпусе SOT-23, но в библиотеке для этого корпуса два посадочных места — обычное и от NXP; для микросхем посадочные могут быть с задним и передним миниском.

Отладка

Это крайне специфический этап. Порой для отладки нужно собирать целые стенды, которые дороже устройства. Еще может быть такое, что от способа отладки может зависеть концепция платы, например: устройство состоит из 3 плат и раньше отлаживали каждую отдельно, а потом все в куче, но начальство предложило вообще все 3 платы делать одним куском, а потом их разламывать. В таком случае устройство для отладки одно, но нужно тогда потратить время уже на три платы и новый стенд, это оказалось не выгодно (просто потому что тогда нужна была модификация только одной платы).
Если в ходе отладки были выявлены ошибки, их лучше всего задокументировать, чтобы впредь не наступать на те же грабли.
Почему все таки лучше начинает проект с макета, а не разрабатывать сразу опытное устройство/серийное? Потому что в случае второго невозможно сразу сказать дело в качестве платы, элементной базе или в пайке.
И не забываем об использовании блоков питания.

Разработка железа это долго, дорого, сложно, но очень-очень интересно, писать об этом можно еще и еще. Главное не забывать фразу «Делай хорошо, плохо получится само».
В планах так же написать статьи о схемотехнике (от идеи до схемы, с чего вообще начинать, как делать расчеты, что нужно знать и понимать? То есть, для новичков), трассировке (прорисовка компонентов, сложные посадочные места, лайфхаки, туториал по САПР), пайке и граблях с масштабированием производства, если вам, конечно, интересно.

Всех с праздничками и наступающими рабочими буднями!


Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *