Об инженерном подходе замолвлю я слово
Привет, Хабр
Этим расслабленным воскресным вечером мне бы хотелось поговорить на две темы, отчасти взаимосвязанные — о том, что такое и как вообще выглядит инженерный подход в разработке электроники, а также как и зачем писать на Хабр статьи про эту электронику так, чтобы они были приятны и понятны всем.
Навела меня на эту мысль фраза в сегодняшней статье — «Под катом многабукав, но будет инженерненько»; к сожалению, не только под катом не было инженерненько, но и вообще в очень большом проценте статей по теме «как я сделал девайс», публикуемых в последнее время на Хабре, нет ничего инженерного.
Почему?
Потому, что у любого инженера — как и у программиста, врача, юриста и вообще любого профессионала — есть базовая методология работы, без соблюдения которой деятельность из профессиональной превращается в бессистемные метания. Точнее, даже не методология — к методологии мы можем отнести аджайл, ТРИЗ и вот это вот всё, оно у каждого своё —, а грубая стратегия, которую можно записать в несколько шагов.
Итак, что же это применительно к электронике?
1) Формирование задачи — или, говоря формальнее, постановка технического задания.
На первом этапе мы формулируем, что и зачем мы вообще хотим получить, а также граничные условия, которые мы хотим соблюсти.
Я не буду даже трогать GPS-трекеры, работа GPS-модуля, время его выхода на режим захвата координат и т.п. — штуки довольно сложные и зависящие от многого (отмечу только, что любой минимально современный GPS-модуль имеет как минимум четыре режима работы, с потреблением 20–30 мА, 2–3 мА, 200–300 мкА и < 10 мкА, не считая полного отключения).
Возьмём более простую вещь — акселерометр. Вот, например, три совершенно реальные задачи, решавшиеся на дешёвом MEMS-акселерометре ST LIS3DH:
- датчик угла наклона — отслеживание угла наклона столба освещения
- датчик физической активности и падения — отслеживание фактов свободного падения, а также оценка физической активности носителя
- датчик вибрации — отслеживание спектра вибрации 0,1…100 Гц
Во всех трёх случаях — устройства на батарейном питании, которые мы хотим оптимизировать по энергопотреблению.
Смотрим даташит акселерометра:
- сон — 0,5 мкА
- 1 Гц — 2 мкА
- 25 Гц — 6 мкА
- 1344 Гц — 185 мкА
Очевидно, что наши три задачи потребуют трёх разных режимов работы — в первой для столба даже 1 Гц крайне избыточен, столб обычно никуда не торопится, а ремонтная бригада не торопится тем более. Во второй вполне адекватен оказывается режим со скоростью порядка 25 Гц, а в третьем, очевидно, неплохо бы иметь 10-кратное превышение частоты сэмплирования над частотой измеряемого сигнала.
Более того, в случае столба 1 Гц настолько избыточен, что наиболее эффективным вариантом оказывается вообще ручной опрос акселерометра. Допустим, наш микроконтроллер для такого опроса просыпается раз в 15 минут (это мы согласовали с заказчиком, его такая задержка информации о собирающемся упасть столбе устраивает — всё едино туда бригада не раньше чем часа через два приедет), вся процедура занимает 100 мс, а контроллер при этом потребляет 5 мА — среднее энергопотребление активного режима контроллера оказывается равным 5×0,1/15/60 = 0,55 мкА, что в сочетании с 0,5 мкА спящего акселерометра оказывается примерно вдвое выгоднее, чем акселерометр, молотящий сам на 1 Гц и будящий контроллер только при превышении порогового значения.
На самом деле, то, что я описываю сейчас — это уже по сути третий этап в методологии подхода к разработке, сейчас он призван проиллюстрировать, насколько важно заранее поставить задачу.
Вы делаете GPS-трекер? Отлично. Вы его делаете для кого? Для пешехода, у которого он должен лежать в кармане, весить 50 г и жить на аккумуляторе сутки? Для железнодорожного вагона, где он должен жить пять лет, зато и весить хоть пять кило? Для коровы на свободном выпасе, на которой он живёт на батарейке те же пять лет (потому что больше не живёт корова), зато весить должен максимум 35 г, потому что крепится ей на ухо?
Это всё — совершенно разные задачи.
И чётко проговорить, что именно вы делаете и каковы граничные условия, при попадании в которые задача может считаться решённой, надо заранее.
Собственно, уже на этом этапе у большинства DIY-проектов — чёрная дыра: автор делает что-то совершенно непонятно зачем. Иногда честно пишет — «чтобы потренироваться паять», но чаще всего различные абстрактные — без ТЗ они всегда будут абстрактными — вещи типа «добиться минимального энергопотребления процессора, одновременно забив на энергопотребление всего остального» оказываются самоцелью.
Взять ту же вышеупоминаемую статью — автор устройства гонится за единицами микроампер потребления, коммутируя отдельными транзисторами питание акселерометра (меньше 2 мкА в спячке) и GPS (7–8 мкА в battery backup mode). Оно правда надо? Вот передо мной прямо сейчас лежит модуль электроники для «умной каски» (там тоже есть GPS-трекер), у него требуемое время эксплуатации на одной зарядке с запасом получается при среднем по больнице потреблении 5 мА (миллиампер), вы правда думаете, что плюс-минус десяток микроампер тут имеет какое-то значение? А если нет, то к чему на и без того вполне плотную плату пихать лишние детали?
2) Подбор компонентов
После того, как вы определились с граничными условиями — начинается второй этап, в котором вы выбираете, из чего вы будете делать ваше устройство.
Задача, на самом деле, не очень простая, т.к. у каждого компонента есть куча параметров, таких как:
- электрические параметры
- занимаемое на плате место
- сложность и стоимость монтажа
- стоимость самого компонента
- доступность в продаже
Возьмём даже те же задачи с акселерометром — ну ок, в умной каске вас однозначно устроит LIS3DH за полдоллара, катушками лежащий в Компэле. А на измерении отклонения столба? А с какой точностью клиент хочет это отклонение измерять? Всё ещё дешёвый 12-битный LIS3DH, чуть более дорогой 16-битный LIS2HH или уже топовый ADXL355 стоимостью в полтинник баксов и с доставкой две недели? Тут мы возвращаемся к граничным условиям п. 1 и начинаем считать, считать, считать.
А это был всего лишь акселерометр. А представьте, какое разнообразие творится на рынке, например, экранов. Понятно, что все любят WH1602 (хотя лично я больше люблю WEH001602), но вот вы сходу ответите, что поставить в какой-нибудь водосчётчик, которому 6–8 лет работать на одной батарейке, при этом непрерывно показывая кубометры?
Собственно, каждый компонент в схеме должен быть обоснован — у разработчика либо должно быть понимание, почему компонент именно такой, либо же понимание, что в данном случае всё равно какой (ну, например, резисторы обычно более-менее всё равно какие ставить, хотя и тут бывают нюансы).
И всё это взаимосвязано. Например, тот же выбор элемента питания — LiMnO2 с напряжением 2,0…3,0 В, LiSOCl2 с напряжением 2,4…3,6 В или вообще перезаряжаемый аккумулятор с его 3,0…4,2 В? А компоненты у вас от чего работать могут? А от чего они будут работать эффективнее или экономичнее? А пиковые токи нагрузки выбранный элемент потянет? А если это LiSOCl2, то с учётом пассивации всё равно потянет? DC/DC повышающий хотите поставить, а когда не надо — выключать? А выбранный чип load disconnect-то вообще умеет, или у него выключение — это ШИМ остановить, а на выходе при этом оказывается входное? А опасность перегрева есть, а то может вам вообще в 1,5-вольтовые LiFeS2, у которых теплового саморазгона нет, податься?
И вот так по кругу несколько раз — смена одних компонентов тянет за собой другие, третьи…
Вы думаете, те же GPS-модули — они все одинаковые? Вот у меня в той же «умной каске» в рамках согласованных с заказчиком габаритов и в рамках имеющегося в продаже и удовлетворяющего требованиям аккумулятора компоненты придётся ставить на стороне платы, прилегающей к корпусу, и имеющей ввиду этого ограничение по высоте оных компонентов что-то около 1,5 мм. Теперь возьмите в руки ближайший GPS-модуль и измерьте, сколько у него высота корпуса.
Ага. Именно. Ну, можно пересогласовать габариты и сделать корпус на 1 мм толще, а можно и привычный Quectel L76 сменить на новенький EVA M8M с его 7×7×1,1 мм.
Что мы видим в вышеупомянутой статье? Автор не знает, зачем именно он делает GPS-трекер, поэтому ставит в него первый попавшийся GPS-модуль, про рабочие режимы которого он не знает и узнавать особо не хочет, в связи с чем ради энергосбережения (нужного тоже не очень понятно зачем) просто рубит ему всё питание.
То есть — провал в формировании задачи ведёт к провалу в выборе компонентов.
3) Изготовление прототипа изделия
Ну, здесь, наверное, останавливаться сильно не на чем — после выбора компонентов делается финальная схема, плата, собираются прототипы. С этим у DIY всё обычно более-менее хорошо, а тот факт, что синяя изолента и разноцветные провода постепенно сменяются кастомными платами, можно только приветствовать.
4) Оптимизация режимов работы компонентов
Несмотря на все ваши усилия, предыдущие этапы оставят отдельные белые пятна — во многих случаях у вас всегда останется место для тонкой подстройки работы компонентов (GPS здесь, кстати, хороший пример — с ними можно долго играться с настройкой режимов неактивности с целью минимизации энергопотребления при обеспечении заданной достоверности координат). Многие нюансы выяснить по даташитам либо трудно, либо невозможно вообще — производители часто не указывают слишком детализированные данные или взаимосвязи между различными параметрами.
Поэтому после изготовления прототипа, который, по вашим предварительным прикидкам, должен попадать в требования ТЗ, наступает этап его оптимизации.
Есть, например, классический пример — энергопотребление процессора как функция от его скорости. Да, чем больше мегагерц — тем больше миллиампер. Но ведь и тем быстрее процессор выполнит задачу и снова уйдёт в сон! Но при этом задача может частично зависеть от скорости внешних интерфейсов, которые одинаково работают что на 1 МГц, что на 64 МГц. При этом вывод процессора на 64 МГц может занять больше времени, чем вывод его на 4 МГц (запуск и стабилизация кварцевого резонатора, запуск и стабилизация PLL, перенастройка режимов тактирования), и в результате от включения до выключения одна и та же задача в первом случае съест больше микроампер-секунд, чем во втором!
Здесь, конечно, часто не стоит слишком увлекаться — если вы с хорошим запасом попадаете в граничные условия ТЗ, то смысла тратить время на оптимизацию мало; ну, как в той вышеупомянутой «умной каске», у которой при среднем потреблении 5 мА экономить единицы и даже десятки микроампер смысла просто нет, это погрешность, а не экономия.
На этом же этапе могут проверяться и различные предположения — например, автор статьи про GPS-трекер предположил, что устройства с высоким потреблением будут более экономичны, если их питать меньшим напряжением. На практике же это не всегда так — если модуль имеет в составе импульсный преобразователь, то он в любом случае потребляет постоянную мощность, а значит, при снижении напряжения увеличит потребляемый ток.
В результате общее потребление схемы, в которой добавился ещё один понижающий преобразователь, а то ещё и цепи согласования уровней, только вырастет.
5) Экспериментальное доказательство оптимального решения задачи
Последний этап (который, впрочем, частично может выполняться на предпоследнем) — это экспериментальное доказательство того, что устройство сделано правильно и оптимально.
Во-первых, стоит ещё раз взглянуть — не обнаружились ли в процессе прототипирования и отладки ненужные детали. Оверинжиниринг, при котором устройство получает много лишнего, вообще весьма характерен для DIY-проектов — взять, например, недавнюю статью про сенсорный выключатель, автор которой, имея под рукой мощнейший микроконтроллер, сделал датчики касания на отдельных чипах, а потом ещё и не смог удержать энергопотребление получившегося в сколь-нибудь приемлемых рамках. Ну или бытующее среди ардуинщиков поверие, что для «защиты от помех» выход микроконтроллера и затвор транзистора, управляющего реле, надо разделять оптопарой.
Впрочем, в этих случаях критический осмотр своих проектов авторам никак бы не помог — у них с очевидностью острая нехватка базовых знаний, позволяющих решить задачу оптимальным способом, а не наворачивая дополнительные компоненты с не очень понятной им самим функциональностью. Тем не менее, пройтись взглядом по схеме и подумать, не оказалось ли на ней что-то в итоге не сильно нужным — сигналы, дорожки, компоненты — стоит.
Во-вторых, необходимо понять, действительно ли устройство удовлетворяет граничным условиям ТЗ, а если нет — или даже если его параметры просто не вписываются в ваши представления о том, какими они должны быть — то почему (да, я специально выделил жирным: грош цена тому разработчику, который, получив энергопотребление 40 мкА вместо расчётных 5–10 мкА, не может объяснить, почему).
Случаев «ну всем понятно, что в даташите написано 10 мкА, а в реальности-то меньше 100 мкА не получится» в природе не бывает. Либо в даташите вполне конкретная ошибка, нолик, например, не пропечатался, либо вы чего-то не понимаете. Будем честны, вероятность, что вы с такой ошибкой столкнётесь, довольно невелика в профессиональной деятельности и практически равна нулю в DIY-проектах, это один случай на многие тысячи компонентов и, как правило, в каких-то экзотических режимах их работы — поэтому, если параметры вашего устройства сильно и объективно не совпадают с тем, что вы посчитали на салфетке по даташиту, это значит, что вы чего-то не понимаете.
Примеров этому в том же вопросе энергопотребления я видел массу — оставленные в воздухе цифровые входы, невыключенная периферия процессора, забытые подтяжки к питанию… Но я не помню ни одного случая, когда в итоге оказалось бы, что «в реальности-то и правда не получится», и потребление не удалось бы либо привести к расчётному, либо скорректировать расчёты с учётом явно указанных в даташитах, но по ошибке не учтённых ранее факторов.
Исследование таких вопросов обычно бывает достаточно нетривиальным, но оно необходимо. Если ваши расчёты не сходятся с вашими измерениями — значит, либо в тех, либо в других вы ошиблись, а ошибки надо исправлять.
Так про что же статьи-то писать?
Ну и в заключение — про что же писать на Хабр так, чтобы к вам не было претензий у профессионалов, которых мы считаем здесь значительной частью аудитории.
По сути, те статьи по проектированию электроники, которые я регулярно вижу, попадают в одну из групп:
- информационный мусор, дублирующий первую страницу выдачи гугля
- жизнеописание «как я провёл выходные»
- руководство по тому, как сделать себе какое-то устройство
- разбор неочевидных большинству тонкостей
Хороший пример последнего — например, свежая статья Аппаратный bit banding CortexM3/M4. Содержание таких статей — это не обязательно научное открытие, но в любом случае достаточно подробный для практического применения разбор информации, неизвестной большинству людей. Такие статьи бывают разной сложности и разной специфичности, но их все объединяет то, что самостоятельно информацию из них вы бы, конечно, рано или поздно нарыли бы, но потратили на это время, сильно превышающее время чтения статьи.
Диаметральная противоположность им — это статьи «как помигать светодиодом с помощью мультивибратора». Не то чтобы в них была изложена неверная или ненужная информация, но если всю ту же информацию можно получить практически из любой ссылки с первой страницы выдачи гугля по соответствующему запросу — то ценность такой статьи в общем-то нулевая. Это мусор, статья ради статьи.
Возможны, однако, и статьи, которые полезны, но при этом не содержат принципиально новой информации — это руководства по тому, как сделать себе какое-то устройство, основанное на личном опыте автора. Как правило, это сравнительно несложные вещи (сложные, проходящие весь описанный выше путь проектирования, появляются в виде статей «как мы делали» и по сути быстро распадаются на перечисление возникших в процессе неочевидных большинству тонкостей, попадая в соответствующую категорию), а информация, которая даётся в статьях, необходима и достаточна для самостоятельного повторения и дальнейшего развития читателями устройства. Это схемы, прошивки, пояснения, почему устройство сделано именно таким и каким вообще его можно сделать.
Наконец, статья-жизнеописание —, а в эту категорию из упомянутых попадают и сенсорная кнопка, и GPS-трекер — самый загадочный для меня жанр. Их авторы пишут много — иногда очень много — букв, обильно сопровождаемых картинками, но посторонний человек не может извлечь из них ничего для себя полезного. Авторы никак не обосновывают выбираемые ими решения, часто вообще не указывают, для чего они всё это делают, часто не приводят принципиальных схем или исходных кодов прошивок не то что целиком, но и хотя бы значимыми частями, не указывают на какие-либо специфические проблемы, возникшие в процессе и могущие быть интересными для окружающих («сначала я не умел паять SMD-компоненты, но со временем научился» не является проблемой, интересной для окружаюших).
Хотя такая статья чисто внешне выглядит глубокой технической работой, на деле это — школьное сочинение «как я провёл лето», малоинтересное кому-либо, кроме самого автора.
По возможности избегайте этого.
P.S. Так как в статье обязательно должны быть какие-то иллюстрации, приведу пример, за что не любят людей, утверждающих, что картинка из Fritzing — это и есть полноценная электрическая схема:
Попробуйте понять, что вообще происходит на этом рисунке.
