В программировании микроконтроллеров на электронных платах на выходе всегда получается довольно много артефактов. Это прошивка, документация, отладочная инфа.
По мере возможности всё это добро надо как-то связать и заточить в один архив, чтобы всегда можно было ассоциировать .hex с нужным для него .map и .elf. Также один архив очень удобен при транспортировке программного обеспечения железнодорожными видами транспорта ).
Логичным шагом будет являться архивация всех этих файликов в *.tar архив, чтобы всё это не рассыпалось по жесткому диску.
Терминология
Артефакты (Artifact) в контексте программирования микроконтроллеров артефакты - это то полезное, что кристаллизируется на выходе tool chain(а). В самом общем случае это
№ |
Расширение |
type |
Назначение |
1 |
*.hex |
text |
бинарный образ прошивки в ASCI символах |
2 |
*.bin |
bin |
Бинарный образ прошивки |
3 |
*.elf |
bin |
образ с отладочными символами для пошаговой отладки |
4 |
*.map |
text |
спецификация разметки памяти |
5 |
*.gv |
text |
граф зависимостей программных компонентов на Graphviz |
6 |
? |
? |
doxygen документация на ПО |
7 |
*.fw |
bin |
бинарь прошивки с цифровой подписью |
8 |
... |
... |
прочее |
Фактически артефакты - это и есть результат работы программиста микроконтроллера для бизнеса.
Некоторые также называют артефакты словом дистрибутив.
Постановка задачи
Надо реализовать автоматическую архивацию артефактов прошивки. Написать один общий для всех проектов make скрипт для упаковки артефактов. Вмонтировать это действие в общий конвейер сборки любого проекта из репозитория.
Реализация
Для этого можно воспользоваться классической утилитой tar. Это консольная утилита для архивирования файлов. Вот её справка.
tar -h
tar(bsdtar): manipulate archive files
First option must be a mode specifier:
-c Create -r Add/Replace -t List -u Update -x Extract
Common Options:
-b # Use # 512-byte records per I/O block
-f <filename> Location of archive (default \\.\tape0)
-v Verbose
-w Interactive
Create: tar -c [options] [<file> | <dir> | @<archive> | -C <dir> ]
<file>, <dir> add these items to archive
-z, -j, -J, --lzma Compress archive with gzip/bzip2/xz/lzma
--format {ustar|pax|cpio|shar} Select archive format
--exclude <pattern> Skip files that match pattern
-C <dir> Change to <dir> before processing remaining files
@<archive> Add entries from <archive> to output
List: tar -t [options] [<patterns>]
<patterns> If specified, list only entries that match
Extract: tar -x [options] [<patterns>]
<patterns> If specified, extract only entries that match
-k Keep (don't overwrite) existing files
-m Don't restore modification times
-O Write entries to stdout, don't restore to disk
-p Restore permissions (including ACLs, owner, file flags)
bsdtar 3.5.2 - libarchive 3.5.2 zlib/1.2.5.f-ippНам понадобятся только вот эти опции утилиты tar
ключ |
назначение |
-? |
показать короткую справку по ключам утилиты |
-f |
путь и имя результирующего файла архива |
-v |
Активировать логирование. Показать что именно будет заархивированно. |
--version |
показать версию программы |
-с |
Префикс после которого через пробел надо перечислить полные пути к тем файлам, которые мы хотим поместить в архив |
Надо организовать вот такой конвейер обработки файлов
Для начала поэкспериментируем в windows cmd. Вот этим скриптом в принципе можно решить задачу.
echo off
cls
set project_name=boardname_appname_m
set project_dir=%cd%
set artefact_dir=%project_dir%\build
echo project_dir=%project_dir%
set FILES_TO_PACK=%artefact_dir%\%project_name%.map
set FILES_TO_PACK=%artefact_dir%\%project_name%.bin %FILES_TO_PACK%
set FILES_TO_PACK=%artefact_dir%\%project_name%.elf %FILES_TO_PACK%
set FILES_TO_PACK=%artefact_dir%\%project_name%.hex %FILES_TO_PACK%
set FILES_TO_PACK=%artefact_dir%\%project_name%.jpeg %FILES_TO_PACK%
set FILES_TO_PACK=%artefact_dir%\%project_name%.pdf %FILES_TO_PACK%
set FILES_TO_PACK=%artefact_dir%\%project_name%.svg %FILES_TO_PACK%
set FILES_TO_PACK=%artefact_dir%\%project_name%_dep.gv %FILES_TO_PACK%
echo artefact_dir=%artefact_dir%
echo FILES_TO_PACK=%FILES_TO_PACK%
tar.exe -v -f %artefact_dir%\%project_name%.tar -c %FILES_TO_PACK% --Однако система сборки у меня Make поэтому надо написать общий на все сборки скрипт для упаковки файлов. Вот так может выглядеть make скрипт archive_artifacts.mk для упаковки бинарей в архив
$(info ArchiveArtifactsScript)
TIME_STAMP_FILE = $(BUILD_DIR)/time_stamp.txt
FILES_TO_PACK += $(TIME_STAMP_FILE)
FILES_TO_PACK += $(BUILD_DIR)/$(TARGET).pdf
FILES_TO_PACK += $(BUILD_DIR)/$(TARGET).svg
FILES_TO_PACK += $(BUILD_DIR)/$(TARGET).jpeg
FILES_TO_PACK += $(BUILD_DIR)/$(TARGET)_dep.gv
FILES_TO_PACK += $(BUILD_DIR)/$(TARGET).map
FILES_TO_PACK += $(BUILD_DIR)/$(TARGET).elf
FILES_TO_PACK += $(BUILD_DIR)/$(TARGET).hex
FILES_TO_PACK += $(BUILD_DIR)/$(TARGET).bin
ARCHIVE_FILE := $(TARGET).tar
.PHONY: compose_time_stamp
compose_time_stamp:
$(info ComposeTimeStamp)
$(info TIME_STAMP_FILE=$(TIME_STAMP_FILE))
$(shell date > $(TIME_STAMP_FILE))
.PHONY: archive_artifacts
archive_artifacts: compose_time_stamp generate_dep auto_version_target
$(info BUILD_DIR=$(BUILD_DIR))
$(info FILES_TO_PACK=$(FILES_TO_PACK))
$(info ARCHIVE_FILE=$(ARCHIVE_FILE))
$(info Archive Artifacts...)
tar.exe -v -f $(ARCHIVE_FILE) -c $(FILES_TO_PACK) --
После отработки этого скрипта в папке build (BUILD_DIR) корня проекта появляется *.tar архив с бинарями. Сюда же в архив капнет временная отметка time_stamp.txt, чтобы показывать насколько эта сборка новая.
Итоги
Удалось добавить автоматическое архивирование бинарей в общий процесс сборки проекта.
Ссылки
# |
название |
URL |
1 |
Create .zip folder from the command line - (Windows) |
https://superuser.com/questions/201371/create-zip-folder-from-the-command-line-windows |
2 |
TAR - архивирование данных в Windows 10. |
Комментарии (31)
kotC9
04.07.2024 16:32+1а почему не решать эту задачу путем ci job artifacts?
заодно исчезнет привязка к винде (tar.exe) и к makefile. появится ссылка на коммит, из которого были сделаны артефакты
aabzel Автор
04.07.2024 16:32+1Тот же CI в jenkins вынуждает прописывать вручную список файлов для каждой сборки. А в make код формирования архива сосредоточен в одном месте.
kotC9
04.07.2024 16:32решается переменными в том же gitlab ci. при этом переменные будут задаваться автоматически(например в BUILD_DIR вкидываем build, а в TARGET вкидываем название проекта, затем выгружаем артефакты), будет один конфиг на все сборки
Sap_ru
04.07.2024 16:32А чего бы не CMAKE использовать?
aabzel Автор
04.07.2024 16:32Лучше gnu Make никто в мире так ничего и не придумал.
Vladislav_Dudnikov
04.07.2024 16:32+2ninja scons waf
На самом деле шучу, Makefile удобен, в первую очередь, тем, что он есть везде.
le2
04.07.2024 16:32+2Внимание, дальше токсичный комментарий, который написан не с целью возвысится, а с целью заставить задуматься.
Статья - иллюстрация того почему embedded плохо оплачивается. В этом деле уже через пару недель легко словить звезду, потому что большая часть проблем можно решить без интернета, только читая документацию (сам таким был). Становится ощущение что ты можешь всё, ты особенный и можешь добывать решения только выковыривая их из носа. А программисты микроконтроллеров это отдельная каста и на них современные методы разработки не распространяются.
На самом деле суровая правда - большая часть эмбеддед разработки это разработка уровня 199x годов. С плохой коллективной работой, с плохой передачей знаний, с очень низкой эффективностью и с некачественной кодовой базой.
Правильное решение для документооборота должно быть, как и везде сейчас, что-то типа GIT + Jenkins + GitLab + Jira
(последний раз такой колхоз я видел в 2005 году и примерно тогда же перевел всех на SVN)aabzel Автор
04.07.2024 16:32с некачественной кодовой базой.
Что является атрибутами качественной кодовой базы?
aabzel Автор
04.07.2024 16:32Правильное решение для документооборота должно быть, как и везде сейчас, что-то типа GIT + Jenkins + GitLab + Jira
Я работаю в embedded. У нас сейчас есть GIT, Jira и Jenkins (правда Jenkins крутится пока только на локальном PC)
aabzel Автор
04.07.2024 16:32на них современные методы разработки не распространяются.
Что Вы вкладываете в понятие "современные методы разработки"?
tandzan
04.07.2024 16:32+2Из личного опыта - соотечественники делятся разработанными прошивками приложением zip архива к сообщениям (на форуме с самописным движком). Новая версия - новый архив. Бывает код прям кровь из глаз. Или в размеренное обсуждение на eevblog врывается соотечественник с фотографиями экрана осциллографа с метрового расстояния и карандашными рисунками схем.
aabzel Автор
04.07.2024 16:32карандашными рисунками схем
Современных российских инженеров электронщиков надо обучать самым базовым основам компьютерной графики.
Чтобы умели пользоваться хотя бы программой inkscape.
aabzel Автор
04.07.2024 16:32Или в размеренное обсуждение на eevblog врывается соотечественник с фотографиями экрана осциллографа с метрового расстояния
Дело в том, что на многих российских предприятия часто можно встретить аналоговые электронно-лучевые осциллографы и там просто нет USB порта, чтобы установить USB накопитель. Вот и приходится фотографировать.
aabzel Автор
04.07.2024 16:32Из личного опыта - соотечественники делятся разработанными прошивками приложением zip архива к сообщениям . Новая версия - новый архив.
А как по-вашему следует передавать прошивку для платы, если не архивом через messenger? Всегда и везде же так делают.
tandzan
04.07.2024 16:32+2Ошибся, хотел сказать "исходники прошивки". Особое удовольствие ее искать в обсуждении на тысячу страниц, в двух-трех частях. Один что-то свое добавил, кто-то другое, сиди несколько вечеров, ковыряй. Системы контроля версий уже наверно даже в школе проходят (шутка).
aabzel Автор
04.07.2024 16:32У меня был начальник-схемотехник он часто говорил:
--SVN/GIT не нужен так как у нас только один программист-микроконтроллеров.
aabzel Автор
04.07.2024 16:32с плохой передачей знаний
Пишите заметки на habr вот и будет Вам работать передача знаний.
aabzel Автор
04.07.2024 16:32+4Статья - иллюстрация того почему embedded плохо оплачивается
Вовсе не по этому. Просто специфика разработки электроники такая.
В разработке прошивок в принципе не может быть никакой монетизации, как в Web сайтах. Никто не будет вам платить 10$ в месяц за аккаунт в прошивке. Это было бы ну просто смешно.Цена прошивки без физического устройства 0 рублей 0 копеек. Продажи прошивок жестко ограничены продажами электронных устройств, которые крутят эти прошивки. А количество электронных устройств жестко ограничено производственными возможностями конкретной организации. При этом в России нет массового производства никакой электроники. Просто былая промышленность СССР утрачена, продана, угроблена.
В нынешних российских электронных организациях как правило мелкая серия электроники 100..500 штучек чего-либо за весь жизненный цикл продукта. Причем сами электронные платы обычно паяют в подвалах вручную 2...3 тётушки бальзаковского возраста. Выглядит всё это очень удручающе. В yield(де) как правило 60% брака. Сами понимаете, что много народных гаджетов так не наклепаешь.
При этом стоимость конечного российского изделия на MCU (какой-нибудь пресловутый СКУД) редко превышает 10k...30k RUB.
Вот ещё, например, компания ГК Телесистемы, которая сделала на микроконтроллере крутой нишевый диктофон и страдает от того, что продажи слишком низкие, и невозможно инвестировать в развитие и рост организации и повышение зарплаты программистам. https://habr.com/ru/articles/822375/
Ну сами представьте, сколько может стоить работа по написанию I2C драйвера для микросхемы AT24C02M5 стоимость которой 11 рублей (0,12 USD)? И какое отношение у предпринимателей к такой работе?...
Поэтому программисты микроконтроллеров - самые низкооплачиваемые программисты в России 42k..70k RUR/меc, работающие в массе своей за идею.
Просьба относиться к этому с пониманием...
Lorindo
04.07.2024 16:32+1Добрый день. Хочу написать коментарий с несогласием с вашими выводами о причинах низкой оплаты embedded. На мой взгляд причина в том что embedded это крайне рискованная ниша. Потому что в большинстве случаев требуется сразу сделать готовый продукт без багов и учесть весь функционал - обновление железа точно не сделать по ci/cd а бывает что и прошивку не передать на конечное устройство. А это очень не просто. Даже если сделать все достаточно хорошо - нужно ещё продать. Тут наслаивается слабость бизнес культуры на всем постсовковом пространске и высокая конкуренция со стороны западных стран - фирм, которых уже позанимали все сладкие места в продуктах нужных всему миру, у которых налажен процесс работы, сбыта продукта, инженерии, есть финансы для R&D и экспериментов - ведь не факт что всегда получается и небольшая молодая компания может просто разориться если вложит в провальный продукт, и так не большие ресурсы. В сегменте массово и дешего доминируют китайские фирмы - у них дешовые ресурсы и опыт масштабирования.
Итого остаются проекты где то по середине, обычно они не самые лакомые с точки зрения денег и ввиду необходимости продавать, опыта в чем нет/мало и без ресурсов на маркетинг, остается только работа на локальный рынок для дяди пети, которого ещё попробуй уговори что-то купить. У дяде Пете часто ваш этот интернет ***** не нужон. У него есть баба клава и вася которые будут все руками делать. Потому что уровень конкуренции и как результать уровень культуры/автоматизации производства, обычно не высокий.
На это все накладывется изоляция из-за мудрых решений - конфликтовать с теми с кем нужно налаживать связи и торговать.
Итого embedded тут находится в условниях - когда инвесторы предпочитают более простые и менее рискованные вложения т.к. ещё не все низко висящие яблоки сорваны, проблема с кадрами и процессами, высокая конкуренция на мировом рынке.
Как результат ЗП низкие потому что доходы низкие и нет конкуренции за кадры.
Что касается совковой промышленности то тут я думаю проблема в том что производили оружие, а когда он развалился оказалось что в условиях когда люди могут хотя бы от части выбирать на что тратить свои средства, ни кто не хочет тратить на оружие по 40-60% своего бюджета. Что логично, на мой взгляд.
В любом случае со временем будет все меньше возможностей инвестировать в простые бизнесы, накопиться культура предпринимательства, конкренция вырастет - будет больше хорошо оплачиваемых вакансий в мире embedded. Но вот когда это наступит - я вам не скажу. ))
aabzel Автор
04.07.2024 16:32и высокая конкуренция со стороны западных стран фирмы из которых уже позанимали все сладкие места в продуктах нужных всему миру, у которых налажен процесс работы, сбыта продукта, инженеров, есть финансы для R&D и экспириментов
Но Россия же не из космоса высадилась на Землю в 1991 году.
Вот только интересно в какой момент Россия повернула не туда и так отстала в HiTech технологиях?В любом случае со временем будет все меньше инвестировать в простые бизнесы, накопиться культура предпринимательства, конкренция вырастет - будет больше хорошо оплачиваемых вакансий в мире embedded. Но вот когда это наступит - я вам не скажу. ))
Моя ставка: это произойдет в России не раньше чем через 200 лет...
Lorindo
04.07.2024 16:32Вот только интересно в какой момент Россия повернула не туда и так отстала в HiTech технологиях?
На мой взгляд с потребительскими товарами всегда было слабо. Если бы не СССР с его плановой экономикой, думаю уже были бы фирмы которые делают то что нужно не для войны а обычным людям. А HiTech обычно это крупные технологические фирмы которым нужны новинки что бы быть их товары были самыми привлекательными.
Но Россия же не из космоса высадилась на Землю в 1991 году.
Конечно не из космоса, но опыта создания потребительских товаров и работы на международном рынке не было. Потому что в СССР за частную инициативу и создание товара или услуги, наступало самое суровое наказание и в целом было не возможно. Мне кажется страны после распада прошли уже не малый путь и снизили отставание по доступности и качеству разных товаров и услуг, по сравнению с самыми развитыми мировыми центрами. Уже все не так плого как в 91 году. Если не делать всякие глупости а направить ресурсы в сторону развития, на улучшение качества жизни то ещё пару десятилетий и уже не будет существенной разницы по качеству жизни. Тому пример китай, хоть и диктатура но ввели много аспектов из свободной экономики и уже шутки про голодающих китайцев не уместны, у них средняя ЗП выше чем в РФ.
Моя ставка: это произойдет в России не раньше чем через 200 лет...
Тут конечно возможны разные пути развития особенно сейчас. Имхо от каждого зависит - будем мы торговать со всем миром и участвовать в кооперации или делать глупости.
aabzel Автор
04.07.2024 16:32но опыта создания потребительских товаров и работы на международном рынке не было.
Но СССP поставлял на экспорт самолеты Ан-32 и Як-42
https://www.youtube.com/watch?v=CRy1a7qKLmo&t=10s
aabzel Автор
04.07.2024 16:32высокая конкуренция со стороны западных стран - фирм, которых уже позанимали все сладкие места в продуктах нужных всему миру, у которых налажен процесс работы, сбыта продукта, инженерии, есть финансы для R&D и экспериментов
Да есть такая системная проблема.
В России не выгодно делать разработки новых продуктов. Проблема в том, что рынки давно заняты и переделены.Все комплектующие импортируются. Цены на них таковы, что при таких ценах любой товар разработанный в России получается нежизнеспособным. Слишком дорогим.
——————————————
Выход вижу такой.
Поделить весь мир на две экономические зоны. Две капиталистические экономические системы.
В одной останется весь Западный цивилизованный мир, а во втором Россия и все её союзники ( если таковые конечно найдутся).Затем оградить всю Россию по периметру железобетонной стеной, с электротоком, минными полями, работающими магнетронами, радиоактивными изотопами.
Перекрыть импорт и экспорт.
И развиваться полностью автономно, без обмена материей и информацией с остальными окружающими государствами. Расти медленно, как дерево. Тогда со временем Россия сама пере изобретёт все западные товары и население не будет прозябать в безработице, а инженеры всегда нужными и пристроенными.
aabzel Автор
04.07.2024 16:32На самом деле суровая правда - большая часть эмбеддед разработки это разработка уровня 199x годов.
На самом деле это даже достоинство! Консерватизм!
В профессии программист МК, как в деревне ничего не меняется десятилетиями! Буквально сквозь века (XX-->XXI век).
Си - самый древний язык из тех, что всё еще активно используются. Си(шнику) как и Make(у) уже более 50 лет!Постоянный консерватизм в наборе технологий. Что в 2011 в военном НИИ мы программировали Cortex-M3 в IAR на C с классами для БМП-3, так и c 2021(го) в яНДЕКС.драйв всё так же программируют Cortex-M3 в IAR на С c классами для телематики таксопарка.
Поэтому эта работа идеально подойдет для тех кто не очень-то хочет непрерывно доучиваться всяческим погремушкам.
Обычно в этой профессии кристаллизируются вчерашние ВУЗ(овцы), которые ещё не поняли, что вовремя переметнуться в Java/Python разработку - это лучшее, что может с ними случится в жизни, и много пенсионеров, которые уже просто не могут освоить что-то ещё другое. Ибо с возрастом утрачивается способность мыслить последовательно.
aabzel Автор
04.07.2024 16:32С плохой коллективной работой, с плохой передачей знаний, с очень низкой эффективностью и с некачественной кодовой базой.
Чтобы этого не происходило надо всего-навсего устраивать ежедневные 7минутные планерки.
NutsUnderline
04.07.2024 16:32+1разработка уровня 199x
Только вот почему то то что делали в этих годах работает до сих пор, причем летает на процессоре 2МГц, в то время как разработанный по всем правильным методам современный "продукт" тормозит даже в обычном меню при процессоре 2ГГц
aabzel Автор
04.07.2024 16:32Да. Так и есть.
Люди до сих пор играют в 8бит игры из 199x на приставках SG800 в, то время как современные видеоигры обычно на один сезон и полное забвение.NutsUnderline
04.07.2024 16:32это "несерьезный" случай :) И думаю кроме всяких Вояджеров (а они даже не из 90х) найдутся и отечественные достойные примеры
NutsUnderline
я в свою "систему автоматического бэкапа рабочих файлов" специально добавил фильтрацию расширений большинства артефактов поскольку их легко востановить
а вот промежуточные версии просто архивирую вручную всю папку проекта со всеми файлами, и вот эти архивы та же бэкапилка сохраняет
с учетом того что в бэкапилке есть еще версионность....
aabzel Автор
Я тоже не архивирую *.о *.d *.lst *.i *.su *.pp файлы. Это промежуточные данные.
Я архивирую только то, что нужно для отгрузки: *.bin *.hex *.map *.elf + *.svg файл с деревом зависимостей программных компонентов
Генерация зависимостей внутри программы
https://habr.com/ru/articles/765424/