В период с 199x по 201x на территории РФ развелось очень много программистов-микроконтроллеров (несколько десятков сотен), которые никогда не вылазили из всяческих IDE (IAR, KEIL, Code Composer Studio, Atolic True Studio, CodeVision AVR и прочие). Как по мне, дак это очень печально. Во многом потому, что специалист в Keil не сможет сразу понять как работать в IAR и наоборот. Другие файлы для настроек компоновщика. Другая xml настройки проекта. Миграция на другую IDE тоже вызывает большую трудность, так как это сводится к мышковозне в IDE-GUI. Каждая версия IAR не совместима с более новой версией IDE.
Дело в том, что GUI IDE появились в 199x...201x, когда не было расцвета DevOps(а), программист работал один и все действия выполнялись вручную. Мышкой. В то время работа в GUI казалась программистам-микроконтроллеров веселее, ведь в IDE много стразиков.
Но с усложнением кодовой базы, с увеличением сборок, с увеличением команд разработчиков появилась нужда в переиспользовании кода, нужда в автосборках, в авто тестах. Появилась методология
код отдельно, конфиги отдельно
и работа с IDE стала только тормозить процессы. Ведь конфиги хранятся в IDE-шной XML(ке). Приходилось дублировать конфиги платы для каждой сборки, что использовала эту плату. Пришлось дублировать код конфигов и этот процесс сопровождался ошибками, из-за человеческого фактора. При масштабировании работы с IDE кодовая база фактически превращалась в зоопарк в болоте.
Какие недостатки сборки исходников из-под IDE?
IDE отжирают много ресурсов компьютера, как RAM как и CPU, IDE же надо много оперативки, чтобы отрисовывать окошки со стразиками.
IDE монолитные и неделимые. Если вы захотите поменять препроцессор, компилятор или компоновщик, а остальные фазы ToolChain(а) оставить как есть, то ничего из этого не выйдет, так как капот IDE закрыт на замок.
-
IDE стоят дорого, порядка 3500 EUR на один компьютер.
стоимость IAR
IDE(шные) xml очень слабо документированы или не документированы вовсе. У всех вендоров xml имеет свой особенный снобский язык разметки. При внесении незначительных изменений появляется огромный git diff.
Затруднена сборка из консоли. В основном инициировать сборку в IDE можно мышкой или горячими клавишами.
Обратная несовместимость с новыми версиями IDE
В условиях технологического эмбарго законно купить IDE европейского (Германия, Швеция) вендора невозможно.
В общем распространение IDE это яркий пример известного ныне "технологического диктата" (vendor locking) запада для стран второго и третьего мира.
Мы вам продаём песочницу (IDE), а вы сидите там за бортиками, улыбаетесь и лепите свои, никому ненужные, куличики (прошивки-паршивки).
Понятное дело, что в таких рамках на "сделать что-то серьезное" рассчитывать не приходится. Это мелкая серия. Малый ассортимент. Ручное развертывание.
Пришлось думать. Хорошим решением оказалось сделать шаг назад в 197x 198x когда на компьютерах всё делали из консоли. Собирать сорцы из скриптов! Можно вообще *.bat файл написать и он, в общем-то, инициирует запуск нужных утилит, однако исторически С-код собирали культовой утилитой make.
Junior-embedded программист-микроконтроллеров, привыкший к IDE, может логично провозгласить:
Я вообще не представляю, как без помощи IDE производить пошаговую отладку программы?
Тут есть 4+ ответа:
1--> Использовать связку GDBClient + GDBServer и отлаживать код из командной строки.
https://habr.com/ru/post/694708/
2--> Отлаживать код через интерфейс командной строки CLI поверх UART.
https://habr.com/ru/post/694408/
3--> В коем-то веке покрывать код модульными тестами
https://habr.com/ru/post/698092/
4--> Использовать другие косвенные признаки отладки кода: HeartBeat LED, Утилита arm-none-eabi-addr2line.exe, Assert(ы), DAC, STMStudio, Health Monitor
https://habr.com/ru/post/681280/
В чем достоинства сборки С-кода из make файлов?
Makefile это самый гибкий способ управлять модульностью. Можно буквально одной строчкой добавлять или исключать один конкретный программный компонент (десятки файлов) из десятков сборок. В случае же сборки из-под IDE вам бы пришлось вручную редактировать .xml для каждой сборки.
Сборку из Makefile очень легко автоматизировать. Достаточно в консоли выполнить make all и у вас инициируется процесс сборки.
После сборки из скриптов вы получите полный лог сборки, в то время как IDE обычно показывают последние 3-4 экрана сообщение компилятора.
В MakeFile очень просто менять компиляторы. Это, буквально, заменить одну строчку. С GCC на Clang или на GHS. Вот типичный основной makefile для любой сборки на ARM Cortex-Mxx
mkfile_path := $(abspath $(lastword $(MAKEFILE_LIST)))
$(info Build $(mkfile_path) )
BUILD_DIR = build
#@echo $(error SOURCES_C= $(SOURCES_C))
INCDIR := $(subst /cygdrive/c/,C:/, $(INCDIR))
#@echo $(error INCDIR=$(INCDIR))
SOURCES_C := $(subst /cygdrive/c/,C:/, $(SOURCES_C))
#@echo $(error SOURCES_C=$(SOURCES_C))
SOURCES_ASM := $(subst /cygdrive/c/,C:/, $(SOURCES_ASM))
LIBS := $(subst /cygdrive/c/,C:/, $(LIBS))
LDSCRIPT := $(subst /cygdrive/c/,C:/, $(LDSCRIPT))
#@echo $(error SOURCES_ASM=$(SOURCES_ASM))
# binaries
PREFIX = arm-none-eabi-
GCC_PATH="C:/Program Files (x86)/GNU Arm Embedded Toolchain/10 2021.10/bin"
$(info GCC_PATH=$(GCC_PATH))
# The gcc compiler bin path can be either defined in make command via GCC_PATH variable (> make GCC_PATH=xxx)
# either it can be added to the PATH environment variable.
ifdef GCC_PATH
CC = $(GCC_PATH)/$(PREFIX)gcc
AS = $(GCC_PATH)/$(PREFIX)gcc -x assembler-with-cpp
CP = $(GCC_PATH)/$(PREFIX)objcopy
SZ = $(GCC_PATH)/$(PREFIX)size
else
CC = $(PREFIX)gcc
AS = $(PREFIX)gcc -x assembler-with-cpp
CP = $(PREFIX)objcopy
SZ = $(PREFIX)size
endif
HEX = $(CP) -O ihex
BIN = $(CP) -O binary -S
# float-abi
ifeq ($(NRF5340), Y)
ifeq ($(CORE_NET), Y)
FLOAT-ABI = -mfloat-abi=soft
OPT += -fsingle-precision-constant
endif
ifeq ($(CORE_APP), Y)
FLOAT-ABI = -mfloat-abi=hard
endif
else
FLOAT-ABI = -mfloat-abi=hard
endif
# mcu
MCU = $(CPU) -mthumb $(FPU) $(FLOAT-ABI)
# macros for gcc
#CSTANDARD = -std=c11
CSTANDARD = -std=gnu99
# AS defines
AS_DEFS =
# AS includes
AS_INCLUDES =
ifeq ($(DEBUG), Y)
#@echo $(error DEBUG=$(DEBUG))
CFLAGS += -g3 -gdwarf-2 -ggdb
OPT += -O0
else
OPT += -Os
endif
OPT += -fmessage-length=0
OPT += -fsigned-char
OPT += -fno-common
OPT += -fstack-usage
OPT += -finline-small-functions
#Perform dead code elimination
OPT += -fdce
#Perform dead store elimination
OPT += -fdse
# compile gcc flags
ASFLAGS = $(MCU) $(AS_DEFS) $(AS_INCLUDES) $(OPT) -Wall -fdata-sections -ffunction-sections
CFLAGS += $(CSTANDARD)
CFLAGS += -Wall
#CFLAGS += -Wformat-overflow=1
CFLAGS += $(MCU) $(OPT) -fdata-sections -ffunction-sections $(INCDIR)
# Generate dependency information
CFLAGS += -MMD -MP -MF"$(@:%.o=%.d)"
# LDFLAGS
# libraries
LINKER_FLAGS += -Xlinker --gc-sections
ifeq ($(MBR), Y)
#@echo $(error MBR=$(MBR))
LIBS += -lnosys
LDFLAGS += -specs=nano.specs
else
LINKER_FLAGS += -u _scanf_float
LINKER_FLAGS += -u _printf_float
endif
#LINKER_FLAGS += -lrdimon --specs=rdimon.specs
ifeq ($(LIBC), Y)
#@echo $(error LIBC=$(LIBC))
LIBS += -lc
endif
ifeq ($(MATH), Y)
#@echo $(error MATH=$(MATH))
LIBS += -lm
endif
#@echo $(error LDSCRIPT=$(LDSCRIPT))
LIBDIR =
LDFLAGS += $(MCU) -T$(LDSCRIPT) $(LIBDIR) $(LIBS) -Wl,-Map=$(BUILD_DIR)/$(TARGET).map,--cref -Wl,--gc-sections $(LINKER_FLAGS)
# default action: build all
all: $(BUILD_DIR)/$(TARGET).elf $(BUILD_DIR)/$(TARGET).hex $(BUILD_DIR)/$(TARGET).bin
# build the application
# list of objects
OBJECTS = $(addprefix $(BUILD_DIR)/,$(notdir $(SOURCES_C:.c=.o)))
vpath %.c $(sort $(dir $(SOURCES_C)))
# list of ASM program objects
OBJECTS += $(addprefix $(BUILD_DIR)/,$(notdir $(SOURCES_ASM:.S=.o)))
vpath %.S $(sort $(dir $(SOURCES_ASM)))
$(BUILD_DIR)/%.o: %.c Makefile | $(BUILD_DIR)
$(CC) -c $(CFLAGS) -Wa,-a,-ad,-alms=$(BUILD_DIR)/$(notdir $(<:.c=.lst)) $< -o $@
$(BUILD_DIR)/%.o: %.S Makefile | $(BUILD_DIR)
$(AS) -c $(CFLAGS) $< -o $@
$(BUILD_DIR)/$(TARGET).elf: $(OBJECTS) Makefile
$(CC) $(OBJECTS) $(LDFLAGS) -o $@
$(SZ) $@
$(BUILD_DIR)/%.hex: $(BUILD_DIR)/%.elf | $(BUILD_DIR)
$(HEX) $< $@
$(BUILD_DIR)/%.bin: $(BUILD_DIR)/%.elf | $(BUILD_DIR)
$(BIN) $< $@
$(BUILD_DIR):
mkdir $@
# clean up
clean:
-rm -fR $(BUILD_DIR)
# dependencies
-include $(wildcard $(BUILD_DIR)/*.d)
# *** EOF ***5--Когда вы собираете из Make вы можете не только собирать исходники, но и собирать документацию, строить графы зависимостей на dot, построить схему ToolChain(а). Вызвать Latex, Doxygen.
Утилите make всё равно какие консольные утилиты вызывать. Это универсальный способ определения программных конвейеров.
Для каждой сборки надо самим писать крохотный Makefile
MK_PATH:=$(dir $(realpath $(lastword $(MAKEFILE_LIST))))
#@echo $(error MK_PATH=$(MK_PATH))
WORKSPACE_LOC:=$(MK_PATH)../../
INCDIR += -I$(MK_PATH)
INCDIR += -I$(WORKSPACE_LOC)
#@echo $(error SOURCES_C=$(SOURCES_C))
include $(MK_PATH)config.mk
include $(MK_PATH)cli_config.mk
include $(MK_PATH)diag_config.mk
include $(MK_PATH)test_config.mk
include $(WORKSPACE_LOC)code_base.mk
include $(WORKSPACE_LOC)rules.mk
и конфиг для сборки.
mkfile_path := $(abspath $(lastword $(MAKEFILE_LIST)))
$(info Build $(mkfile_path) )
TARGET=pastilda_r1_1_generic
#@echo $(error TARGET=$(TARGET))
AES256=Y
ALLOCATOR=Y
......
USB_HOST_HS=Y
USB_HOST_PROC=Y
UTILS=Y
XML=Y
Для каждого компонента *.mk файл. Язык make простой. Он, в сущности, очень похож на bash. Вот типичный *.mk файл для драйвера UWB радио-трансивера DW1000.
ifneq ($(DWM1000_MK_INC),Y)
DWM1000_MK_INC=Y
DWM1000_DIR = $(DRIVERS_DIR)/dwm1000
mkfile_path := $(abspath $(lastword $(MAKEFILE_LIST)))
$(info Build $(mkfile_path) )
$(info + DWM1000)
INCDIR += -I$(DWM1000_DIR)
OPT += -DHAS_DWM1000
OPT += -DHAS_DWM1000_PROC
OPT += -DHAS_UWB
DWM1000_RANGE_DIAG=Y
DWM1000_RANGE_COMMANDS=Y
DWM1000_OTP_COMMANDS=Y
DWM1000_OTP_DIAG=Y
SOURCES_C += $(DWM1000_DIR)/dwm1000_drv.c
include $(DWM1000_DIR)/otp/dwm1000_otp.mk
include $(DWM1000_DIR)/registers/dwm1000_registers.mk
ifeq ($(DWM1000_RANGE),Y)
include $(DWM1000_DIR)/range/dwm1000_range.mk
endif
ifeq ($(DIAG),Y)
ifeq ($(DWM1000_DIAG),Y)
$(info +DWM1000_DIAG)
OPT += -DHAS_DWM1000_DIAG
SOURCES_C += $(DWM1000_DIR)/dwm1000_diag.c
endif
endif
ifeq ($(CLI),Y)
ifeq ($(DWM1000_COMMANDS),Y)
$(info +DWM1000_COMMANDS)
OPT += -DHAS_DWM1000_COMMANDS
SOURCES_C += $(DWM1000_DIR)/dwm1000_commands.c
endif
endif
endif
Параллельное написание Make файлов и С-кода стимулирует придерживаться модульности, изоляции программных компонентов и к прослеживанию зависимостей между компонентами. Если вы пишите код и make файлы примерно параллельно, то очень вероятно, что у вас получится чистый, аккуратный репозиторий сам собой.
Makefile(лы) хороши тем, что можно добавить много проверок зависимостей и assert(ов) на фазе отработки Make-скриптов прямо в *.mk файлах еще до компиляции самого кода, даже до запуска препроцессора, так как язык программирования make поддерживает условные операторы и функции. Можно очень много ошибок отловить на этапе отработки утилиты make.
Язык make очень прост. Вся спека GNU Make это всего 226 страниц. Cтю Фельдман (автор make) просто гений.
Makefile(лы) прозрачные потому что текстовые. Всегда видно, где опции препроцессора, где ключи для компилятора, а где настройки для компоновщика. Всё, что нужно можно найти утилитой grep в той же консоли от GIT-bash даже при работе в Windows 10.
Конфиг для сборки можно формировать как раз на стадии make файлов и передавать их как ключи для препроцессора. Таким образом конфиги будут видны в каждом *.с файле проекта и не надо вставлять #include(ы) c конфигами. Всё можно передать как опции утилите cpp (препроцессора).
Вывод
В наше время гордится навыками пользования всяческими IDE должно быть уже стыдно.
Настало время, чтобы российских программистов-микроконтроллеров из детского садика под названием "GUI-IDE" перевести, наконец, в школу (т.е. приучить к makefile или хотя бы к CMake).
Надо смотреть в сторону Make, CMake. Make это как пуговицы. Старая, простая и очень полезная вещь.
Собираете свои прошивки из make в этом нет ничего сложного.
Links
https://www.youtube.com/watch?v=vmuO4bHjTSo&t=7s
https://habr.com/ru/post/47513/
Комментарии (56)
victor_1212
00.00.0000 00:00статья заслуживает внимания, конечно это типа начального чтения, для более серьезного например YOCTO -
aabzel Автор
00.00.0000 00:00-4YOCTO это для Linux(ов). В Linux как раз программировать умеют.
В РФ проблема в том, чтобы программистов-микроконтроллеров из детского садика (IDE) перевести ,каконец, в школу (т.е. приучить к makefile).
mentin
00.00.0000 00:00+4В embedded разработке makefile по старинке ручками пишут, всякие autotools / configure для автоматизации, или альтернативы вроде bazel не распространены?
victor_1212
00.00.0000 00:00+1в embedded используют все что подходит по требованиям, например кроме Linux VxWorks 653, makefiles типа полезный ликбез, который всегда пригодится, посмотрите AECS (4.3 Build Subsystem ) -
https://ntrs.nasa.gov/api/citations/20160000333/downloads/20160000333.pdf
aabzel Автор
00.00.0000 00:00-10В embedded разработке иногда собирают из Cmake, который в свою очередь автогенерирует makefile или ninja.
Например так в ZephyrProject.
Но Cmake скрипты ненадежны для automotive так как часто дают осечки. В if(ы) не заходит например.
MiraclePtr
00.00.0000 00:00+6Но Cmake скрипты ненадежны для automotive так как часто дают осечки. В if(ы) не заходит например.
За десяток лет в самых разных проектах ни разу такого не наблюдал. CMake является одним из индустриальных стандартов C и C++ разработки и применяется при разработке сотен, если не тысяч сложнейших и ответственных продуктов, и там таких проблем нет. Более того, я только что бегло погуглил, во всем интернете включая stackoverflow не нашлось каких-либо свидетельств о багах в CMake вызывающих рандомные несрабатывания if'ов - то есть либо такого бага никогда не было, либо он давным-давно уже исправлен.
Поэтому к подобным заявлениям следует прикладывать конкретные примеры кода, когда такое происходит (и зарепортить их мейнтейнерам CMake), иначе это больше похоже на банальную криворукость конкретного программиста (с которой в мейкфайлах можно наделать ничуть не меньших бед).
victor_1212
00.00.0000 00:00много глаз присматривают за CMake включая sandia и cern для тривиальных ошибок, если что возможно давно закрыто -
MiraclePtr
00.00.0000 00:00-1Ну да, я и сказал "...либо он давным-давно уже исправлен" :)
BadHandycap
00.00.0000 00:00Думаю, бага никогда и не было, иначе кому такой CMake вообще нужен был бы.
mentin
00.00.0000 00:00+2Я спросил Бинг/Чатгпт, он вспомнил про один баг с комментариями 2002-го года, и изменение в поведении 2014-го. Если очень-очень долго не обновляться, можно наверное словить.
There are a few possible reasons why CMake does not enter an if statement. Some common mistakes are:
Using incorrect syntax for the condition argument of the if clause. You can refer to the Condition Syntax section of ¹ for more details on how to write valid expressions for CMake if statements.
Using a variable name that is affected by Policy CMP0054¹, which determines whether quoted variables should be dereferenced. For example, if you write
if ("${VAR}"), CMake will treat it as a string unless you set CMP0054 to NEW¹.Using end-of-line comments inside an if statement, which may cause unexpected behavior such as skipping the first line of the if body or changing the evaluation of the condition³. It is recommended to avoid end-of-line comments and use separate lines for comments instead.
I hope this helps you debug your CMake issue.????
Source: Conversation with Bing, 3/18/2023(1) if — CMake 3.26.0 Documentation. https://cmake.org/cmake/help/latest/command/if.html Accessed 3/18/2023.
(2) [Cmake] cmake bug with IF statement and end-of-line comment. https://cmake.org/pipermail/cmake/2002-May/059634.html Accessed 3/18/2023.
(3) CMake IF (something OR something else) - Stack Overflow. https://stackoverflow.com/questions/19144020/cmake-ifsomething-or-something-else Accessed 3/18/2023.MiraclePtr
00.00.0000 00:00+3О, спасибо за ссылки. То есть первые два кейса - это когда разработчик не прочитав документацию тупо косячит с синтаксисом (make и bash, кстати, в некоторых случаях от подобного взрываются ещё красивее), а третий пункт ведёт на ссылку вообще за 2002 год.
То есть по какому-то багу более чем 20-летней давности (а скорее даже просто особенности парсинга комментариев, пропущенную в документации, как там ответили разработчики), который разработчики оперативно отработали спустя два часа (!) после того как им о нем сообщили, делается вывод о фатальной ненадежности всего CMake в настоящем времени.
Мне прям вот даже интересно - те или иные баги находились и до сих пор находятся в любом софте, в том числе и в восхваляемых автором make и bash, почему же он сразу не отказывается от их использования? :)
randomsimplenumber
00.00.0000 00:00Ну, воще то синтаксис у cmake местами действительно странный. Местами он декларативный - ожидается что он сам разберётся, в каком порядке выполнять инструкции. Местами порядок важен. Местами case insensitivity, местами case sensitivity. endif(условие, которое вроде как должно соответствовать условию в if(), но можно и без него) - полный кринж.
MiraclePtr
00.00.0000 00:00+1Да никто и не говорит, что это идеальный инструмент, у меня самого к CMake целый список претензий есть.
Правда, к классическому make этот список длиннее раза так в два, а то и в три, так что при разработке чего-нибудь хоть сколь-менее сложного и серьезно при выборе между чистым make и cmake однозначным выбором будет второй :)
sergey-kuznetsov
00.00.0000 00:00+2Ну не склоняются английские слова, но вы аж в заголовок умудрились своё (ов) воткнуть.
MountainGoat
00.00.0000 00:00+18IDE отжирают много ресурсов компьютера
IDE стоят дорого, порядка 3500 EURСтатья в песочнице ждала с 1980-х?
Make это как пуговицы. Старая, простая и очень полезная вещь.
Старинные. Кованые кузнецом. По 100 грамм каждая.
randomsimplenumber
00.00.0000 00:00+13Если вы собираете из make, то очень вероятно, что у вас получится чистый, аккуратный репозиторий сам собой.
Так вот в чем секрет! :) Нужно не зелёную галочку нажимать, а в консоли make all набирать, и говнокод станет чистый и шелковистый.
Можно очень много ошибок отловить на этапе отработки утилиты make
Создать ошибок. Дебажить ошибки в makefile тот ещё квест.
comdivuz
00.00.0000 00:00+7Не знаю о чем статья. Работаю в IDE за 0 евро. Idea ce, vs code. При этом часто особенно для голанга для сборки использую старый добрый мейк, который вызываю во встроенном в ide терминале. Я вот в итоге и не знаю, автор бы меня похвалил или предал бы анафеме???)))
comdivuz
00.00.0000 00:00Улыбнуло что make это баш. Тогда и yaml для Хелм чартов тоже баш, раз туда можно баш команды вставлять и вообще что угодно "тот же баш")))
ky0
00.00.0000 00:00+1Не могу ничего сказать насчёт кода на C, но в целом использование Make для меня, как девопс-инженера, действительно очень упрощает автоматизацию. Для этого даже существует целая парадигма "три мушкетёра" — make, docker, compose.
MiraclePtr
00.00.0000 00:00+2Вот да, тоже хотел написать, что автору стоит двигаться дальше - когда у вас есть проект, который можно собрать отдельно без проприетарной IDE, само собой напрашивается дальнейшая автоматизация: docker-образы для сборки (чтобы не разворачивать с нуля нагромождение тулчейнов и библиотек когда нужно передать код проекта на доработку коллеге или запустить на билд-сервере), CI/CD в каком-нибудь jenkins, автоматический прогон тестов (автор же пишет тесты, я надеюсь?) и оценка code coverage, статический анализ кода (cppcheck, clang-static), линтеры и контроль форматирования (clang-tidy, clang-format), автогенерация документации (doxygen). Начало положено.
MiraclePtr
00.00.0000 00:00+2Чистый Make в 21 веке для сколь-менее сложных проектов это немного... странно (а для действительно сложных и больших проектов - так вообще глупо). Потому что давно уже есть, например, CMake и другие альтернативы, более удобные, более простые в использовании, поддержке и отладке.
С одной стороны, желание автора отвязаться от vendor lock-in' а и начать пользоваться чем-то гибким и общепринятым в отрасли разработки ПО понятно и похвально, но когда решил делать хорошее дело, не стоит зацикливаться на первом попавшемся инструменте для этого, лучше рассмотреть все варианты.
BobovorTheCommentBeast
00.00.0000 00:00+7Чет какая то труха в статье.
Иде отжирает не сильно больше браузера. Даже монстр на яве.
Есть IDE общего назначения умеющие во все мс студия, вс крд, клион, кривой эклипс.
Часть бесплатна. Но да, за хорошее надо платить, особенно когда контора делает дела, а не экономит мейкфайлами.
Потому что нефиг хранит описание сборки проекта в хмл. Есть смейки и мезоны для этого.
Тоже что и пункт 4.
Тоже что и 4.
-
Всегда можно сделать аналоговнетную. Ведь можно... Можно же?
В каком то кб грохнули лицуху на клон эклипса, теперь у дедов, которые сами себя закопали под проприетарную проектную систему весеннее обострение и мейкфайло рейдж.
ZafiRUS
00.00.0000 00:00+2make это замечательно, только вот есть маленькая такая проблема. Есть вендоры (Texas к примеру), у которых сборка только родными инструментами и возможна. Нет, вызвать компилятор cl6x и его инструментарий из командной строки вам никто запретить не может. Но в тот момент, когда вы захотите сделать что-то сложнее Hello World и начнёте использовать NDK, IPC и прочие библиотеки для работы с этими процессорами, вам потребуется великий и ужасный Code Composer Studio. Отладчик опять же у них работает только в нем.
Максимум, чего мне удалось добиться - запуск процесса сборки из консоли, что позволяет использовать sublime или qtcreator в качестве редактора кода.
aabzel Автор
00.00.0000 00:00-7Есть вендоры (Texas к примеру), у которых сборка только родными инструментами и возможна.
Поздравлю вас! Вы подпали под "технологический диктат". Хотя это и не удивително для политики США(Texas Instruments).
Вот попросите у TI техподдержки репозиторий из make.
Посмотрим, что они вам ответят.
aabzel Автор
00.00.0000 00:00Даже IDE-IAR не оказывает техподдержку по сборку из make.
Что уж говорить про TI
NeoCode
00.00.0000 00:00+1Как по мне, так формат makefiles это абсолютнейший, лютейший бред (также как и bash, и то и другое - продукты одного исторического периода). Как можно вообще с этим ископаемым форматом комфортно работать? Почему нельзя сделать все структурированно, в xml или json. У каждого проекта есть корень, в нем указывается имя проекта, далее могут быть секции с конфигурациями, секции со списками файлов, у каждой секции опять же должно быть имя в корне и структурированное содержимое. Каждая конфигурация должна содержать внутренние секции, отвечающие за разные группы опций компиляции. Если нужны разные компиляторы и прочие инструменты - тоже можно придумать соответствующий тип секции, с явным указанием что это "инструмент сборки" и именем. То есть, формат должен быть такой, чтобы его можно было максимально прозрачно отобразить на GUI окно настроек проекта.
iig
00.00.0000 00:00+1Как по мне, так формат makefiles это абсолютнейший, лютейший бред
В далёкие времена, когда компьютеры были большие, автор запилил себе программу с таким вот странным форматом, с табуляциями. Народу понравилось.
Почему нельзя сделать все структурированно, в xml или json.
Не нужно. Это машинные форматы, кодированные в текст. Для человеков есть 100500 других систем управления сборкой. scons, cmake, ninja.. Некоторые IDE их понимают.
BobovorTheCommentBeast
00.00.0000 00:00-3Ну смейк тоже говно (но все еще лучше). Но ради бога, можно же делать на питонячьем синтаксисе каком.
comdivuz
00.00.0000 00:00+1Собственно и была целая эра сборщиков декларативных на xml и json. ANT, ms build, xbuild, maven, ... Имя им легион - неудобно, многословно, проблемы с порядком выполнения, уйма тайного знания. Любой кто на этом строит сборки рано или поздно понимает, что даже динозавры типа make удобнее в части управления задачами. Собственно дьявол во всяких плагинах, например в части ракетных менеджеров. Но где этот вопрос решён нормальными консольными командами или прямо встроено в тулчейн опять же проблемы с мейком нет. Как краевед говорю, который 15 лет евангелировал ms build, затем maven и большие проекты с кастомными плагинами на грэдле собирал.
Так вот yaml лучше xml и json, процедурное типа градла лучше декларативного типа мавена, мейк и баш вообще всего лучше решают всё в лоб и по простому и где есть возможность действительно проще быстрее и понятнее сделать на них
zloddey
00.00.0000 00:00+1Смешно.
make, вообще-то, на десятилетия старше и XML, и, тем более, JSON. Почему же его авторы не использовали эти форматы? Вот что-то даже не знаю...comdivuz
00.00.0000 00:00+2А как авторы make могли использовать то чего нет. Я вам раскрою может секрет, но xml и json не популярны не только в девопс, но и в обработке данных, так как избыточные и не поточные, там царствуют добрые старые csv и прочие такие форматы.
Xml и json это форматы для сериализации древовидных структур с сохранением (особенно xml) метаданных. Зачем это всё в make, который является сборочным скриптом?
comdivuz
00.00.0000 00:00+2Вам то чем они так милы. Целое десятилетие было царствование xml, wsdl soap и всё такое, осталось только в мире легаси и кровавых межведомственных систем. Потом типа rest, json это наше всё... Ну и что по сути сейчас наметился возврат к классическим бинарным форматам но там с блэкджеком и прочим, типа протобафа. Json же смещается в более нишевое использование. Форматы, тренды, приходят и уходит. А бессмертная классика типа мейков и башей остаётся независимо от степени мощности своего синтаксиса. Причина одна они чётко знают свою работу и хорошо её делают)))
GarryC
00.00.0000 00:00+7Фигня какая то - сначала придумаем недостатки IDE, а потом начнем их побеждать.
IDE монолитные и неделимые. Если вы захотите поменять препроцессор, компилятор или компоновщик, а остальные фазы ToolChain(а) оставить как есть, то ничего из этого не выйдет, так как капот IDE закрыт на замок.
О как, а мужики по не знают ...
IDE стоят дорого, порядка 3500 EUR на один компьютер.
Мы в одной вселенной живем?
IDE(шные) xml очень слабо документированы или не документированы вовсе. У всех вендоров xml имеет свой особенный язык разметки.
А что, все должны иметь один стандарт разметки? Да, документированы не очень, но Вам точно нужно лезть под капот, если все работает правильно?
Затруднена сборка из консоли.
А никто и не обещал такое, хотя многие IDE позволяют сделать make файл и дальше делайте с ним , что хотите.
Обратная несовместимость с новыми версиями IDE
То есть при использовании make можно код с фичами C++17 скомпилировать под C++11 компилятором - честно говоря не знал о подобных возможностях, Вы открыли мне глаза.
lolikandr
00.00.0000 00:00+1Вы собираете код с помощью СMake?
Я понимаю, что есть cmake --build, но строго говоря вызовы компилятора и линкера делает не cmake, а " a native build tool ". То есть, если было cmake -G Ninja , то сборка всё-таки с помощью ninja.
aabzel Автор
00.00.0000 00:00СMake может генерировать целые проектные файлы для IDE Microsoft Visual Studio или Eclipse.
ATmegAdriVeR
00.00.0000 00:00+2Тут небольшая путаница в терминологии: Cmake - это способ управления компилятором. IDE (integrated development environment) - это интегрированная среда разработки, куда помимо инструментов управления компилятором, входят другие полезные вещи, вроде отладчика, терминалов, инструментов работы с репозиториями и т.п.
Я вообще не представляю, как без помощи IDE производить отладку программы?
И да, если мы говорим про Embedded, то Eclipse (и IDE на нём базирующиеся, наподобие STM Cube IDE, ESP-IDF), VSCode + PlatformIO - бесплатны. Очень хороший инструмент VisualGDB для Embedded систем стоит 100 долларов в год (https://visualgdb.com/buy/).
aabzel Автор
00.00.0000 00:00-2Я вообще не представляю, как без помощи IDE производить отладку программы?
Тут есть 4+ ответа:
1--> Использовать связку GDBClient + GDBServer и отлаживать код из командной строки.
https://habr.com/ru/post/694708/2--> Отлаживать код через интерфейс командной строки CLI поверх UART.
https://habr.com/ru/post/694408/3--> В коем-то веке покрывать код модульными тестами
https://habr.com/ru/post/698092/4--> Использовать другие косвенные признаки отладки кода: HeartBeat LED, Утилита arm-none-eabi-addr2line.exe, Assert(ы), DAC, STMStudio, Health Monitor
https://habr.com/ru/post/681280/
le2
00.00.0000 00:00+2Разработчики встраиваемых систем такие смешные. Очень быстро (особенно если писать на ассемблере для примитивных контроллеров x51, AVR, PIC) возникает ощущение всемогущности. Сам таким был.
Потом приходят маркетологи и просят написать под Cortex-A, свой блютуз-стек, с утилизацией многоядерности, прикрутить толстую внешнюю библиотеку, что-нибудь из мира Unix и это проезжает бульдозером по твоей самооценке. Выясняется, что твой любимый инструмент превращается в тыкву. Потому что он не может Cortex-A, RISC-V, MIPS, C++ - там странный кривой диалект, не может стырить толстую либу с гитхаба. А работа под отладчиком это для маленьких детей и большие пацаны так не пишут.Итого, есть два сценария - первый, самый распространенный, вы продолжаете использовать свой любимый инструмент и отказываетесь от работ, которые вы не в состоянии выполнить.
Второй сценарий - вы просто используете то что используется в толстой внешней библиотеке которая вам необходима, и которую вы не напишете никогда, потому что она стоит сотен человеко-лет разработки.
Но самый зубастый сценарий - все писать под Линукс, без отладчика, с любой необходимой системой сборки: cmake, ninja, makefile, bazel... как со своей родной. Если действительно нужен отладчик, то лучший вариант gcc с платным плагином для Visual Studio. Вы сразу получите все возможности работы с С++ и удобный аппаратный отладчик.aabzel Автор
00.00.0000 00:00-3это проезжает бульдозером по твоей самооценке. Выясняется, что твой любимый инструмент превращается в тыкву.
В программировании микроконтроллеров самооценка еще рушится при переходе на очередную RTOS.В каждом проекте взяты за основу разные RTOS(ы).
Если вы senior в FreeRTOS с 10 годами опыта за плечами, то при переходе на TI-RTOS вы мгновенно превратитесь в Junior(а).
Если вы senior в TI-RTOS с 15 годами опыта за плечами, то при переходе на RTOS Zephyr вы мгновенно снова превратитесь в Junior(а).+ учите CMake, Ninja, KConfig и DeviceTree.
Затем та же история с RTEMS 5, Tizen, VxWorks, ThreadX и так далее?
Поэтому в программировании микроконтроллеров Senior может на следующий день стать Junior(ом) и это более чем нормальное явление.В профессии программист MK развитие и экспертиза обнуляется каждые 2-3 года.
le2
00.00.0000 00:00+1у меня картина мира следующая.
Чиновники США в 60х оплатили разработку новой операционной системы. Туда были приглашены реальные звезды, технологические компании и университеты. Это проект Multics. Проект провалился, так как сроки были нереальные. Но именно там были придумали сущности: файл, директория, файловая система...
На обломках возникла сильно кастрированная операционная система UNIX. (яндекс голосовой переводчик часто переводит это название как "евнух-кастрат" и это действительно одна из версий происхождения названия) Система получилась удачной и чиновники США стандартизируют ее как проект POSIX. Итак, человечество получило единый стандарт для того чтобы портировать приложения. Прямо сейчас POSIX-приложения можно портировать на Андроид, МакОС, игровые приставки, суперкомпьютеры, Линуксы, ФриБСД и так далее.
В этом мире все должно поставляться в исходниках.
Проекты make (autotools), cmake, ninja и так далее это просто решение этой задачи портирования.Я думаю ваши проблемы от незнания Линукса. Вы пытаетесь заучивать рецепты. Хотя, если бы имели навыки и понимание, то ни одна из сущностей вашего перечисленного не казалось бы чем-то новым и удивительным.
Мне тоже казалось что Линукс это всего лишь подобие Винды. Нет. Расстояние от Линукса до Винды такое же как от Винды до пальцевого интерфейса Айфона (Андроида).
Линукс (UNIX) это долго и очень больно для изучения. Порог вхождения очень высокий.
Но с каждым шагом есть ощущение что вы возвращаетесь домой. Здесь Си, наконец-то, базовый родной язык. Но после преодоления порога уже ничего не шокирует. Ничего не вызывает раздражения и новые инструменты изучаются легко и естественно. И вы больше не джуниор.randomsimplenumber
00.00.0000 00:00+1Я думаю ваши проблемы от незнания Линукса.
Где linux с его POSIX, и где микроконтроллеры..
le2
00.00.0000 00:00+1перечисленные автором проблемы: CMake, Ninja, KConfig, DeviceTree, Tizen, VxWorks и так далее это все из мира UNIX.
aabzel Автор
00.00.0000 00:00Я думаю ваши проблемы от незнания Линукса.
В микроконтроллерах(МК) нет MMU, поэтому Linux на МК не запускают. На МК крутят разнообразные как снежинки RTOS(ы).
le2
00.00.0000 00:00+1UNIX это эталонная реализация Машины Тьюринга поверх фоннеймановской архитектуры. И мы живем с этим много лет, пока не появится некий новый квантовый компьютер или биологическая вычислительная система для которых придется все проектировать заново.
То есть все ваши ОС являются проекциями базовой системы. Достаточно понять первичную чтобы разобраться.
DeviceTree - это такое "ардуино" для взрослых, общее описание оборудования. Придумали когда устали бороться с зоопарком железа. Сейчас используется везде, кроме x86.KConfig - часть системы сборки ядра Линукс
VxWorks - POSIX система, те же яйца только в рилтаймеTizen - снова Линукс.
Zephyr - опять распотрашенный Линукс. Весь инструментарий оттуда.
язык Си - бессмертный пока существует POSIX
С++, большинство прочих языков программирования долгое время существовали как надстройки над бэкендом Си и его стандартной библиотеки.
Все эти RTOS, как FreeRTOS содержат те же мьютексы и семафоры только в сильно кастрированном виде. Вернее чаще это голый планировщик задач.
dltex
00.00.0000 00:00+2Для отладки консоль и только консоль. Обычно отладка нужна для капризных интерфейсов, работающих в реальном времени и фоном. Поэтому все что остается делать - складывать все переменные и регистры что могут понадобиться в массивы внутри прерываний, а потом считывать их консольным gdb. По другому заглючивший интерфейс отлаживать я хз как. ИМХО в остальных случаях отладка не нужна, т.к. какой нибудь алгоритм можно и тупо на компе погонять, проверить.
aabzel Автор
00.00.0000 00:00-1Для отладки консоль и только консоль.
Согласен. Нужен Debug CLI terminal over UART.
dltex
00.00.0000 00:00-2Все ARM Cortex-M давно уже по JTAG или сокращенному варианту его же (SWD). По нему же зашиваются, по нему же отлаживаются. У меня пока ручки до CC2640 Ti и ESP32 с Nordic NRF51 не дотянулись (их думаю через opencocd, swd over ftdi). Но вот STM32 давно уже по gbd через st-link utility по swd, причем под линуксом, в репозиториях уже все есть.
tzlom
В странах "первого мира" конечно же используют только мейк файлы, но тщательно это скрывают.
вообще не баш, иначе ба зачем был нужен мейк
прям запредельная простота
aabzel Автор
Да. Разумеется. Я работал в английском автопроме. Прошивки для ECU собирают там из само писных makefile(лов). *.mk подвергают версионному контролю наравне с *.c *.h.
Всех всё устраивает.
roma_turkin
Обобщать не стоит. Работал в немецком и американском автопроме, использовали cmake, bazel и bake, каждый хорош и плох по-своему. make и cmake перестают работать в сильно гетерогенных сборках, когда надо запустить 50 разных генераторов в разной последовательности и всё это дело соркестрировать в единый результат, желательно со временем компиляции, измеряемым в минутах, а не часах и днях.
victor_1212
> Всех всё устраивает.
примерно так, мне к примеру тоже без разницы, столько видел ddk, sdk, и пр., удивить трудно, чего никогда не понимал на habr, так это минусования вполне грамотных комментариев из-за того что у людей разный опыт