Насколько надежны примечания к применению

Мой последний вопрос привел обсуждение некоторых замечаний по применению и (плохой) практики. См. Комментарии под различными ответами.

До сих пор я думал: «Хорошо, эти примечания к применению написаны электриками, работающими в некоторых крупных компаниях, которые, вероятно, знают, что они делают».

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

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

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

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

12 голосов | спросил 4 revs, 3 users 65%
PetPaulsen
1 Jam1000000amThu, 01 Jan 1970 03:00:00 +030070 1970, 03:00:00

4 ответа


15

Спроси Олина :-) - но наденьте пламя.

В отличие от листов данных, которые ДОЛЖНЫ быть святым письмом (но часто это не совсем понятно), заметки по применению - очень «смешанная сумка». Он не платит, чтобы просто взять то, что находится в AN, как Евангелие, хотя вы бы надеялись, что он был, по крайней мере, полезен без волшебного дыма.

Следующее - мнение (конечно).
 люди с большим удовольствием предлагают контрапункт любой оценки, которую я делаю.

Код: . Когда дело доходит до образца кода, который поставляется с AN, вы можете ожидать, что он «немного поспешил», если он был написан специально для AN и, возможно, более высокого качества если он основывается на существующих приложениях и библиотеках. Олин, который гораздо более компетентен говорить об этом, чем я, скажет вам, что код MOST AN низок или опасен. Бывает, что компания Olin - это лучшие представители Microchip, и Олин - это своего рода перфекционист, которого вы хотите как своего разработчика и не хотите, как своего босса ;-). т.е. вы, вероятно, можете слегка рассказать об AN-коде, который Olin, но прислушайтесь к его советам.

Аппаратное обеспечение: Что касается аппаратного обеспечения, вы можете надеяться, что автор AN был высоко компетентным. Если AN относится к эталонному дизайну, который они предлагают использовать в качестве основы для коммерческого продукта, тогда вы также надеетесь, что они наделили его лучших людей. НО, если вы сделаете много микросхем, и вы хотите предложить способы, которыми люди могут использовать ВАШ продукт, тогда вы можете ожидать, что «мальчик» напишет хотя бы некоторые из них. Так что будьте проницательны - посмотрите, что предлагается, и будьте готовы найти некоторых bloopers.

Chip bloat: множитель, который я снова вспомнил сегодня вечером, когда смотрю на заметку о приложении TI, заключается в том, что существует тенденция «почистить лилию» - использовать многие ИС, где меньше всего может быть. Любой мог подумать, что у них есть что-то вроде заинтересованность в том, чтобы заставить IC в обращении, или что-то в этом роде.

Writer репутация очень важна - это одно место, где «призыв к власти» имеет некоторые достоинства. Если бы Джим Уильямс написал это, доверьтесь ему. Недавно Джим умер, и слишком многие другие классически доверчивые имена пошли одинаково.

Компания репутация считается несколько.

LT обычно хороши. Главным образом с Джимом виноват.

AD /Аналоговые устройства обычно очень хорошие.

NatSemi - это немного смешанная сумка с большим количеством пользы, но ничего определенного.

Microchip делает отличные продукты, но скорее склоняется к тому, чтобы отличать заметки приложения.

Burr Brown, как правило, являются хранителями Святого Грааля [tm}, но, будучи приобретены TI, имя может использоваться по-другому.

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

Zetex (приобретенный Diodes Inc) делает отличные отличные части (отлично!), но, как известно, пишет менее совершенные заметки о приложениях.

Nichia обычно не пишет заметки о приложении, но если бы они это сделали, вы могли бы создать их.

Luxeon /Lumileds /Ghost of Philips прошёл писать превосходные технические примечания для светодиодов. LLP понимает светодиоды, в отличие от практически любых других на рынке, и может использоваться для развития вашей базы знаний при просмотре других продуктов.

Atmel /AVR: Должны придерживаться цифровых данных, которые они знают очень хорошо. На самом деле, как правило, очень хорошо - использование диодов тела в качестве детектора с нулевым скрещиванием соответствовало мгновенному безумию.

Hewlett Packard: техническая новинка Old School HP была совершенно совершенно превосходной. Насквозь. Novo Riche HP, если они производят заметки о приложении, следует относиться с осторожностью. Проходите с другой стороны, если сомневаетесь. Agilent несет большую часть мантии старого HP и может в значительной степени доверять.

Motorola старых не так уж плохо. На полу следовало довольно хорошо. Возможно, также отделили детей.

...

ответил WhatRoughBeast 6 J0000006Europe/Moscow 2017, 01:27:58
9

Мое решение с заметками приложения: Просто игнорируйте их . Подумайте о них как Электроника для чайников , слишком часто написанных манекенами.

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

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

Конечная истина в техническом описании. Если вы знаете, что делаете, в приложениях нет необходимости. В лучшем случае они ничего не испортили. Если вы не знаете, что делаете, вы не должны нести ответственность за дизайн. Я полагаю, заметки приложения могут быть дополнительным материалом, помогающим демистифицировать вещи, но лучше всего рассматривать их как написанные манекенами для манекенов, потому что слишком много.

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

Даже «большие имена» могут иметь плохие дни. Давным-давно, в 1980 году, когда я был новым инженером, не работающим в Hewlett Packard, мне настоятельно рекомендовал старший инженер использовать новое напряжение для преобразователя частоты в National Semiconductor в моем дизайне. Старший инженер сказал, что эта часть была разработана этим парнем Бобом Пейзом, который должен был стать своего рода аналоговым богом-полупроводником. Поэтому я внимательно прочитал техническое описание и приложение, написанное Бобом Пейзом об использовании этой части для создания A /D высокого разрешения. Техническое описание имело смысл, но примечание к приложению серьезно предполагало, что вы можете сделать 22 бит A /D с этой штукой. Схема в примечании к приложению имела очевидные источники ошибок, превышающие 1/4 части в миллионе. Я думал, что должен что-то недопонимать, поэтому я сделал математику и достаточно тщательно доказал свое дело, чтобы показать старшего инженера. Он посмотрел на него и согласился со мной, и любезность засмеялась, сказав «Да, BoB Pease, похоже, в последнее время представляет собой свободную пушку, я думаю, что National пытается немного покорить его». . Это удивило меня, что он был настолько терпим и не более расстроен тем, что я считал неправым. Затем он сказал, что «Это просто приложение, так или иначе, оно по-прежнему выглядит как хорошая часть» . Именно тогда я понял, что примечания к приложениям написаны небрежно и не предназначены для принятия более чем случайно.

ответил WhatRoughBeast 6 J0000006Europe/Moscow 2017, 01:27:58
5

Хотя совершенно верно, что многие примечания к приложениям имеют низкое качество или сомнительную заслугу, написанные неопытными инженерами (я использую этот термин свободно), пытаясь просто продавать продукт, есть еще история.

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

Когда вы строите схему из примечания к приложению, маловероятно, что ваши детали и методы будут идентичны тем, которые используются инженером приложения. Нечто простое, как использование печатной платы с разной толщиной, может вызвать проблемы. Рассмотрим случай простого осциллятора, если он использовал конденсатор, покрытый плюсом или минус 10%, и он был на высокой стороне, а ваш на низком уровне, возможно, что именно эта разница может означать, что один не может колебаться или колебаться на гармонике, а не на основной частоте.

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

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

ответил WhatRoughBeast 6 J0000006Europe/Moscow 2017, 01:27:58
3

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

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

ответил WhatRoughBeast 6 J0000006Europe/Moscow 2017, 01:27:58

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132