Ситуация знакомая: прибор ведёт себя неправильно, схемотехник говорит «плата в порядке, смотрите программу», программист — «программа отрабатывает как написано, дайте нормальный сигнал». Оба показывают прогоны, где всё работает. Переписка идёт неделями, изделие всё это время стоит. Ниже — семь шагов, которые превращают такой спор в разбирательство с проверяемым результатом, и то, что стоит согласовать заранее, чтобы разбираться было проще.
Что мешает закрыть ошибку на стыке электроники и прошивки
У неё нет владельца по умолчанию. Отказ внутри схемы принадлежит схемотехнику, отказ внутри программы — программисту, а отказ между ними не принадлежит никому: он живёт в уровне сигнала, в тайминге, в порядке включения, в том, что происходит с выводом до того, как прошивка его сконфигурировала. Каждая сторона внутри своих границ действительно права, и обе говорят правду одновременно.
Вторая причина — характер отказа. Условия на стыке задаёт не код: температура, то, что включено рядом, порядок подачи питания, конкретный экземпляр платы. Отказ, который зависит от них, плавает — и тем самым даёт каждой стороне готовый аргумент, прогон, в котором ничего не сломалось. Пока предмет разговора не зафиксирован, спор нечем закончить.
Шаг 1. Зафиксировать пару «ревизия платы — версия прошивки»
«Прибор иногда виснет» — это не отказ, а жалоба: у неё нет адреса. Первое действие — записать, на чём именно наблюдали: маркировка экземпляра, ревизия платы, версия сборки прошивки, дата. Пока эта пара не названа, любой результат опровергается фразой «а у меня другая сборка», и разбирательство начинается заново.
Если ревизию нельзя прочитать с самой платы, а версию прошивки устройство не сообщает по запросу — это первый дефект, который надо закрыть, и он не относится ни к схеме, ни к коду. Учёт версий на партии — отдельная работа, которой не бывает у единственного образца; она разобрана в статье прототип платы и серийная партия.
Шаг 2. Записать отказ как воспроизводимый сценарий
Дальше нужен текст, по которому отказ повторит другой человек. В нём разделены наблюдение и трактовка: «зависает» — трактовка, «после команды на пуск выход не переключается, обмена нет, индикатор горит ровно» — наблюдение. Трактовку в протокол разбора не пишут: она уже содержит версию виновного.
- •Чем запитан прибор и что ещё висит на том же источнике,
- •Что было на линии обмена: кто опрашивал, с какой стороны шла команда,
- •Какая нагрузка на выходах и коммутировалось ли рядом что-то мощное,
- •Сколько устройство проработало до отказа и что делали непосредственно перед ним,
- •Температура и питание в момент отказа, если они менялись,
- •Что именно наблюдали — словами, без слова «зависло».
Критерий готовности шага один: сценарий даёт тот же результат у второго человека. Не даёт — значит, описан не полностью, и это единственный вывод, который из такого прогона следует.
Шаг 3. Питание и сброс — раньше логики
Провал напряжения ниже порога перезапускает контроллер, и снаружи это выглядит как «прошивка потеряла состояние». Сторожевой таймер, сработавший по своей причине, выглядит точно так же. Помеха от силовой части, общая точка земли, просадка при включении реле или двигателя — всё это даёт симптомы, неотличимые от программной ошибки, и разбирается совсем другими инструментами.
Поэтому шину питания и линию сброса смотрят до того, как открывают исходники. Признак, что дело здесь: отказ привязан не к ветке программы, а к событию во внешнем мире — включению нагрузки, длинному кабелю, конкретному месту монтажа. Пока это не исключено, поиск ошибки в коде идёт мимо причины, даже если в коде найдётся что поправить.
Шаг 4. Смотреть на провод, а не в лог
Лог прошивки — это её собственное представление о мире. Если она читает вход неверно, лог добросовестно покажет неверно прочитанное и будет выглядеть убедительно. Спорный сигнал смотрят прибором на самом выводе или на линии обмена: уровень, фронт, тайминг, реальная скорость передачи, есть ли ответ и кто начинает обмен.
Этот шаг ценен тем, что даёт не два исхода, а три — и третий как раз и есть стык.
| Что видно на проводе | Куда уходит разбирательство |
|---|---|
| Нужного сигнала нет вовсе или он искажён | Сторона схемы и монтажа: питание, цепь, компонент, пайка |
| Сигнал есть и соответствует ожиданию, но прошивка ведёт себя иначе | Сторона программы: конфигурация вывода, порядок инициализации, обработка |
| Сигнал есть, но не в том виде, какого ждёт программа | Это и есть стык: полярность, уровень, тайминг, порядок байтов — разбирается документом |
Шаг 5. Менять по одному
Локализация делается подстановками, и в каждом прогоне меняется ровно одна вещь. Иначе результат ничего не значит: сработало сразу два изменения, и какое из них помогло, неизвестно.
- •Та же плата, но заведомо простая тестовая прошивка: переключает вывод, отвечает эхом на линию, ничего больше,
- •Та же прошивка, но другой экземпляр платы той же ревизии,
- •Та же пара, но другое питание, другой кабель, другой соседний прибор на линии,
- •Та же пара в другом месте: на столе вместо шкафа, без силовой части рядом.
Ответ этого шага — не «кто виноват», а где живёт отказ: на одном экземпляре, на всех платах ревизии, в прошивке или во внешнем окружении. Отказ на одном экземпляре из нескольких указывает на монтаж или разброс параметров компонентов, а не на логику: логика одинакова на всех платах, а пайка — нет.
Шаг 6. Свести увиденное с документом на интерфейс
Здесь спор становится проверяемым утверждением. Документ на интерфейс между платой и прошивкой описывает границу словами, одинаковыми для обеих сторон: назначение и активный уровень каждой линии, состояние выводов до инициализации, порядок подачи питания и сброса, тайминги, параметры обмена, что считается ошибкой и что делает при ней каждая сторона.
Документ есть — сверяем наблюдение с ним и видим, кто от него отступил. Документа нет — виноватого в инженерном смысле нет тоже: обе стороны реализовали своё представление о границе, представления разошлись, и это ровно тот случай, ради которого назначают владельца стыка. Тогда сам документ пишется по итогам разбора и становится частью исправления, а не приложением к нему.
Отдельный источник расхождений — обмен по цифровой линии: адресация, таймауты, повторы, трактовка молчания как нормы или как аварии, порядок регистров. Одна сторона считает, что устройство обязано ответить всегда, вторая — что тишина допустима. Как расходятся два варианта одного распространённого промышленного протокола, разобрано в статье Modbus RTU и TCP: в чём разница на практике.
Шаг 7. Назначить владельца и закрыть отказ
Владелец стыка — не тот, кто виноват, а тот, кто принимает решение и доводит его до конца. Он один и назван поимённо; двое владельцев — это тот же спор, только с бюджетом. Его решение звучит не как «виновата прошивка», а как «правим здесь, потому что так дешевле и безопаснее, а границу описываем вот так».
Закрытие отказа — это не «поправили и вроде работает», а повторение исходного сценария из шага 2 на той же паре и запись результата: что изменилось — ревизия платы или версия прошивки, — и какие сочетания теперь считаются рабочими. Последнее важнее, чем кажется: после правки программы у вас останутся экземпляры на прежней ревизии платы, и кто-то должен знать, какую прошивку на них допустимо заливать.
Что согласовать до того, как отказ случится
Регламент выше работает быстрее, если часть его условий выполнена заранее. Это не про доверие между исполнителями, а про то, чтобы в момент разбора было чем оперировать.
- •Владелец стыка назван до начала работ, а не выбирается в момент отказа,
- •Документ на интерфейс между платой и прошивкой стоит в перечне результатов, а не «по возможности»,
- •Устройство сообщает свою версию прошивки по запросу, а ревизия читается с платы глазами,
- •Доступ к спорным линиям для измерения предусмотрен заранее — иначе шаг 4 упирается в отсутствие места, куда поставить щуп,
- •Исходники прошивки и среда сборки на руках у заказчика: без них проверить сторону программы нечем и разбор упирается в одного исполнителя,
- •Порядок разбора спорного отказа описан: кто собирает данные, кто измеряет, кто принимает решение.
Когда плата и прошивка заказываются по отдельности, к этому списку добавляется ещё один пункт: интерфейс между ними должен быть согласован раньше разводки, иначе первая же несостыковка стоит новой ревизии. Как этапы укладываются друг за другом, показано в разборе разработка электроники под заказ.
Два случая, в которых регламент работает иначе
Первый — когда электронику и программу ведёт один исполнитель. Спор тогда внутренний и решается без переписки — но граница всё равно должна быть описана. Не ради разбирательства, а ради инженера, который придёт после: он не был при устной договорённости и восстановит её только из документа.
Второй — когда внутри вашего изделия стоит законченный покупной блок: готовый контроллер, привод или датчик, чью прошивку вам не отдают и заменить не дают. Программируемый модуль-ядро, куда прошивку пишете вы сами, сюда не относится: там регламент работает целиком, а выбор между таким модулем и своей платой разобран отдельно — готовый модуль или своя плата.
С закрытым блоком стык не исчезает, он переезжает на границу с изготовителем. Свою сторону вы описываете сами, чужую берёте из документации на блок и проверяете измерением: ведёт ли он себя так, как там написано. Расхождение с его же документацией — проверяемое утверждение, с которым идут к изготовителю; догадка о том, что творится внутри чужой прошивки, таким утверждением не является.
Меняется в регламенте один шаг. Тестовую программу внутрь закрытого блока не подставить, поэтому в шаге 5 подстановками остаются другой экземпляр блока, другой его режим, другое питание и другое окружение. Шаг 7 остаётся целиком: правка внутри блока идёт через изготовителя и его очередь, но решение по своей стороне принимаете вы, а закрывать отказ — повторять сценарий шага 2 и записывать, какие сочетания считаются рабочими, — кроме владельца изделия некому.
Мы ведём электронику и прошивку в одной ответственности, поэтому владелец стыка у проекта есть с первого дня и переводить стрелки некому. Что остаётся у заказчика после работы — права на результат, исходники со средой сборки и документация, по которой продолжит другой инженер, — перечислено на странице что мы делаем.
Главный вывод регламента прост: вопрос «кто виноват» задаётся последним. Сначала пара версий, потом питание, потом измерение на проводе, потом подстановка по одному — и лишь затем сверка с документом, которая и называет сторону. В обратном порядке этот разговор не заканчивается никогда.
Частые вопросы
Кто виноват, если плату и прошивку делали разные подрядчики?
Пока причина не локализована, вопрос о вине задавать рано: каждая сторона права в своих границах и покажет прогон, где у неё всё работает. Сначала измерение на выводе, потом сверка с документом на интерфейс — и только он показывает, чья сторона от согласованного отступила. Если согласованного документа нет, вопрос уходит из инженерной плоскости в договорную: сверять наблюдение не с чем, и сторону называет не измерение, а владелец стыка.
С чего начинать, если отказ воспроизводится не всегда?
Порядок тот же, что и у воспроизводимого: сначала шаг 1 — пара «ревизия платы — версия прошивки», иначе любой прогон не к чему привязать. А дальше смотрят условия, а не код: чем запитан прибор, что включалось рядом, что происходило на линии обмена, сколько устройство проработало до сбоя. Отказ, привязанный к коммутации мощной нагрузки, разбирается на шине питания, а не в ветках программы.
Можно ли определить сторону по логам прошивки?
Сторону — нет, момент — да. Лог отвечает на вопрос, что прошивка прочитала, а не что происходило на проводе: неверно сконфигурированный вход даёт запись убедительную и неверную одновременно. Зато лог расставляет метки времени и порядок событий, и по ним находят нужное место в записи прибора. Доказательством считают измерение на линии, логом до него добираются.
Что должно быть в документе на интерфейс между платой и прошивкой?
Критерий достаточности один: каждый пункт должно быть чем проверить — прибором на выводе или прогоном по сценарию. По линиям это назначение, активный уровень и то, каким вывод обязан быть до инициализации; по включению — очерёдность питания и сброса; по обмену — тайминги, параметры, что считается ошибкой и как ведёт себя при ней каждая сторона. Пункт, который нечем проверить, спора не закроет и в документе не нужен. Пишут его до разводки платы, а не после первого отказа.
Обязательно ли менять плату, если причина оказалась на её стороне?
Не всегда: часть расхождений закрывается прошивкой — другим порядком инициализации, иной трактовкой уровня, программной фильтрацией дребезга. Решение принимается по цене и по риску: правка прошивки дешевле выпуска новой ревизии, но она не спасает там, где на выводе физически нет нужного сигнала. Выбор фиксируют в журнале, чтобы следующий инженер видел, почему схема выглядит именно так.