После 13 лет программирования микроконтроллеров размышляя на тему того, что должно быть в типовой микроконтроллерной прошивке я проанализировал сотни сборок и десятки электронных плат. В результате как в математике вынес за скобки базовый функционал, который так или иначе нужен практически в каждом проекте. Этот функционал кристаллизировался в требования, которые я решил назвать ортодоксально каноническая форма прошивки (ОКФП). По аналогии с тем как в С++ есть такое понятие, как ортодоксально каноническая форма для класса.
Итак обо все по порядку. Что же такое ортодоксально каноническая форма прошивки? Если коротко, то это компромисс между простотой и функциональностью.
Ортодоксально каноническая прошивка это прошивка, которая обладает следующими свойствами:
1--Прошивка собирается из GNU Make скриптов. Это необходимо для сборки по клику на *.bat скрипт. Плюс сборка из скриптов нужна для подключения сборки к серверу автоматического построения Jenkins.
2--Сборка без RTOS. Например, UART загрузчику RTOS нужна, как собаке бензобак. Потом прошивки с RTOS проблематично сертифицировать. Плюс NoRTOS код можно легко собирать и на LapTop PC в виде консольного приложения и тем самым быстро отлаживать всяческую математику программы. Поэтому безусловно надо научиться собирать проекты без RTOS и держать наготове сборки без RTOS.
3--В сборке присутствуют драйверы для следующих базовых фундаментальных аппаратных подсистем: Clock, MCO, PLL, NVIC, SysTick, GPIO, PINMUX, FLASH, TIMER, DMA, UART. Реализация драйверов должна быть полной.
4--В сборке присутствует HeartBeat LED. Чтобы просто глядя на устройство убеждаться, что прошивка не зависла. Раз мигает LED значит не зависло. Значит вертится суперцикл в main-е.
5--В прошивку добавлен драйвер аппаратных таймеров. Это необходимо не только для вычисления микросекундных пауз, но и для получения up-time программы. Для анализа времени исполнения участков кода и для диспетчера задач.
6--В сборке присутствует диспетчер задач на базе компонента Limiter.
7--В сборке присутствует UART-CLI.
8--В сборке присутствует NVRAM.
9--В сборке присутствует API для пуска модульных тестов.
10--Модульные тесты можно вызывать текстовой командой из UART-CLI буквально из PuTTY.
11--Также следует сразу подготовить отдельную сборку загрузчика через UART-CLI.
12--Должен быть запущен сторожевой таймер.
Вот, пожалуй, и всё. Всего лишь какие-то жалкие двенадцать пунктов. По факту только на этой почве и возможно полноценно начинать наращивать и отлажить какой бы то ни было прикладной функционал или приложение. А без этого минимума-минимумов будет не разработка, а стрельба из лука с завязанными глазами. Уж поверье мне... Нахлебался уже.
CLI, NVRAM и сборка из скриптов это норма. Эти атрибуты являются просто джентльменским набором программиста для абсолютно любой нормальной, современной, взрослой, промышленной прошивки. Своего рода коробочка в которую можно заложить абсолютно любой прикладной функционал. Это так же принято, как в нормальных государствах присутствует школьное образование, медицинское страхование и пенсионная система. Если у Вас в репозитории и прошивке всего этого добра нет, то, наверное, говорить о разработке какого-либо устройства просто даже не имеет смысла... Проект заглохнет, разрушится под собственным весом спустя два-три года. Разработка уйдет в штопор и пополнит кладбище не взлетевших проектов. Я сам это видел своими глазами до того как сам пришел к необходимости ОКФП. Как ни крути, но сначала надо поднять какую-никакую минималистическую систему. Писать прошивку без этих 7-10 свойств - это как ходить по улице без одежды. Понимаете?...
Более подробно по каждому требованию к ортодоксально канонической форме для прошивки можно почитать отдельные тексты по ссылкам в источниках
Название текста | URL |
Зачем Программисту Микроконтроллеров Диофантовы Уравнения | |
Как собрать Си программу в OS Windows | |
NVRAM для микроконтроллеров | |
Почему Нам Нужен UART-Shell? | |
Архитектура Хорошо Поддерживаемого Программного Компонента | |
Модульное Тестирование в Embedded | |
Диспетчер Задач для Микроконтроллера | |
Почему важно собирать код из скриптов | |
23 Атрибута Хорошего Загрузчика | |
Запуск сервера сборки Jenkins | |
Что Должно Быть в Каждом FirmWare Pепозитории | |
Архитектура Xорошего Кода Прошивки (Массив-Наше Всё) | |
Aтрибуты Хорошей Прошивки (Firmware) |
Можно конечно и расширять этот список. Добавить требование запуска MPU, окраски стековой памяти, сборки из CMake и прочие радости. Однако тогда придется вводить какое-то новое следующее определение. Например, условно, "надежная прошивка" или "имунная прошивка" и т. п.
Разумеется в случае работы с Bluetooth или LwIP вам ещё потребуется какая-никакая RTOS. Это вообще отдельная тема. Но ОКФП у вас должна быть всегда наготове для экспериментов, испытаний и прогона модульных тестов.
Если есть, что добавить (или исключить) к требованиям к ОКФП, то пишите в комментариях.
