Из чего состоит прошивка прибора
Прошивку (firmware) записывают в память микроконтроллера, и она работает всё время, пока прибор включён. В отличие от программы на компьютере, у неё жёсткие ограничения: мало памяти, ограниченная производительность, часто — питание от батареи и требование реагировать на события за фиксированное время.
Хорошо спроектированная прошивка состоит из слоёв. Это не формальность: от разделения на слои зависит, насколько дорого будет менять микроконтроллер, добавлять функции и исправлять ошибки.
| Слой | Что делает | Пример |
|---|---|---|
| Загрузчик | Запускается первым, проверяет и загружает основную программу, принимает обновления | Проверка контрольной суммы образа, переход в режим обновления |
| Драйверы | Работа с периферией микроконтроллера и микросхемами на плате | АЦП, таймеры, SPI, I2C, UART, дисплей, внешняя память |
| Промежуточный слой | Протоколы, файловые системы, планировщик или ОС реального времени | Modbus RTU, CAN, Bluetooth, USB, RTOS |
| Логика прибора | То, ради чего прибор существует | Расчёт измеряемой величины, калибровка, режимы работы, тревоги |
| Сервисные функции | Диагностика, журналы, настройка, защита | Журнал ошибок, сторожевой таймер, режим калибровки с паролем |
Когда логика прибора не зависит напрямую от регистров конкретного микроконтроллера, её можно тестировать на компьютере, а при смене элементной базы переписывать только нижние слои.
Этапы разработки прошивки
Прошивку не стоит начинать после того, как плата готова. Архитектуру проектируют вместе со схемой: программист заранее знает распиновку, интерфейсы и объём памяти, а схемотехник — что нужно прошивке. Код начинают писать на отладочных платах с тем же микроконтроллером.
| Этап | Что делаем | Результат | Где теряют время |
|---|---|---|---|
| 1. Требования | Функции, режимы работы, интерфейсы, время реакции, энергопотребление, аварийные ситуации | Требования к ПО | Аварийные режимы не описаны — их «вспоминают» на испытаниях |
| 2. Архитектура | Слои, модули, выбор между bare-metal и RTOS, протокол обмена, карта памяти | Описание архитектуры и протокола | Протокол обмена с ПК или облаком меняется по ходу работы |
| 3. Разработка | Драйверы, логика, протоколы; код в системе контроля версий | Рабочие версии прошивки | Код ведётся без истории изменений, на одном компьютере |
| 4. Отладка на плате | Запуск на опытном образце, поиск ошибок схемы и кода | Прошивка, работающая на образце | Ошибки платы и кода ищут по отдельности, без совместной отладки |
| 5. Тестирование | Модульные тесты, стендовые проверки, граничные режимы | Протокол тестирования | Проверяют только «нормальную» работу |
| 6. Передача | Исходники, сборки, инструкции, утилиты для производства | Комплект для выпуска и сопровождения | Передают только файл прошивки без исходников |
Что должно быть в требованиях к прошивке
- все режимы работы прибора и переходы между ними;
- интерфейсы и протоколы: что, куда, с какой частотой и в каком формате передаётся;
- требования ко времени: как быстро прибор должен отреагировать на событие;
- энергопотребление и режимы сна — для батарейных приборов;
- поведение при сбоях: пропадание питания, обрыв связи, неисправный датчик, некорректные данные;
- способ обновления прошивки и защиты от несанкционированных изменений;
- какая документация нужна на выходе.
Bare-metal или RTOS: как выбрать
Bare-metal — прошивка без операционной системы: основной цикл и обработчики прерываний. RTOS — операционная система реального времени, которая распределяет процессорное время между задачами. Это не вопрос «старое или современное», а выбор под задачу.
| Критерий | Без ОС (bare-metal) | С RTOS |
|---|---|---|
| Число задач | Немного, работают по очереди | Много параллельных задач с разными приоритетами |
| Ресурсы | Минимальные требования к памяти | Нужна память под ядро и стеки задач |
| Время реакции | Предсказуемо в простых системах | Управляется приоритетами при сложной логике |
| Сетевые стеки | Подключать сложнее | Многие стеки рассчитаны на работу под ОС |
| Сложность отладки | Проще в небольших проектах | Нужен опыт: гонки, взаимные блокировки, переполнение стека |
| Типичный прибор | Датчик с одним интерфейсом, простой контроллер | Прибор с экраном, сетью, измерениями и журналом одновременно |
На практике решение принимают на этапе архитектуры, а не по привычке разработчика. Если сомневаетесь, полезно спросить подрядчика, почему он выбрал тот или иной вариант и что изменится, когда в прибор добавят новую функцию.
Обновление прошивки в поле
Если прибор нельзя обновить после выпуска, каждая найденная ошибка означает возврат устройств или выезд к заказчику. Поэтому способ обновления закладывают в архитектуру с самого начала:
- через проводной интерфейс — USB, RS-485, UART с помощью сервисной программы;
- по воздуху — через Bluetooth, Wi-Fi или сотовую связь, если они есть в приборе;
- проверка целостности — загрузчик проверяет образ перед запуском и не запускает повреждённый;
- откат — при неудачном обновлении прибор возвращается к предыдущей рабочей версии;
- защита — прибор принимает только прошивки от производителя, если это требуется.
Обновление по воздуху требует запаса памяти — как правило, места под две версии прошивки. Это нужно учесть при выборе микроконтроллера, иначе функцию придётся отложить до новой ревизии платы.
Тестирование и приёмка кода
Принимать прошивку только по тому, что «прибор работает», рискованно: ошибки граничных режимов проявятся у пользователей. Ниже — что стоит проверить при приёмке.
- Сборка. Прошивка собирается из переданных исходников по инструкции на чистом компьютере, и результат совпадает с файлом, который зашит в прибор.
- История изменений. Код передан вместе с репозиторием системы контроля версий, а у каждой выпущенной версии есть метка.
- Тесты. Есть модульные тесты для логики и обработки данных, и они проходят.
- Граничные режимы. Проверены пропадание питания во время записи, обрыв связи, неисправный датчик, переполнение журналов, некорректные команды.
- Протокол обмена. Описан отдельным документом: по нему другая команда сможет написать ПО для ПК или облака.
- Протокол тестирования. Видно, что проверяли, на какой версии прошивки и ревизии платы, и с каким результатом.
Типичные ошибки
- Прошивку начинают после платы. Выясняется, что не хватает памяти, ножек микроконтроллера или нужного интерфейса, и плату переделывают.
- Нет запаса памяти. Прошивка помещается впритык, и для обновления по воздуху или новых функций места уже нет.
- Логика смешана с драйверами. Любая замена микросхемы или микроконтроллера превращается в переписывание всего кода.
- Протокол обмена не зафиксирован. Прошивка и программа для ПК развиваются независимо и перестают понимать друг друга после обновления.
- Исходники не переданы. У заказчика есть только файл прошивки: исправить ошибку или сменить подрядчика невозможно.
Нормативная база
Единого закона о разработке прошивок нет. Требования к ПО прибора зависят от его назначения и рынка:
- ГОСТ 19.101-77 и другие стандарты Единой системы программной документации (ЕСПД, серия ГОСТ 19) — если заказчику нужна программная документация по государственным стандартам. Как правило, этого требуют в госзаказе и на предприятиях с собственной системой стандартов.
- Федеральный закон № 102-ФЗ «Об обеспечении единства измерений» — если прибор является средством измерений в сфере государственного регулирования и проходит утверждение типа. В этом случае проверяют и его ПО: по рекомендациям Р 50.2.077-2014 оценивают идентификацию метрологически значимой части ПО (наименование, версию, цифровой идентификатор) и её защиту от непреднамеренных и преднамеренных изменений.
- ТР ТС 020/2011 «Электромагнитная совместимость технических средств» — сам регламент не регулирует код, но режимы работы прошивки влияют на помехи от прибора и его устойчивость к ним.
- МЭК 62304 — процессы жизненного цикла ПО медицинских изделий: для прошивок медицинских приборов требования к процессу разработки, тестированию и документации строже.
Условный пример: регистратор температуры
Это обобщённый пример, а не описание конкретного проекта. Заказчику нужен многоканальный регистратор температуры для складов: измерения раз в минуту, журнал во внешней памяти, передача данных на сервер, работа от батареи не меньше года.
- Требования. Описываем, что делать при пропадании связи (копить данные и досылать) и при разряде батареи (предупредить заранее и сохранить журнал).
- Архитектура. Задач немного, и они выполняются по расписанию, поэтому выбираем прошивку без ОС с режимами глубокого сна. Логику измерений отделяем от драйверов, чтобы тестировать её на компьютере.
- Обновление. Закладываем загрузчик с проверкой образа и откатом. Из-за этого выбираем микроконтроллер с запасом памяти под две версии прошивки.
- Тестирование. На стенде отключаем питание во время записи в журнал и проверяем, что данные не теряются. Измеряем реальный ток потребления во сне и пересчитываем время работы от батареи.
- Передача. Заказчик получает репозиторий, инструкцию по сборке, описание протокола для серверной части и утилиту прошивки для производства.
Ключевой момент примера: требования к обновлению и энергопотреблению повлияли на выбор микроконтроллера, поэтому их нужно было определить до разводки платы.
Частые вопросы
Кому принадлежит исходный код прошивки?
Это определяет договор. Условия передачи исходного кода и исключительных прав нужно зафиксировать до начала работ. Если код остаётся у разработчика, вы не сможете исправить ошибку, перенести прошивку на другой микроконтроллер или сменить подрядчика без его участия.
Сколько стоит разработка прошивки?
Стоимость зависит от числа и сложности интерфейсов, объёма обработки данных, требований к надёжности и обновлению, а также от того, нужна ли документация по стандартам. Оценку дают после разбора требований — по этапам, чтобы было видно, за что вы платите.
Можно ли перенести прошивку на другой микроконтроллер?
Да, если код изначально разделён на слои: драйверы и работа с периферией отдельно, логика прибора отдельно. Тогда при смене микроконтроллера переписывается в основном нижний слой. Если всё смешано в одном модуле, перенос по трудоёмкости близок к новой разработке.
Нужна ли прибору операционная система реального времени?
Не всегда. Простому прибору с несколькими задачами и предсказуемыми режимами достаточно прошивки без ОС. RTOS оправдана, когда задач много, они работают параллельно и у них разные требования ко времени реакции — например, сетевой стек, измерения и интерфейс пользователя одновременно.
Можно ли доработать прошивку, которую писал другой разработчик?
Да, но начинать нужно с аудита: собирается ли код из того, что передано, есть ли история изменений, как устроена архитектура, какие известны ошибки. По итогам решают, что можно доработать, а какие модули надёжнее переписать.
Нужна прошивка для прибора?
Опишите, что должно делать устройство, есть ли уже плата и какие интерфейсы нужны. Разберём требования, предложим архитектуру и оценим работу по этапам. NDA подписываем до передачи технической информации.
Обсудить прошивку