79. Как рождается устройство: этапы разработки

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

Здесь мало регистров и много решений. Но и у решений есть проверяемая часть: бюджет питания считается, требование превращается в тест, а воспроизводимость сборки проверяется компилятором — всё это в разделе пересчитано и собрано.

Как это называется в документации

Оригинал	Перевод
requirements, specification	требования, техническое задание
functional / non-functional requirement	функциональное / нефункциональное требование
stakeholder	заинтересованная сторона
power budget	бюджет питания
bill of materials (BOM)	перечень элементов
schematic, layout	схема, разводка платы
ERC, DRC	проверка схемы, проверка правил разводки
EVT, DVT, PVT	инженерные, конструкторские, производственные испытания
verification / validation	верификация / валидация
unit test, hardware-in-the-loop (HIL)	модульный тест, испытания на стенде с устройством
reproducible build	воспроизводимая сборка
traceability	прослеживаемость
design for manufacturing / testing (DFM / DFT)	технологичность, контролепригодность
test fixture	испытательная оснастка
end of life (EOL), NRND	снятие с производства, «не для новых разработок»

79.1 Шесть этапов — и почему это петля

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

79.2 Требования: только измеримые

Требование, которое нельзя проверить, — пожелание. Сравните:

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

У каждого требования в задании должен быть способ проверки. Тогда к этапу испытаний готов их перечень: одно требование — одна или несколько проверок. Этот справочник устроен так же: каждое число в тексте пересчитано проверочным скриптом.

79.3 Расчёт на салфетке: можно ли это сделать

Прежде чем выбирать компоненты, требования проверяют грубым расчётом. Пример — «год от батарейки». Исходные данные примера: устройство раз в минуту просыпается на 20 мс и в работе потребляет 10 мА; спит в режиме Stop при 20 мкА; батарейка — 220 мА·ч. Порядок токов режимов для F103 — в разделе 10.

Средний ток — взвешенная по времени сумма:

Iср = (10 мА × 20 мс + 0,020 мА × 59 980 мс) / 60 000 мс ≈ 23,3 мкА
220 мА·ч / 23,3 мкА ≈ 9430 ч ≈ 393 дня

Год набирается впритык, но главное видно из разложения: 86 % среднего тока — сон, а не работа. Ускорить программу вдвое почти бесполезно: при работе 10 мс вместо 20 выходит 423 дня — всего на 8 % дольше. А сон в режиме Standby при 3 мкА даёт 6,3 мкА в среднем и 1448 дней — почти четыре года. Цена — в Standby теряется содержимое ОЗУ, и после пробуждения программа начинается со сброса (раздел 10).

Все эти сроки — верхняя оценка. Паспортная ёмкость CR2032 указана при малом постоянном токе; импульсы по 10 мА сажают напряжение и уменьшают отдаваемую ёмкость, на холоде сильнее, да и саморазряд забирает около процента в год (раздел 53.6). Поэтому в расчёт закладывают запас хотя бы в полтора-два раза и ставят у батарейки конденсатор, который отдаёт импульсы тока. С запасом вдвое Stop даёт 196 дней — требование «год» без Standby не выполнено; Standby — 724 дня, почти два года.

Так расчёт на салфетке меняет требования к схеме и программе раньше, чем куплен первый компонент: нужен режим Standby, нужен датчик, который умеет спать, и нужна проверка тока сна на первом же прототипе.

⚠️ Проверка правдоподобия. Задача: источник 24 В, лампа и два резистора по 18 Ом, сопротивление лампы — половина резистора, ток 875 мА; найти внутреннее сопротивление источника. Если считать всё соединённым последовательно, выходит 27,43 − 45 = −17,6 Ом: отрицательного сопротивления не бывает — значит, модель неверна. Лампа последовательно с двумя параллельными резисторами даёт 9,4 Ом, все три параллельно — 22,9 Ом. Без схемы у задачи два ответа. Это и есть неоднозначное требование: условие без рисунка. Законы для таких расчётов — в разделах 49 и 50.

79.4 Проектирование: от блоков к плате

Сначала — структурная схема: какие блоки, как связаны, где питание, где интерфейсы. Потом выбор компонентов под блоки, и только потом принципиальная схема и плата.

Выбор микроконтроллера (раздел 2.5): периферия под задачу, память с запасом, корпус, который вы сможете запаять, наличие у поставщиков и статус жизненного цикла. Камень с пометкой NRND — «не для новых разработок» — в новый проект не ставят.

Прототип до своей платы. Отладочная плата (раздел 2.6) и модули на макетке позволяют писать программу и мерить ток, пока своя плата ещё не заказана. Раздел 80 — о таком прототипе.

Своя плата. Схема проверяется ERC, разводка — DRC. Для STM32 при этом не забывают минимальную обвязку и условия запуска (раздел 61), защиту выводов (раздел 62) и то, что понадобится на всех следующих этапах:

• разъём или контактные площадки SWD — прошивка и отладка (раздел 4.9);
• доступ к BOOT0 — встроенный загрузчик на крайний случай (раздел 11.7);
• свободный UART для журнала;
• контрольные точки питания и ключевых сигналов — для оснастки на производстве;
• пара свободных выводов «на всякий случай».

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

79.5 Программа: с первого дня как для серии

Логика — отдельно от железа. Код, который принимает решения, не должен сам лезть в регистры: его вызывают с данными, он возвращает результат. Тогда его можно проверить тестом на компьютере. Пример — требование из 79.2 про кнопку, превращённое в функцию:

#define PRESS_MS 20

typedef struct {
    uint8_t stable;     /* принятое состояние: 1 — нажата */
    uint8_t count;      /* сколько миллисекунд подряд уровень не равен принятому */
} button_t;

/* raw — уровень вывода (1 — нажата), вызов раз в 1 мс. Вернёт 1 ровно
 * один раз — в ту миллисекунду, когда нажатие принято. */
int button_update(button_t *b, int raw)
{
    if (raw == b->stable) {
        b->count = 0;
        return 0;
    }
    if (++b->count < PRESS_MS)
        return 0;
    b->stable = (uint8_t)raw;
    b->count = 0;
    return raw;         /* событие — только нажатие, отпускание молча */
}

На плате её вызывают из прерывания таймера раз в миллисекунду с уровнем вывода (природа дребезга — раздел 50.7). А на компьютере тест подаёт ей заранее заданные последовательности уровней:

Один и тот же файл собран armclang для Cortex-M3 и M0 без предупреждений и gcc для теста; состояние кнопки — 2 байта ОЗУ. Тест остаётся в проекте: любая правка функции перепроверяется за секунду. Следующий уровень — испытания на стенде, где устройство получает настоящие сигналы от другой платы или прибора.

Версия — в прошивке, и без __DATE__. Устройство должно уметь сказать, какая в нём прошивка. Соблазн — вписать __DATE__ и __TIME__ (раздел 71). Но тогда две сборки одного исходника подряд дают разные файлы, и уже не доказать, из какого исходника собрана прошивка в конкретном устройстве. Проверено:

• с __DATE__ и __TIME__ две сборки подряд различаются;
• ключ -Wdate-time предупреждает о каждом таком месте;
• переменная окружения SOURCE_DATE_EPOCH=0 фиксирует дату (Jan 1 1970 00:00:00), и сборки совпадают байт в байт;
• лучше всего версию передаёт система сборки:

#ifndef FW_VERSION
#define FW_VERSION "0.0.0-dev"
#endif
const char version[] = FW_VERSION;

Номер задают ключом компилятора, и кавычки должны дойти до него: в оболочке ключ берут в одинарные — '-DFW_VERSION="1.4.2"', в Makefile пишут -DFW_VERSION=\"1.4.2\". Без этого оболочка кавычки съест, FW_VERSION раскроется в 1.4.2 без кавычек, и строка не соберётся. Сам номер удобно брать из системы контроля версий — командой git describe (раздел 109). С таким ключом сборки совпадают, а строка 1.4.2 лежит в объектном файле. Но строку, на которую никто не ссылается, компоновщик выбрасывает (раздел 77.5), и в готовой прошивке её не окажется. Поэтому версию либо используют — отдают по команде в порт, печатают при старте, — либо сохраняют явно: у armlink — ключом --keep=version, у GNU ld — строкой KEEP(*(.rodata.version)) в скрипте компоновки. Проверяют поиском строки в готовом образе — тогда её видно и в файле, и по отладчику (раздел 77.9).

Контроль версий с первой строки, обновление прошивки в поле (раздел 48), сторожевой таймер (раздел 12) и журнал ошибок закладывают сразу — добавить их в готовое изделие труднее, чем в прототип.

79.6 Испытания

Два слова, которые путают:

• верификация — сделано ли устройство правильно, по заданию: каждое требование проверено;
• валидация — сделано ли правильное устройство: решает ли оно задачу пользователя. Устройство может пройти все проверки задания и оказаться ненужным — если задание было неверным.

В производстве электроники испытания делят по зрелости изделия:

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

Прошивка на заводе. Программатор по SWD через контактные площадки или встроенный загрузчик по UART (раздел 4.9). После записи — защита чтения байтами конфигурации (раздел 11.6).

Тестовая прошивка. Отдельная программа проверяет собранную плату: питание, кварц, светодиоды, датчики, интерфейсы — и выдаёт «годен / брак» на оснастку. Контрольные точки на плате закладывают ещё на этапе проектирования (79.4) — это и есть контролепригодность.

Серийный номер. У STM32 есть заводской уникальный номер длиной 96 бит. У F407 он лежит по адресу 0x1FFF7A10, рядом — регистр размера Flash 0x1FFF7A22; оба имени (UID_BASE, FLASHSIZE_BASE) объявлены в stm32f407xx.h. В заголовке F1 старого формата stm32f10x.h этих имён нет. У F1 номер лежит с адреса 0x1FFFF7E8, размер Flash — по адресу 0x1FFFF7E0, у G4 — 0x1FFF7590 и 0x1FFF75E0. В каждом семействе адрес свой, поэтому его берут из справочного руководства своего камня (раздел 39).

uint32_t serial32(void)
{
    const volatile uint32_t *uid = (const volatile uint32_t *)UID_BASE;
    return uid[0] ^ uid[1] ^ uid[2];
}

Это три чтения по 32 бита и два XOR. Свёртка 96 бит в 32 может дать совпадение у разных камней; где номер важен, хранят все 12 байт.

Прослеживаемость. Серийный номер связывают с версией прошивки, партией плат и партиями компонентов. Когда из поля придёт отказ, это позволит найти всех «соседей» устройства по партии.

Компоненты. Для каждой позиции перечня — второй поставщик или замена; статус жизненного цикла отслеживают и после запуска серии.

79.8 Поддержка после выпуска

• Обновления — через свой загрузчик или по воздуху (раздел 48); без механизма обновления любая ошибка в прошивке — это выезд к устройству.
• Журнал ошибок в устройстве: причина последнего сброса, счётчик срабатываний сторожевого таймера, код последнего отказа. Возвращённое устройство тогда рассказывает, что с ним было.
• Разбор возвратов: каждый отказ — вопрос, на каком этапе его следовало поймать, и новая проверка на этом этапе.
• Совместимость: новая прошивка должна понимать настройки, записанные старой.

79.9 Команда

Устройство редко делает один человек: схемотехник, конструктор, программист, испытатель, технолог производства, руководитель проекта. Чем больше людей, тем важнее общие документы — задание, схема, перечень элементов, журнал изменений — и общие правила работы.

Для железа итерации медленнее, чем для программ: плату не пересоберёшь за минуту. Поэтому то, что можно проверить без железа, проверяют без него — модульными тестами на компьютере (79.5) и автоматической сборкой при каждом изменении. Этот справочник выпускается так же: ни одна версия не выходит, пока не прошли все проверки.

79.10 Грабли

Требование «быстро» или «долго». Без числа его нельзя ни выполнить, ни проверить.

Батарейки хватает на месяц вместо года. Бюджет питания не считали; ток сна не мерили на прототипе.

Ускорили программу — время работы от батареи не выросло. Средний ток определяет сон, а не работа.

Плата пришла, а прошить её нечем. Не выведены SWD или BOOT0.

Две прошивки с одинаковой версией ведут себя по-разному. Версию не меняли при сборке, или сборка не воспроизводима из-за __DATE__.

Ошибка, исправленная полгода назад, вернулась. Не было теста, который её ловит.

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

Отказ из поля не воспроизводится. Устройство не хранит причину сброса и код отказа.

Камень сняли с производства посреди серии. Не отслеживали статус жизненного цикла, нет замены.

В ответе задачи отрицательное сопротивление. Неверна модель, а не арифметика.

79.11 Итоги

• Этапы — требования, проектирование, программа, испытания, производство, поддержка — образуют петлю; ошибка тем дороже, чем позже найдена.
• Требование измеримо и имеет способ проверки; нефункциональные требования забывают чаще всего.
• Расчёт на салфетке проверяет требования до покупки компонентов: при работе 20 мс в минуту 86 % среднего тока — сон; Stop даёт 393 дня от 220 мА·ч, Standby — почти четыре года. Это по паспортной ёмкости; с запасом вдвое «год» выполняет только Standby.
• Логику отделяют от железа и проверяют тестом на компьютере: один файл для armclang и для gcc.
• Версия прошивки — из системы сборки; __DATE__ делает сборку невоспроизводимой, -Wdate-time об этом предупреждает.
• Верификация — «сделано по заданию», валидация — «сделано то, что нужно»; стадии EVT, DVT, PVT.
• На плату закладывают SWD, BOOT0, UART и контрольные точки; на заводе — тестовая прошивка, защита чтения, серийный номер из уникального номера камня.
• После выпуска — обновления, журнал отказов и разбор возвратов.

Полные исходники

ver79.c — версия из системы сборки.

/* Раздел 79.5: версия из системы сборки. На строку никто не ссылается — компоновщик её выбросит. */
#ifndef FW_VERSION
#define FW_VERSION "0.0.0-dev"
#endif
const char version[] = FW_VERSION;

Дальше: раздел 80 «Прототип на Arduino: плата, среда, первый скетч».