Комментарии 67
У меня проекты небольшие, поэтому проверяю сам. 3Д тоже нет.
Из того, что делаю обязательно перед отдачей платы на производство — распечатываю сторону компонентов в масштабе 1:1 с проводниками на бумаге и тупо пинцетом устанавливаю на нее все компоненты.
Очень помогает проверить футпринты и если компоненты мешают друг-другу.
Из того, что делаю обязательно перед отдачей платы на производство — распечатываю сторону компонентов в масштабе 1:1 с проводниками на бумаге и тупо пинцетом устанавливаю на нее все компоненты.
Очень помогает проверить футпринты и если компоненты мешают друг-другу.
Расклейка на бумагу более информативна, тк позволяет посмотреть, как куда подлезать инструментом, прокладывать кабель и тд. особенно, если присутствуют всякие штуки типа micro-usb, которые трудно рисовать с высокой точностью.
На сложные детали можно посмотреть модели у производителя. Сейчас даже «китайцы» их начали поставлять.
Чаще всего рисовать самому ничего не надо, какой-нибудь добрый человек уже всё нарисовал и выложил, только качай
www.3dcontentcentral.com
grabcad.com/library
Если же нужной модели нигде нет — стоит потратить на неё время, заодно навык прокачать. А потом тоже поделиться с сообществом.
www.3dcontentcentral.com
grabcad.com/library
Если же нужной модели нигде нет — стоит потратить на неё время, заодно навык прокачать. А потом тоже поделиться с сообществом.
То ж понятно, но, например, этап с бумагой отлично сработал, когда схемотехник (я) выдал перечень элементов снабженцу (мне) и он (то есть я) закупил все компоненты, а когда начал устанавливать их на бумаге, оказалось, что футпринты не совпадают. Те же SOPXX, или не помню какой тип, бывают разные — чуть, чуть шире, чуть чуть уже и на 3D модели фиг заметишь разницу, а компоненты сейчас обзываются чем-то вроде 74AC245NHBDTAMK — и тут легко проморгать разницу при заказе.
И это со мной, а если это два разных человека, то ошибка может возникнуть и 3D модель тут не поможет.
И это со мной, а если это два разных человека, то ошибка может возникнуть и 3D модель тут не поможет.
Смысл в дополнительной возможности проверки, абсолютной гарантии, конечно, нет даже с использованием 3D. Однако видно всё замечательно, любой сдвиг и несимметрия сразу бросаются в глаза.
Интересно, и кого же потом больше ругал шеф (Вы)? Подозреваю, премии лишили всех :)
Для того, чтобы снабженец не ошибся, партномер должен содержать все буквы, обозначающие корпус.
Это хорошо и правильно, но не всегда оно есть лучшая альтернатива распечатке на бумаге (скорее дополняют друг друга).
Не всегда оправданно тратить на 3Д-модели время. Распечатка на бумаге и проверка занимают всего несколько минут.
В 3Д-модели можно тоже ошибиться. Например, сделать с небольшим смещением отверстия в радиаторе на плату, IGBT-модуле или в чём-то ещё достаточно крупном. На модели это не будет бросаться в глаза. Даже несколько проверяющих влёгкую пропускают иные баги. Иногда всплывают несоответствия чертежам размеры уже закупленных реальных деталей (сторонние модули, корпуса, например). Бумажка бывает очень быстрым и халявным дебаггером.
Мир несовершенен, люди тоже, нам часто приходится это учитывать)))
Не всегда оправданно тратить на 3Д-модели время. Распечатка на бумаге и проверка занимают всего несколько минут.
В 3Д-модели можно тоже ошибиться. Например, сделать с небольшим смещением отверстия в радиаторе на плату, IGBT-модуле или в чём-то ещё достаточно крупном. На модели это не будет бросаться в глаза. Даже несколько проверяющих влёгкую пропускают иные баги. Иногда всплывают несоответствия чертежам размеры уже закупленных реальных деталей (сторонние модули, корпуса, например). Бумажка бывает очень быстрым и халявным дебаггером.
Мир несовершенен, люди тоже, нам часто приходится это учитывать)))
А если делать футпринты с 3d моделями, не надо будет потом на бумаге расставлять.«Помогает проверить футпринты», если Вы ошиблись с футпринтом (взяли не тот, или ошиблись с размерами при создании) — поставив на него реальный компонент ошибка обнаружится наглядно.
Я обычно делаю так:
— схема оформляется как гибрид схемы и блок-схемы — удобно проверять и трассировать; схема сделана — сразу проверили; только после этого трассировка.
— трассировка по блокам, потом компоновка, вычищение всех мелочей, день перерыва, свежим взглядом проверка и тогда проверяет коллега.
— проверка компонентов (соответствие УГО футпринту и шагу между ножек).
— вывод герберов и проверка по ним.
Вот честно, никогда никаких траблов не было кроме шага между ножками и шириной корпуса. Например, SOIC есть узкий и широкий (а называются они одинаково) или QFN с шагом 0.5 и 0.65.
— схема оформляется как гибрид схемы и блок-схемы — удобно проверять и трассировать; схема сделана — сразу проверили; только после этого трассировка.
— трассировка по блокам, потом компоновка, вычищение всех мелочей, день перерыва, свежим взглядом проверка и тогда проверяет коллега.
— проверка компонентов (соответствие УГО футпринту и шагу между ножек).
— вывод герберов и проверка по ним.
Вот честно, никогда никаких траблов не было кроме шага между ножками и шириной корпуса. Например, SOIC есть узкий и широкий (а называются они одинаково) или QFN с шагом 0.5 и 0.65.
— схема оформляется как гибрид схемы и блок-схемы — удобно проверять и трассировать; схема сделана — сразу проверили;Вы имеете в виду иерархические схемы с первым листом в виде блоков?
— трассировка по блокам, потом компоновка,Почему не сначала компоновка, потом трассировка?
— вывод герберов и проверка по ним.Что и как проверяете по герберам?
Много ли разных устройств делаете?
Вы имеете в виду иерархические схемы с первым листом в виде блоков?Проще на примере (блок — рамочка вокруг группы компонентов, с подписью функционального назначения блока). Схема читается слева направо, сверху вниз, все входы слева, выходы справа. 1й блок разъем питания, 2й блок преобразование 12В в 6В, 3й блок — 12В в 5В (очень условно). Блок с МК, блок с драйверами, блок с разъемами под моторы, например. Если в друг что-то случится с командой, то любой новый человек легко поймет что происходит =)
Почему не сначала компоновка, потом трассировка?Часто есть рекомендуемая топология, сначала опираюсь на нее, потом корректирую в зависимости от габаритов и технологических требований.
Что и как проверяете по герберам?Просматриваю на наличие лишних перегибов, как пролились полигоны, отверстия, маску (некоторые отверстия закрываю маской, некоторые нет), в принципе. Ну и плюс, правильность формирования герберов. Давно конечно, но было, что не совпали гербера и сверловка. Или что выводили гербера без меня, а овальные почему-то не вывелись (у альтиума они отдельно от круглых).
Много ли разных устройств делаете?
Много, самые разные (бытовая электроника, носимая, лед, мед, неразрушающий контроль, иот), мелкие и крупные партии, местное производство, Китай и Европа =)
Я несколько лет назад работал программистом в институте, где разрабатывали микроэлектронику. Воркфлоу был примерно такой — программисты писали модель проектируемых модулей на Haskell, потом железячники реализовывали ее на Verilog, записывали в FPGA вместе с процессором LEON (свободный Spark-совместимый) и снова отдавали нам, что бы мы писали тесты (начали на C, но быстро перешли на ассемблер). Иногда к FPGA в соседнем отделе разрабатывали плату с дополнительным железом, например I2S. И с этими платами постоянно возникали проблемы, типа перепутанной полярности RESET. Программистов это очень расстраивало, и мы думали как бы статическую типизацию из Haskell прикрутить к описанию платы. Такого рода ошибки легко бы обнаружились. Но до реализации идеи руки так и не дошли.
Могу только позавидовать вашей удаче! Если у вас появятся коллеги — как будете контролировать качество? САПР проверяет очень поверхностно, к сожалению.
Статья как раз о системном подходе. К сожалению (или к счастью), опытных и не ошибающихся инженеров нельзя заказать сразу пяток, с доставкой в офис. Они получаются из неопытных, путём совершения ошибок. Иногда — очень дорогих ошибок.
Проверяя чужую работу и давая пояснения Рецензент учится сам. А перечень — просто способ упорядочить процесс, облегчить передачу знаний. И немного сэкономить на переделках.
Проверяя чужую работу и давая пояснения Рецензент учится сам. А перечень — просто способ упорядочить процесс, облегчить передачу знаний. И немного сэкономить на переделках.
Вы или очень везучий, или очень талантливый человек! Я как ни стараюсь, даже понимая что личные деньги уходят на производство платы, окончательная версия только к третей плате созревает. Я даже с этим смирился…
Возможно 50-60 часов в неделю дают результат, потому как у меня получается 3-5 плат в год разводить, на большее число проектов времени не хватает.
Возможно 50-60 часов в неделю дают результат, потому как у меня получается 3-5 плат в год разводить, на большее число проектов времени не хватает.
У меня вся беда в том, что редко случаются проекты с узлами, которые можно дернуть из предыдущих проектов. А еще моя головная боль — Оркад 9.2, принятый за стандарт на нашей конторе. Там DRC просто вообще никакой.
Для остальных проектов использую Kicad — вот там ошибок на порядок меньше. Главным образом схемотехнические косяки. А по платам — только в плане размещения компонентов бывает. С виду вроде все хорошо, а по факту SMD конденсатор чтобы поменять нужно разъем снимать.
И да, почти всегда для аналоговых схем провожу моделирование а LTSpice. Он почему то больше всех приглянулся. Даже если работа схемы кажется очевидной, все равно моделирую. Вылазят интересные моменты по поводу устойчивости работы.
Для остальных проектов использую Kicad — вот там ошибок на порядок меньше. Главным образом схемотехнические косяки. А по платам — только в плане размещения компонентов бывает. С виду вроде все хорошо, а по факту SMD конденсатор чтобы поменять нужно разъем снимать.
И да, почти всегда для аналоговых схем провожу моделирование а LTSpice. Он почему то больше всех приглянулся. Даже если работа схемы кажется очевидной, все равно моделирую. Вылазят интересные моменты по поводу устойчивости работы.
Интересно было-бы почитать о том как отлаживать готовую плату.
Берешь плату, берешь план тестирования, берешь подготовленные тесты (ПО и т.д.), берешь нужное оборудование. Идешь последовательно по плану. Если что-то не работает как ожидалось — первым делом осматриваешь визуально плату на случай некачественной сборки. Далее смотришь схему на наличие явных проблем. Потом вооружаешься тестером/осциллографом/спектроанализатором и пытаешься найти корень проблемы. Все очень индивидуально в зависимости от устройства, интерфейса и т.п.
В общем, да, nerudo описал верно. У нас отладка новых плат начинается без софта — проверяются питания, соответствие диапазонов требованиям ТЗ, а затем, если у программиста что-то не поднимается — начинается совместное творчество. Самое интересное — локализация ошибок и выдвижение гипотез, тут вряд ли можно дать готовый план. У нас многие проекты совместные, когда заказчик проектирует свою часть(СВЧ), а мы — свою(управление и питание) — отладка крайне увлекательна, я вам доложу.
Был свидетелем классической ошибки, доведенной до эпичности. Две больших сложных платы, стыкуются специальными многорядными разъемами через которые тащатся скоростные параллельные интерфейсы. Когда все изготовили, собрали и включили выяснилось что входы включены на входы, а выходы на выходы. Поскольку сигналы разъемов назывались *_in и *_out, но один разработчик имел system-centric, а другой board-centric взгляд на устройство. Ну а тщательно готовить и читать документацию никто не хотел.
Ну и как-бы провода на картинках намекают не столько на проверку схем и плат, сколько на проверку схемотехнических решений, прежде чем рисовать свою схему с ними. То есть перед тем, как применять микросхему или модуль в своей схеме, посмотри на reference design, и если твой вариант применения хоть чуть-чуть от него отличается — не ленись, закажи пару семплов, или даже отладочную плату, проверь, поэкспериментируй, спаяй прототип на коленке, сделай демо и только потом переноси в свою схему.
Во первых стоимость ошибки по мере рисования и разводки платы возрастает многократно и все эти эволюционные платы и затраты на прототипирование будут стоить копейки на фоне последующего исправления косяков, а во-вторых всегда будет иметься в наличии референтная рабочая схема, с которой можно будет потом сравнить и проконсультироваться, если что-то не работает на своей плате. Без нее поиск ошибок иногда приводит к танцам с бубном и беганью по форумам.
Во первых стоимость ошибки по мере рисования и разводки платы возрастает многократно и все эти эволюционные платы и затраты на прототипирование будут стоить копейки на фоне последующего исправления косяков, а во-вторых всегда будет иметься в наличии референтная рабочая схема, с которой можно будет потом сравнить и проконсультироваться, если что-то не работает на своей плате. Без нее поиск ошибок иногда приводит к танцам с бубном и беганью по форумам.
А не проще подключи питания и пусть плата сделает диагностику сама на каждый блок верифицирует, по возможности можно отрубить отдельно чтоб не кушал питание при выходе из строя. Ведь схема то всеравно отлажена и плата грамотно проработана и компонент лежит на своем посадочном месте
Как говорит народная конструкторская мудрость «Сколько в первую плату не смотри, а косяки всегда найдутся»
Не страшно, если какую то цепь не провел, хуже когда с футпринтом ошибся, например графический компонент под DIP8, а присоединил SO-16 (микросхема бывает в двух корпусах).
Графический компонент нарисовал в одно время, а плату разводил через неделю, и корпус выбирал по распространенности в продаже.
А статья отличная! Все четко систематизировано. Автору большое спасибо.
Не страшно, если какую то цепь не провел, хуже когда с футпринтом ошибся, например графический компонент под DIP8, а присоединил SO-16 (микросхема бывает в двух корпусах).
Графический компонент нарисовал в одно время, а плату разводил через неделю, и корпус выбирал по распространенности в продаже.
А статья отличная! Все четко систематизировано. Автору большое спасибо.
И это все равно не спасет от ситуации, когда ставишь, например, силовой драйвер, потом начинаешь отлаживать, а он греется как сковородка на частотах ШИМ даже в 10 раз ниже разрешенных по ДШ. Начинаешь гуглить — ан нет, норм, у всех греется. Грустно вздыхаешь и идёшь перепроектировать с нормальным драйвером. Реальность — лучший проверяющий. Все равно версии 1.1.2 будут и никуда от них не деться
Сейчас для «тренировки» делаю так:
1) Всю схему моделирую в FPGA. Постоянно проверяю на наличие глитчей и прочего из-за асинхронных частей схемы;
2) Как модель ALL-IN-FPGA отлажена, выношу основные компоненты (память, интерфейсы) на макетную плату, подключаемую к FPGA и продолжаю отлаживать с реальными таймингами этих частей;
3) И только после этого рисую схему по проекту из FPGA, по которой потом рисуется и плата.
Но у меня и проекты не сильно-то и большие — укладываются в 2к ALM, на мелкой логике и старых процессорах получается около 100 корпусов. Сейчас, например, моделирую ретро-компьютер Орион-128, сейчас уже на этапе 2, часть схемы уже на этапе 3 (видео-подсистема, с выходом на VGA, с поддержкой 4-х видеорежимов (по разрешению, и ещё 8 по цветности).
1) Всю схему моделирую в FPGA. Постоянно проверяю на наличие глитчей и прочего из-за асинхронных частей схемы;
2) Как модель ALL-IN-FPGA отлажена, выношу основные компоненты (память, интерфейсы) на макетную плату, подключаемую к FPGA и продолжаю отлаживать с реальными таймингами этих частей;
3) И только после этого рисую схему по проекту из FPGA, по которой потом рисуется и плата.
Но у меня и проекты не сильно-то и большие — укладываются в 2к ALM, на мелкой логике и старых процессорах получается около 100 корпусов. Сейчас, например, моделирую ретро-компьютер Орион-128, сейчас уже на этапе 2, часть схемы уже на этапе 3 (видео-подсистема, с выходом на VGA, с поддержкой 4-х видеорежимов (по разрешению, и ещё 8 по цветности).
Пару лет назад начальник отдела обещал премию тому разработчику, у кого уже после запуска платы в производство не всплывет какого-либо «нюанса». До сих пор никто не получил…
Когда делала свою вторую в жизни плату, сделала ее зеркальной. Вот обидно то было, столько времени потрачено. А ведь предварительно распечатала на бумажке, разложила все детальки и радуюсь, что удачно получилось. Раскладывать то надо было на зеркальной копии, а я под утюг и в продакшон.
В общих чертах: ERC, DRC, DFM + много опыта по личной сборке и наладке устройств.
Если что-то сложное, то блок-схема в yEd с уточнением интерфейсов и связей.
В схемах — проверенные макро блоки и предварительные консультации с программистами, смогут ли они сделать так, как я планирую.
Какие-то новые не совсем понятные схемы — макеты и отладки с доработками под себя.
Если что-то есть для того же LTSpice'а, то в нём, но и на старуху, как оказалось…
Если компоненты от TI — то обязательно изучение всех вопросов по компоненту в их e2e форуме. А то была чудесная микруха преобразователь pcie-4xUSB3 у которой в даташите и апноуте одно, в эррате чуток другое и на прямой вопрос техасу, дык, делать как в апноуте или эррате, был ответ вида «ну если у вас не работает, то сделайте как в эррате».
В плате после интенсивной трассировки и вылизывания денёк перерыва, потом свежий взгляд, потом зациклить до получения правильного результата.
После этого вывод в герберы и уже изучение герберов на предмет правильного вывода всего и вся. Не помню, где именно когда-то прочитал: «тополог не должен перекладывать на плечи инженера завода свои проблемы». Т.е. если в САПР правила настроены на 4 класс, а по герберам вдруг в некоторых местах получается 5-й, то нельзя лениться, надо корректировать.
Когда работал с коллегами, просил их рисовать блок-схемы будущих устройств. После создания схемы, перед трассировкой, проверяли друг у друга, но это тоже не панацея. Ну и топологию потом так же смотрели.
С механикой по-хорошему надо сначала компоновать, отдавать механику 3d, потом править и так до бесконечности. И только потом трассировка. Но чаще получается в виде «вот тебе объем, тут и тут у нас винты, размещай всё вот здесь». Особенно порадовало на новой работе делать односторонние платы из-за особенностей изделий.
Чтобы не было путаницы в компонентах — все посадочные именуются по IPC. Все УГО называются с учетом конкретного корпуса (это чтобы выводы не попутать). Фактически, один компонент, одно УГО, одно посадочное.
Как правило это помогает со второй итерации получить работоспособное устройство.
А вообще, как показала практика, гарантия хорошей работы почти без ошибок — это стабильная ситуация с зарплатой, отсутствие нервяков и постоянного дерганья. И тогда «состояние потока» проходит с очень большой пользой.
Если что-то сложное, то блок-схема в yEd с уточнением интерфейсов и связей.
В схемах — проверенные макро блоки и предварительные консультации с программистами, смогут ли они сделать так, как я планирую.
Какие-то новые не совсем понятные схемы — макеты и отладки с доработками под себя.
Если что-то есть для того же LTSpice'а, то в нём, но и на старуху, как оказалось…
Если компоненты от TI — то обязательно изучение всех вопросов по компоненту в их e2e форуме. А то была чудесная микруха преобразователь pcie-4xUSB3 у которой в даташите и апноуте одно, в эррате чуток другое и на прямой вопрос техасу, дык, делать как в апноуте или эррате, был ответ вида «ну если у вас не работает, то сделайте как в эррате».
В плате после интенсивной трассировки и вылизывания денёк перерыва, потом свежий взгляд, потом зациклить до получения правильного результата.
После этого вывод в герберы и уже изучение герберов на предмет правильного вывода всего и вся. Не помню, где именно когда-то прочитал: «тополог не должен перекладывать на плечи инженера завода свои проблемы». Т.е. если в САПР правила настроены на 4 класс, а по герберам вдруг в некоторых местах получается 5-й, то нельзя лениться, надо корректировать.
Когда работал с коллегами, просил их рисовать блок-схемы будущих устройств. После создания схемы, перед трассировкой, проверяли друг у друга, но это тоже не панацея. Ну и топологию потом так же смотрели.
С механикой по-хорошему надо сначала компоновать, отдавать механику 3d, потом править и так до бесконечности. И только потом трассировка. Но чаще получается в виде «вот тебе объем, тут и тут у нас винты, размещай всё вот здесь». Особенно порадовало на новой работе делать односторонние платы из-за особенностей изделий.
Чтобы не было путаницы в компонентах — все посадочные именуются по IPC. Все УГО называются с учетом конкретного корпуса (это чтобы выводы не попутать). Фактически, один компонент, одно УГО, одно посадочное.
Как правило это помогает со второй итерации получить работоспособное устройство.
А вообще, как показала практика, гарантия хорошей работы почти без ошибок — это стабильная ситуация с зарплатой, отсутствие нервяков и постоянного дерганья. И тогда «состояние потока» проходит с очень большой пользой.
Выделять TI как особый случай я бы не стал, это общая практика.
Верно подмечено! Жаль, что жизнь вносит свои корективы и подёргивать — таки приходится иногда.
Напишите, пожалуйста, подробнее о DFM
отсутствие нервяков и постоянного дерганья. И тогда «состояние потока» проходит с очень большой пользой
Верно подмечено! Жаль, что жизнь вносит свои корективы и подёргивать — таки приходится иногда.
Напишите, пожалуйста, подробнее о DFM
Т.е. если в САПР правила настроены на 4 класс, а по герберам вдруг в некоторых местах получается 5-й, то нельзя лениться, надо корректировать.Не подскажете подходящий инструмент для такого анализа?
Фактически, один компонент, одно УГО, одно посадочное.
Вот кстати, я как на фирме работала, так отвечала за всю библиотеку. Когда каждый инженер ведет свою, друг другу проект футболят, то такая каша. Особенно улыбало, когда у компонента вручную правят параметры.
У меня каждый номинал — отдельный компонент, даже в резисторах/кондерах. Исключаем по максимуму человеческий фактор.
Создание электрических схем и трассировка печатных плат становятся всё более простыми делами.
Распространение такого мнения не может не пугать. «Копипаст решения от производителя» и «разработка уникального устройства» — немного разные по сути задачи.
Так что фразу следует читать так: «сегодня все больше задач получают готовые решения, которые достаточно всего лишь аккуратно скопировать».
А как вы проверяете свои платы?
Поскольку у меня не стоит задача разрабатывать триста шестьдесят пять устройств в год (решения в основном штучно-специального плана), я даю каждому проекту «вылежаться» дня три перед тем, как отправлять его в производство, даже если к концу всех проверок непосредственно после окончания трассировки стопроцентно уверен, что ошибок нет. Далее снова проверяю плату. Если мне все еще кажется, что ошибок нет, то отправляю ее в производство.
А так все стандартно — DRC, ERC, проверка соответствия платы схеме, проверка электрического соединения цепей, ручная проверка топологии.
Так что фразу следует читать так: «сегодня все больше задач получают готовые решения, которые достаточно всего лишь аккуратно скопировать».
Всё верно, это и имелось в виду. Для большинства задач в промышленной/потребительской электронике этого достаточно.
Вы в одиночку делаете штучно-специальное?
В некотором смысле да. Мной «усиливают» в плане разработки электроники команду, состоящую из специалистов в предметной области (физиология/физика). Они понимают, что нужно сделать, а я — как. :) Разумеется, разработкой занимаюсь не я один; кроме меня есть конструкторы механики, это отдельные люди; при необходимости к нам присоединяются программисты Android и т.д. Но схемы/платы/прошивки электроники на мне.
Да, забыл сказать. Я тоже практикую распечатывание на бумаге макета платы в размере 1:1 и примерку критичных (или тех, которые использую впервые) компонентов. Выглядит не супер-профессионально, зато такой способ, при своей простоте, может сэкономить деньги на перезаказе плат. :)
Да, забыл сказать. Я тоже практикую распечатывание на бумаге макета платы в размере 1:1 и примерку критичных (или тех, которые использую впервые) компонентов. Выглядит не супер-профессионально, зато такой способ, при своей простоте, может сэкономить деньги на перезаказе плат. :)
Поскольку часто при проверке таких вещей мозг упускает 1 из 20-30 пунктов я для себя составил список проверок, такой как бы человеческий DRC, такой же как в САПР, но составленный в том числе из правил которые нельзя или сложно заскриптовать в DRC САПР.
1) Проверка удовлетворения системными решениями
— Требований ТЗ
— Параметров выбранных электронных компонентов, влияющих на требуемые в ТЗ характеристики
— Удовлетворяемости системы и ее составляющих условиям эксплуатации
— Соображений целесообразности
— Соображений экономичности и выгоды
— Удовлетворения себестоимости
— Общих правил проектирования электронных систем
2) Проверка схемы
— Проверка наличия всех названий и каких-либо комментариев на схеме
— Проверка соответствия подписей выводов их номерам
— Проверка правильности установленных типов выводов (Input, Output PushPull, Opendrain, HiZ, Analog, etc...)
— Проверка проводниковых соединений всех УГО между собой согласно их даташитам и согласно ТЗ
— Проверка на непреднамеренные соединения, недосоединения и КЗ
— Проверка удовлетворения рабочих параметров элементов после соединения их между собой
— Проверка удовлетворения ограничений рассеяния мощности из даташитов компонентов
— Проверка согласования импедансов если нужно
3) Проверка платы
— Общая проверка DRC по выбранным нормам завода-изготовителя
— Проверка коллизии компонентов
— Проверка на баланс термосопротивлений паяемых площадок компонентов
— Проверка на способность окружающей обстановки (полигонов, радиаторов, корпуса и т.д.) теплорассеивающих элементов эффективно рассеивать их тепло согласно данным даташита
— Проверка контура платы на наличие участков неоптимальной формы, либо легколомких участков
— Проверка правильности заливки полигонами платы
— Проверка правильности разводки земель
— Проверка согласования импедансов если нужно
— Проверка выравнивания высокоскоростных цепей если нужно
— Проверка целостности сигналов (если необходимо — SI симуляция) и качества разводки сигнальных цепей
— Проверка целостности питания и качества разводки шин питания
— Проверка возможности монтажа и удовлетворения правилам монтажа выбранного изготовителя
— Проверка эргономичности расположения управляющих и электроустановочных элементов
— Проверка возможности порчи легкоплавких частей компонентов при запайке рядом с ними компонентов с тугоплавким припоем с высокой температурой
Кажется, ничего не упустил. Берите, нахаляву.
1) Проверка удовлетворения системными решениями
— Требований ТЗ
— Параметров выбранных электронных компонентов, влияющих на требуемые в ТЗ характеристики
— Удовлетворяемости системы и ее составляющих условиям эксплуатации
— Соображений целесообразности
— Соображений экономичности и выгоды
— Удовлетворения себестоимости
— Общих правил проектирования электронных систем
2) Проверка схемы
— Проверка наличия всех названий и каких-либо комментариев на схеме
— Проверка соответствия подписей выводов их номерам
— Проверка правильности установленных типов выводов (Input, Output PushPull, Opendrain, HiZ, Analog, etc...)
— Проверка проводниковых соединений всех УГО между собой согласно их даташитам и согласно ТЗ
— Проверка на непреднамеренные соединения, недосоединения и КЗ
— Проверка удовлетворения рабочих параметров элементов после соединения их между собой
— Проверка удовлетворения ограничений рассеяния мощности из даташитов компонентов
— Проверка согласования импедансов если нужно
3) Проверка платы
— Общая проверка DRC по выбранным нормам завода-изготовителя
— Проверка коллизии компонентов
— Проверка на баланс термосопротивлений паяемых площадок компонентов
— Проверка на способность окружающей обстановки (полигонов, радиаторов, корпуса и т.д.) теплорассеивающих элементов эффективно рассеивать их тепло согласно данным даташита
— Проверка контура платы на наличие участков неоптимальной формы, либо легколомких участков
— Проверка правильности заливки полигонами платы
— Проверка правильности разводки земель
— Проверка согласования импедансов если нужно
— Проверка выравнивания высокоскоростных цепей если нужно
— Проверка целостности сигналов (если необходимо — SI симуляция) и качества разводки сигнальных цепей
— Проверка целостности питания и качества разводки шин питания
— Проверка возможности монтажа и удовлетворения правилам монтажа выбранного изготовителя
— Проверка эргономичности расположения управляющих и электроустановочных элементов
— Проверка возможности порчи легкоплавких частей компонентов при запайке рядом с ними компонентов с тугоплавким припоем с высокой температурой
Кажется, ничего не упустил. Берите, нахаляву.
Спасибо! А что вы проектируете, если не секрет?
Все что угодно, в данный момент работаю там где нужно заниматься поддержкой и модификацией встраиваемого ПО комплектов контроллера входа-выхода и бортового компьютера для управления гидроприводными системами устанавливаемыми на грузовиках и тракторах наподобие бульдозерного трала или мусоровозной камеры, всего что можно навесить на грузовик.
Тебе просто дают схему и печатку нарисованную в кореле или спринт лайотуе и тебе хочется всех убить.
В такие моменты не надо себя сдерживать
Я боюсь Брейвик тут ребенком покажется. А в наших тюрьмах интернеты не дают, даже ограниченно. А Я видел целые конструкторские отделы, работающие ТАК.
Ну надо менять работу тогда. Если же люди не задумывались о сохранении возможности сменить работу, или как то повлиять на текущий ход работы, то сочувствую, потому что довольно часто в начальстве (да и среди коллег) сидят люди которым пофиг на работников. То есть это эгоисты. Это означает необходимость каждодневного слежения и планирования жизни, куда входит и создание возможности смены работы/пассивного дохода и т.д. Просто потому что среди нас подлые эгоисты, для которых покушение на другого либо наплевательство на другого если он не имеет защиты — каждодневная привычка. Поэтому когда «хочется всех убить» — то значит, на вас кто-то наварился.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Доверяй и проверяй: подход к проверке схем и печатных плат