Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Поток Железо и гаджеты доступен 24/7 благодаря поддержке друзей Хабра
Комментарии 45
Закреплённые комментарии
Ровно до того, пока вкусы по ide совпадают. Меня например рыгать тянет от всяких кубов и прочих специализированных ide.
Ровно до того, пока сборка проекта это просто сборка бинаря, без хитрых ветвлений и зависимостей.
Давно подумываю перейти на CMake в том числе и потому что он автоматически создаёт compile_commands.json. Но пока не понял, как перенести сборку в /tmp. Буду признателен, если подскажете, куда копать.
Суть: в целях экономии ресурса SSD каталог для сборки проекта указываю на /tmp, который у меня в ОЗУ. В случае Makefile это решается просто через переменную builddir (`make builddir=/tmp/myproject`), которая обрабатывается в Makefile. В случае же с CMake обычно сборка происходит в подкаталоге buld в каталоге проекта. И я пока не нашёл способ это изменить.
PROJECT_BINARY_DIR и CMAKE_BINARY_DIR - ошибся.
Страница официальной документации про то, как собирать в другую директорию, но там как всегда мало чего понятно.
Я использую GNU Make для сборки. Собираю на арче. Если вдруг надо из-под винды зайти, то там у меня стоит MSYS MinGW, в котором тоже есть arm-none-eabi-gcc и make. В CMake даже не лезу для микрухи
Спасибо Вам за статьи! Читаю-читаю каждую, и только сейчас заметил, что все они от одного автора)
Интересно, зачем такие вырвиглазные языки делают. Почему бы обычный синткаксис не использовать. Невозможно пользоваться ведь.
Так получилось, так вышло (с)
Интересно, зачем такие вырвиглазные языки делают. Почему бы обычный синткаксис не использовать. Невозможно пользоваться ведь.
Что Вам кажется проще для понимания: GNU Make или CMake?
Для понимания проще отдать это на откуп IDE. Результат будет неотличим от этих ручных ковыряний.
Ровно до того, пока вкусы по ide совпадают. Меня например рыгать тянет от всяких кубов и прочих специализированных ide.
Ровно до того, пока сборка проекта это просто сборка бинаря, без хитрых ветвлений и зависимостей.
Подозреваю, что людей, которых рыгать тянет от всяких cmake и прочих вещей, которые нам завещали предки, гораздо больше.
Меня тоже тошнить от gui-ide. Хочется собирать проекты скриптами.
А от чего не рыгать то? От кубоиде или от иариде что ли?
Отделив билд от редактирования, чувствуешь себя спокойнее, зная, что можешь быстро собрать проект где угодно, настроить ci какие и тп.
Пишу то я в вскод, с клиона перешел, по тем же причинам.
зная, что можешь быстро собрать проект где угодно
Ну если вам часто посреди чиста поля говорят на пеньке что-то вдруг собрать, то может быть, но это как сравнивать автомастерскую с ящиком с инструментами: ящик хоть и портативный, но и возможностей дает куда меньше, чем мастерская. Хотя и тут, скриптолюбцам чтоб настроить тулчейн с нуля скорее всего потребуется больше времени, чем скачать и настроить идешку.
При работе в IDE, если Вы случайно что‑то поменяете в XML (ewp IAR) и сохраните, то в один утренний день у Вас просто не откроется IDE проект.
Знакома такая ситуёвина?
О сборке даже и говорить не придется.
Далее у Вас начнется приступ судороги, конвульсии и паралич.
Нормально так, да?...
Те, кто работают в IDE, обычно не правят XML не через интерфейс, т.к. зачем тогда IDE, да и в этих нагенеренных XML черт ногу сломит.
кто работают в IDE, обычно не правят XML не через интерфейс
Рано или поздно Вам скажут, что надо сделать 55+ конфигураций одной и той же прошивки с косметическими изменениями для разных клиентов.
И Вы замучаетесь мышкой в интерфейсе IDE все это курсором проклёвывать.
Да кто ж спорит, всякому инструменту - свое применение. Если бы мне понадобилось 55 конфигураций одной и той же прошивки или какой-то сложный CD - я б тоже, наверное, нагородил свой сборочный велосипед комбайн. Но сборка в рамках процесса написания кода и отладки также осталась бы в IDE, т.к. 99.9% времени, собственно, разработки уходит обычно не на сборку.
Рано или поздно Вам скажут, что надо сделать 55+ конфигураций одной и той же прошивки с косметическими изменениями для разных клиентов
накину на вентилятор)
у segger можно с полтыка сделать отдельную конфигурации сборки с наследованием свойств от базовой. а дальше переопределить то что душе начальству угодно. коллега так сделал поддержку пачки проектов загрузчиков (штук этак 10). функционал общий, отличие только в железе. Определил нужные настройки параметров через блок DEFINES.
так что аргумент слабоват)))
но согласен, cmake более контролируемый и его проще подружить с CI/CD на гитлаб сервере
в этом случае я делаю так - переменные, задающие конфигурацию сборки/прошивки выносятся в отдельный .h, в исходниках проекта эти переменные анализируются директивами #if define...
На каждый вариант прошивки создается такой файл. При необходимости собрать нужн вариант - в определенное место копируется соотв конфиг файл. Дальше либо из ИДЕ, либо из ком строки это все собирается. В особо извратном случае пишется разлапистый командный файл, который на RAM-диске запускает параллельно несколько потоков сборки. Реальный случай - число конфигураций сборки 101. Собирается в 8 потоков ибо компилятор GHS древней версии однопоточный
PS В другом проекте эти "опции" можно задать в процессе работы прошивки. Изменения применяются после рестарта. Методы решения зависят от задачи
в этом случае я делаю так - переменные, задающие конфигурацию сборки/прошивки выносятся в отдельный .h, в исходниках проекта эти переменные анализируются директивами #if define...
Ок, однако это только 33% решения.
Надо еще в каждую сборку прописать уникальные пути (-Ixxx1/xxx2/xxx3/xxx4 )и добавить уникальные c-файлы.
Как Вы решите остальные 66% проблемы?
Скрипты подготавливаются до степени - вписать команду из редми. Если низя, скрипты кал. (Такое часто, да)
На ci сервере собирать как? Тесты автоматом прогнать там? Я вот люблю иметь билд на х86 всегда еще.
А если вы хотите тех же новомодных агентов подрубить, а в вашем внебрачном сыне эклипса это случится уже к времени когда всех заменят?
Держать проект в IDE это намерено привинчивать себя, потому, что сложно освоить альтернативу. Это звучит неправильно, не находите?
проще отдать это на откуп IDE. Результат будет неотличим от этих ручных ковыряний.
На то у меня есть два развернутых ответа в виде отдельных текстов:
Почему Сборка с Помощью GUI-IDE — это Тупиковый Путь https://habr.com/ru/articles/794206/
Почему важно собирать код из скриптов
https://habr.com/ru/articles/723054/
Если коротко, то GUI-IDE не позволяют масштабироваться при увеличении ассортимента прошивок в организации. В то время как переход на скрипты сборки на порядки повышает производительность труда программиста.
Я сейчас поддерживаю на плаву примерно 150 прошивок. И меня это даже не утомляет, так как все они собираются из скриптов.
Ну смейк все таки довольно ублюдошный язык, ничего тут не попишешь.
А у Вас какая версия STM32CubeMX на хосте? Во всех его свежих (>= v6.x) версиях можно сгенерировать скелет CMake проекта что называется "из коробки".
Во всех его свежих (>= v6.x) версиях можно сгенерировать скелет CMake проекта что называется "из коробки".
У меня 6.9.0 и эта версия не предлагает генерацию проекта на основе CMake.
У меня стоит 6.17.0, там есть. Но по-моему даже с 15-ой версии уже есть
У меня стоит 6.17.0, там есть. Но по-моему даже с 15-ой версии уже есть
Я конечно же попробовал скачать последнюю версию stm32cubeMX, однако внезапно для себя обнаружил, что фирма ST накрыла Россию санкциями и наложила эмбарго.
We apologize for the inconvenience, but in accordance with the European Union's Export Regulation 2021/821, the US Export Administration Regulations (EAR), and other relevant rules and regulations, ST is not authorized to allow the download of this software from your country.
перевод на русскую словесность
"Приносим извинения за неудобства, но в соответствии с Регламентом Европейского союза об экспорте 2021/821, Правилами экспортного контроля США (EAR) и другими соответствующими правилами и положениями, компания ST не имеет права разрешать загрузку данного программного обеспечения из вашей страны."
Вот скриншот в доказательство
Есть ли возможность, пожалуйста, прислать Ваш дистрибутив утилиты stm32cubeMX версии 6.17.0?
У меня стоит 6.17.0, там есть. Но по-моему даже с 15-ой версии уже есть
В самом деле. STM32CubeMX Version 6.16.0 может сгенерировать шаблон для CMake проекта
появились скрипты
Честно говоря, вот этот их скрипт CMake из кубика, он довольно стрёмный. Его даже трогать не очень хочется. НО. В отличие от stm32-cmake, который я в своей статье использовал, он подтягивает ту версию, которая указана в кубике, и HAL в ваших файлах и в библиотечных будет одной версии.
Эта проблема решается довольно просто, и я всё хочу сделать свой тулчейн под это, но руки никак не дойдут. Чтобы это работало, и при этом не надо было подтягивать внутрь каждого проекта библиотеки кубика, и заваливать ими свой гит сервер, можно подключать GitHub репозитории STM HAL/CMSIS/etc как git submodule.
У этого подхода есть и другой плюс: для сборки на других ПК достаточно будет лишь наличия cmake и gcc. И на CI/CD это кладётся намного лучше, чем загрузка этих же репозиториев, но в папку build (по каждой сборке, ага) и захардкоженной в stm32-cmake версией.
Однажды у меня появится свободное время, и я этим займусь. Однажды)
Бинарь разрастается в размере
но как??? Как так то!!!
вроде как надо просто контролировать размер бинарника после любых изменений и тогда никаких сюрпризов не будет. Будет точно известно какие изменения привели к разрастанию бинарника, система сборки тут вроде бы особо не при чем, разве что ворнинг или ошибку выдавать о превышении заданного-предельного размера бинарника.
Вообще увлечение темплейтами С++ и любыми другими средствами неявной генерации кода обычно является главной причиной непомерного разрастания бинарников.
Как вариант - добавляется ненужный код из библиотек. Какие-то управляющие флаги отсутствуют. Автор пишет - Cmake подмешивает компоновщику ненужные ключи. А нужные ключи и флаги наоборот отсутствуют.
Давно подумываю перейти на CMake в том числе и потому что он автоматически создаёт compile_commands.json. Но пока не понял, как перенести сборку в /tmp. Буду признателен, если подскажете, куда копать.
Суть: в целях экономии ресурса SSD каталог для сборки проекта указываю на /tmp, который у меня в ОЗУ. В случае Makefile это решается просто через переменную builddir (`make builddir=/tmp/myproject`), которая обрабатывается в Makefile. В случае же с CMake обычно сборка происходит в подкаталоге buld в каталоге проекта. И я пока не нашёл способ это изменить.
Переопределите переменную CMAKE_BUILD_DIR (вот тут все остальные переменные, которые могут пригодится). И можете загуглить про CMakePresets.json - для чего он нужен и как им пользоваться - может сильно помочь.
Переопределите переменную
CMAKE_BUILD_DIR(вот тут все остальные переменные
Там нет переменной CMAKE_BUILD_DIR
PROJECT_BINARY_DIR и CMAKE_BINARY_DIR - ошибся.
Страница официальной документации про то, как собирать в другую директорию, но там как всегда мало чего понятно.
Сделать это с помощью CMake Presets - отличный вариант (через binaryDir).
Modifying
CMAKE_BINARY_DIRhas undefined behavior.
https://cmake.org/cmake/help/latest/variable/CMAKE_BINARY_DIR.html
Вы точно предлагаете менять переменную, про которую написано, что её изменение имеет неопределённое поведение?
cmake генерирует проект в текущей папке или в указанной ключом -B. Можно сделать, например так:
cmake -S path/to/source -B /tmp/path/to/build # сгенерировать скрипты сборки, по-умолчанию - Makefile
cmake --build /tmp/path/to/build # собрать всё при помощи скриптов сборки
Я использую GNU Make для сборки. Собираю на арче. Если вдруг надо из-под винды зайти, то там у меня стоит MSYS MinGW, в котором тоже есть arm-none-eabi-gcc и make. В CMake даже не лезу для микрухи
Фраза "Кто умеет, делает; кто не умеет, учит других" как никогда уместна. Автор всю дорогу путает переменные окружения и переменные в Cmake, неправильно использует функции, исходники для target добавляет через string переменные. Не нужен вам Cmake, уж лучше по старинке через make.
Тем не менее прошивка собралась и, внезапно, завелась!
Лично мне GNU Make больше по нутру, нежели CMake. Не скрою.
Почему бы Вам не написать свою правильную методичку по CMake?
А за одно и продолжнить пословицу до конца.
"Кто умеет, делает; кто не умеет, учит других, кто не умеет учить других и делать тот становится .... "
Советую искать способы писать на cmake компактно. Чем дальше пишу - тем больше интересного нахожу. Вот минимально обфусцированный пример из моей практики:
toolchain-arm-cortex-m4.cmake
set(CMAKE_SYSTEM_NAME Generic)
set(CMAKE_C_COMPILER arm-none-eabi-gcc)
set(BIN2HEX arm-none-eabi-objcopy -O ihex)
set(C_COMPILER_VERSION_MIN "9.2")
set(CMAKE_C_FLAGS "-mcpu=cortex-m4 -mthumb -nostartfiles -ffreestanding -fno-strict-aliasing -mno-unaligned-access -fno-pie -mfpu=vfp -mfloat-abi=hard")
set(CMAKE_FIND_ROOT_PATH /usr/lib/arm-none-eabi)
# adjust the default behavior of the FIND_XXX() commands:
# search programs in the host environment
set(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER)
# search headers and libraries in the target environment
set(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY)
set(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY)
CMakeLists.txt
cmake_minimum_required (VERSION 3.16)
project(app LANGUAGES C ASM)
set(CMAKE_C_STANDARD 99)
set(CMAKE_C_STANDARD_REQUIRED ON)
set(OPTIMIZATION_FLAGS "-O2")
set(TARGET_EXE "app.elf")
set(HW_DIR "hw/STM32F4xx")
set(SOURCE_COMMON
SRC/crc.c
SRC/main.c
SRC/debug.c
SRC/spi.c
SRC/timer.c
SRC/adc.c
SRC/dma.c
)
set(SOURCE_HW
SRC/${HW_DIR}/vectors.c
SRC/${HW_DIR}/api.c
)
set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -g -Wall ${OPTIMIZATION_FLAGS}")
include_directories(SRC SRC/${HW_DIR})
add_executable(${TARGET_EXE} ${SOURCE_COMMON} ${SOURCE_HW})
add_custom_target(app.hex ALL
COMMAND ${BIN2HEX} ${TARGET_EXE}
DEPENDS ${TARGET_EXE}
)
build.bat
rmdir build_stm32 /s /q
md build_stm32
cmake -G Ninja -DCMAKE_TOOLCHAIN_FILE=..\toolchain-arm-cortex-m4.cmake -S . -B build_stm32
cmake --build build_stm32 -j 20
В случае винды - нужно отдельно прилагать усилия, чтобы все используемые программы и компилятор были добавлены в PATH. Поскольку это не всегда так на рабочем компе - в репозитории лежит set_path_template.bat. Каждый разработчик может его скопировать в свой set_path.bat и настроить свои пути, например так: SET PATH=c:\Program Files (x86)\GNU Tools Arm Embedded\9 2019-q4-major\bin;%PATH%. Файл set_path.bat добавлен в .gitignore.
И конечно же в корне репозитория обязателен readme.md, где написано, где всё скачать, как установить, настроить, запустить.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
STM32 + GCC + CMake + Win10