Комментарии 36
Не нужно фантазировать. Есть нормальные процессы разработки под железо. И тестирование, и тестирование на железе и жизненные циклы. Пишутся имитаторы окружения, имитаторы железа, делаются тестовые стенды, делается изоляция модулей программы, прогоняются анализаторы кода - это всё есть. Это совсем не так как Web и достаточно сильно отличается от десктопных плюсов, но всё уже давно есть и используется в серьёзных проектах.
А то, что 90% российских разработчиков софта под железо - "ардуинщики" или лабают а Keil MDK, так это особенности деградации отрасли и низкий уровень оплаты. Если платить 30 т.р. разработчику под STM, то естественно получишь ардуинщика, Keil, и хаос вместо нормального процесса разработки.
И, кстати, я пока не видел, чтобы Jenkins использовали - специфика несколько иная. Хотя, можно, наверное. Но после того как написана своя сборка - а она совершенно всегда требуется, так как контрольные суммы, нестандартная упаковка бинарников, внедрение ресурсов, гарантия уникальности версии, загрузки и т.д, - всё это сделать из IDE и стандартные make-файлов или невозможно или очень криво получается. И почти всегда нужно делать какие-то дополнительные нестандартные телодвижения для автоматизации процесса релизной сборки. После того, как создано ПО для прошивки и тестирования, ПО для массового производства, массовой проверки ремонта, наладки/калибровки, и т.п. то оказывается, что автоматизация сборки это наиболее простая и наименее трудоёмкая задача из всего и она уже решена каким-то образом в ходе выполнения остальных работ.
для IoT вполне актуальная схема. вот на одном из проектов запускал в продакшн: само приложение бэкенд и мобильные клиенты, но есть устройства (шлагбаумы), отдельная команда разработки и их прошивка до недавнего времени была даже не в репе!) вобщем, внедрили -- положили в реп, завели постоянный тестовый стенд, к которому дев-сервер приложения обращается, и даже выдали сваггер с этого стенда. смогли тестировать целиком наконец-то. варианты включения сборки и аплоада прошивок в общий процесс CI/CD -- сейчас как раз ресерчим и что-то похожее собираемся "изобрести". )
А где-то можно прочитать про лучшие практики, чтобы не изобретать велосипеды?
Лучшие практики формируются во время работы. Надо походить по граблям.
Можно почитать ISO26262 части 5 и 6
Part 5: Product development at the hardware level
Part 6: Product development at the software level
В какой-то мере придется по ним ходить в любом случае, но хотелось бы это минимизировать. Просто Sap_ru сказал, что не нужно фантазировать и всё уже давно отработано, вот мне бы и хотелось почитать где-нибудь про подход, который он предлагает.
Но вам тоже спасибо за статьи и ссылки.
Есть 2 таких текста
17 атрибутов хорошей PCB
https://habr.com/ru/post/655879/
9 атрибутов хорошего firmware
https://habr.com/ru/post/655641/
И, кстати, я пока не видел, чтобы Jenkins использовали - специфика несколько иная. Хотя, можно, наверное.
Jenkins можно и вовсе локально запустить. Для Jenkins зависти отдельный репозиторий в который только git pull делать (release) .
Для разработки другой отдельный локальный репозиторий workspace. В нем можно и писать и читать.
https://habr.com/ru/articles/695978/
Используем ClearCase, make, cmake, Gdb для отладки, Nunit, Clion для редактирования кода.
Нет только сервера сборки, но спасибо за наводку.
А затем отдельный сервер? У вас сборка идёт несколько часов? КМК достаточно настроить сборку в контролируемом окружении (виртуальная машина, docker), чтобы результаты были воспроизводимы.
Да, сборка идет долго. Сама сборка минут 40 (на дебаг и релиз), юнит тесты час примерно и еще проверка статическим анализатором минут 40. Итого, около двух часов. Там конечно если распараллелить на 8 потоков, быстрее получается, но в целом меньше часа не получается.
Долгая сборка идет по причине использования спец тулов, например clearmake, вместо обычного make. Он дополнительно собирает информацию о том, какие версии файлов, с каких меток были собраны в этой сборке. Потом можно делать аудит и собственно полностью воспроизвести сборку для этой версии.
У нас 55 сборок и каждая 5 минут. Чтобы пересобрать артефакты после 1 комита надо 4 ч 30 мин.
Вот тут рассказывал, как это организовано у нас в wirenboard: https://www.youtube.com/watch?v=HEEVxZ4rBCo&t=1510s
В каком инструменте Вы производите инспекцию программ?
В Gerrit(е)?
github
На самом деле если в организации нет Gerrit(а) или другого инструмента для инспекции программ (например Swarm), то говорить про CodeReview не приходится.
Лучше уж для начала поднять в прошивках UART-CLI и модульными тестами код покрыть. Тогда это хотя бы можно будет на том же Jenkins(е) автоматически дергать.
Где Вы храните конфиги для микроконтроллерных сборок?
В DeviceTree?
нет, в хедерах
Чтобы конфиги из some_config.h файлика применились some_config.h надо include(ить) в каждый файл сорцов, где нужны эти конфиги.
А если передавать конфиги из Make скриптов опцией -DHAS_XXXX, то не нужно будет писать повсюду лишние
#include "some_config.h"
Вы добавляете some_config.h через ключи компилятора в MakeFile(лах)?
-include some_config.h
Как известно при сборке из IDE надо вручную прописывать пути к папкам с исходниками в настройках IDE.
Это весьма утомительный и рутийный процесс.
Эти пути потом отражаются в файле .cproject
<listOptionValue builtIn="false" value=""${workspace_loc}/control/generic""/>
<listOptionValue builtIn="false" value=""${workspace_loc}/components/Circular_Buffer""/>
<listOptionValue builtIn="false" value=""${workspace_loc}/adt/array""/>
<listOptionValue builtIn="false" value=""${workspace_loc}/adt""/>
<listOptionValue builtIn="false" value=""${workspace_loc}/computing/math""/>
<listOptionValue builtIn="false" value=""${workspace_loc}/control/free_rtos""/>
<listOptionValue builtIn="false" value=""${workspace_loc}/control/task""/>
<listOptionValue builtIn="false" value=""${workspace_loc}/control/super_cycle""/>
<listOptionValue builtIn="false" value=""${workspace_loc}/control""/>
<listOptionValue builtIn="false" value=""${workspace_loc}/common/code_generator""/>
<listOptionValue builtIn="false" value=""${workspace_loc}/mcal/mcal_common/timer""/>
<listOptionValue builtIn="false" value=""${workspace_loc}/mcal/mcal_common""/>
<listOptionValue builtIn="false" value=""${workspace_loc}/mcal""/>
Есть ли способ при сборке из плагинов Eclipse импортировать пути для GCC извне подобно тому как работает gcc опция -include some_config.h
Почему Вы делаете тестировочные прототипы на фанерке?
Не лучше ли оргстекло? Плексиглас он ведь прозрачный, не перекрывает никаких шильдиков. Прозрачная основа удобнее для отладки.
https://habr.com/ru/articles/709932/
О том что "в embedded DevOps невозможен" мне доказывали не только "очень опытные инженеры" из всяких НИИ “РосПил” но и 28...35 летние Team Lead(ы) некоторых московских контор.
Хороший DevOps не только позволяет уменьшить bus factor до нуля.
Хороший DevOps придает разработке софта положительный азарт, добавляет работе радость и чувство удовлетворения сделанной работой так как всегда видно результат.
Про OpenBMC почитайте. Там сборка под Yocto (ну и гадость эта ваша заливная рыба).
С учетом того, что OpenBMC поддерживают Facebook, Microsoft, Intel и много кто еще - выборка может получиться куда более репрезентативной.
Но очень высокий порог входа туда. Средств отладки в Yocto практически нет. Подключить gdb можно, но столько танцев с саблями придется сделать... То же для IDE - можно, но десять раз вспотеешь.
все производители платформ (intel, AMD, Ampere, etc) к тому же дают свою сборку OpenBMC
Сборки OpenBMC для платформ можно использовать, если они есть. Бывает так, что их пока нет, если платформа совсем новая. Бывает так, что сборки OpenBMC от производителя нет в принципе и появится не скоро, для того же серверного Байкала. Бывает и так, что дизайн платы сделан, как бы это помягче, с особенностями.
Например: вентиляторы висят не на Tach-PWM ногах ASPEED, а на lm63-подобном датчике, подключенном через i2c switch, причем и lm-ка и свич висят на питании хоста, а не на дежурном. И надо думать, как это все прокинуть через конфиг entity-manager. Ну или доработать phosphor-hwmon, чтобы он дергал new_device и delete_device через power events.
драйвера на все популярное есть в ядре
Один из множества примеров. Родной драйвер lm-ки по дефолту PWM не инитит, считая это задачей BIOS (что, в общем, вполне правильно). Т.е. в примере выше его надо дорабатывать, иначе при включении хоста вентиляторы запустятся далеко не сразу. Либо добавлять скрипт инициализации lm в свои рецепты (но проще и надежнее поправить родной драйвер).
Я это все к тому, что как только отходишь от задач типа "а давайте мы на Tioga Pass добавим десяток управляющих релюшек, чтобы конкурс защитить", простота использования OpenBMC куда-то сразу испаряется.
Есть отличный открытый проект flipper zero где можно наслаждаться тем как настроили сборку тесты и кодогенерацию
В репе
https://github.com/flipperdevices/flipperzero-firmware
всё намешано. И USB и UART всё в одной папке валяется.
Сумбурный репозиторий.
Не все в нем идеально, если не сталкивались до этого с проектом, рекомендую как минимум глянуть на их инструмент fbt. Сборка сделана через TaskRunner в VSCode, туда же притянут OpenOCD, инструментарий для тестов и проверки кода. Пользоваться удобнее чем IAR.
С точки зрения embed-ера этот проект новый и свежий.
У самого Флиппера есть и gui и cli и файловая система, и грамотная и удобная система лога.
Сам проект развивается гигантскими шагами и конечно не идеален.
Зачем flipper zero в качестве системы сборки выбрали SCons?
Чем им Make CMake не нравится?
По правде, говоря все мы немного dev ops(ы).
Мы же не вручную код на assembler(е) пишем.
Мы компилятором из абстрактного языка Си генерируем артефакты (*.bin файл).
A это значит что мы DevOps(еры) все.
DevOps для производства Firmware