Gnu toolchain for windows

Настройка Toolchain(а) для сборки артефактов под STM32. x86-64, Win, Eclipse, GCC, Make, GDB, ST-LinkV2

В этом тексте я расскажу какой путь проходят исходники с момента написания до момента исполнения на микроконтроллере и как сварить прошивку. Также прокопаю тему как настроить ToolChain из бесплатных утилит. В этом тексте я покажу на что следует обратить внимание при запуске первого проекта на ARM Cortex-M чипах. Этот текст, в сущности, пояснение того, что происходит под капотом большинства IDE (IAR, Keil, CodeComposerStudio и пр.). Можете читать это как курс молодого боевика бойца.

Что же мне потребуется накатить на свой NetTop для разработки под STM32?

Вот список утилит с которыми скорее всего предстоит столкнуться при разработке прошивок для чипов STM32.

Программа/Утилита

Назначение

STM32 ST-LINK Utility.exе 

GUI прошивальщик по SWD/JTAG

ST-LINK_CLI.exe

CLI прошивальщик по SWD/JTAG

Putty /TeraTerm/HTerm

Терминалы Serial порта

STM Studio

Отрисовывать графики переменных из ячеек RAM памяти

Cygwin

Набор Unix утилит для Windows

pdf reader

браузер PDF файлов с документацией

python

интерпретатор языка Python

Cppcheck

Статический анализатор кода

git-bash.exe

Система управления версиями исходных кодов + удобны Unix CLI терминал

WinMerge

Сравнение текстовых файлов с подсветкой

ST-LINK_gdbserver.exe

Отладочный сервер

WinRAR

распаковка архивов с документацией от вендора

GNU Tools ARM Embedded

Компилятор для ARM

Atollic TrueStudio

Набор утилит

Tor Browser

Web Browser для скачивания утилит и документации из санкционных территорий

Jenkins

Сервер сборки артефактов

hexdump /hexedit

просмотрщик бинарных файлов

grep

поиск подстрок в кодовой базе

find

поиск файла в файловой системе по регулярному выражению для его имени

STM32CubeMX

Генератор базового кода с примерами

clang format

автоматические выравнивание отступов

Notepad++

вспомогательный текстовый редактор специально для коммит сообщений

Eclipse IDE for C/C++ Developers 

текстовый редактор

Фаза 1. Установка текстового редактора

Так как любая программа это прежде всего текст, то надо установить какой-нибудь текстовый редактор.

Предлагаю Eclipse IDE for C/C++ Developers так как у него весьма удобные HotKeys. Для ускорения написания кода.

Плюс в Eclipse приятное синее выделение.

Еще Eclipse мгновенно запускается. Как по мне качество текстового редактора определяется тем как часто вам приходится пользоваться мышкой. В хорошем текстовом редакторе мышка вообще не нужна. Eclipse один из таких текстовых редакторов.

Установить Eclipse IDE for C/C++ Developers можно отсюда
https://www.eclipse.org/downloads/packages/

Установка заключается в распаковке скаченного архива в удобное место. В ОС Windows можно устанавливать Eclipse в корень диска С.

Программа запускается с помощью исполняемого файла eclipse.exe, который находится в распакованной папке. 

При первом запуске Eclipse надо выбрать рабочую папку (workspace). В этой папке Eclipse будет по умолчанию создавать проекты.

Настройка проекта в Eclipse

Настройки текстового редактора содержатся в файлах .project, .cproject. Важно снять галочку с пункта Makefile generation. В поле Build location прописать относительный путь к папке, которая содержит Makefile.

Настроить параллельную сборку чтобы ускорить цикл ToolChain(а). Это делается во вкладке Behavior

После этого инициировать сборки можно горячей клавишей Ctrl+B.

Фаза 2. Накатывание ToolChain(а) GCC под ARM для Cross компиляции на Win10

Нужен ToolChain: препроцессор (cpp), компилятор ASM(as), компилятор С (gcc),компилятор С++(g++), компоновщик(ld), отладчик(gdb). Нужны binutils(ы) для диагностики полученных артефактов(nm, size, readelf), архиватор статических библиотек(ar), и прочее. Это основные утилиты, которые и делают всю работу по превращению исходников (*.с, *.h) в артефакты (*.hex *.bin *.map *.elf *.out файлики).

ToolChain следует брать с официального сайта

https://developer.arm.com/downloads/-/gnu-rm#:~:text=The%20GNU%20Arm%20Embedded%20Toolchain,Arm%20Cortex%2DR%20processor%20families

.

Toolchain устанавливается как обычная win программа прямо из gcc-arm-none-eabi-10.3-2021.10-win32.exe файла

Проверка, что установилось. Вот полный комплект GCC ARM. Всего 32 утилиты.

Как же make файл узнает, что нужен именно этот toolchain? Ведь их может быть установлено несколько в разные папки. Ответ прост. Надо прописать адрес toolchain в переменной Path. А старый путь просто дропнуть.

и тут

Каждый свой шаг надо проверять. Как проверить, что терминал cmd находит ToolChain? Откройте cmd из любой папки и наберите arm-none-eabi-gcc.exe –v

Версия должна отобразиться в соответствии с версией скаченного дистрибутива. ToolChain может находится примерно по такому адресу:

C:\Program Files (x86)\GNU ARM Embedded Toolchain\10 2021.10\bin\

Фаза 3. Установка Windows Build Tools binaries (Make, cp, rm, echo, sh…)

Самый классический способ сборки программ на С(ях) это, конечно же, Make файлы. Не перестаю удивляться насколько элегантна сборка программ из make. В 1970е года когда появились утилита make программировали только настоящие ученые со степенями докторов наук. Тогда у школоты как сейчас банально не было персональных компьютеров из-за дороговизны DeskTop(ов). В 197x программировали по настоящему достойные люди. Поэтому и появились такие утилиты-шедевры как make, grep, find, sort и прочее. Благодаря Make файлам  можно управлять модульностью сборок программных компонентов по-полной. Мгновенно, одной строчкой включать и исключать сотни файлов одновременно для сотен сборок. Это даже не снилось таким GUI(ням) как IAR с Keil, где приходится протирать дыры в коврике для мышки, чтобы сделать то, что в make делается одной строчкой в *.mk файлике.

Сейчас среди российских программистов микроконтроллеров make файлами умеет пользоваться в лучшем случае один из шести. Остальные не могут слезть с иглы GUI-IDE. Сборка прошивок из make это считается высшим пилотаже программирования на С(ях).

Вот минимальный набор утилит для процессинга Make файлов.

Утилита

Назначение

make

build automation tool

sh

Unix shell interpreter

busybox

a software suite that provides several Unix utilities

echo

Echo the STRING(s) to standard output.

cp

Copy SOURCEs to DEST

mkdir

Create DIRECTORY

rm

Remove (unlink) FILEs

Где же мне взять универсальный Makefile для сборки много-файловых проектов? Самое простое это воспользоваться код-генератором STM32CubeMX и сгенерировать MakeFile проект.

Далее аккуратно раздербанить его под общую кодовую базу. Получается вот такой файл с правилами.

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))
LDSCRIPT := $(subst /cygdrive/c/,C:/, $(LDSCRIPT))
#@echo $(error SOURCES_ASM=$(SOURCES_ASM))

# binaries
PREFIX = arm-none-eabi-
# 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
 
# CFLAGS
#https://gcc.gnu.org/onlinedocs/gcc/ARM-Options.html
FPU = 
FPU += -mfpu=fpv4-sp-d16

FLOAT-ABI = -mfloat-abi=hard

MCU = $(CPU) -mthumb $(FPU) $(FLOAT-ABI)

CSTANDARD = -std=c11

AS_DEFS = 

AS_INCLUDES = 
OPT += -Os
    
ifeq ($(DEBUG), Y)
    #@echo $(error DEBUG=$(DEBUG))
    CFLAGS += -g3 -gdwarf-2 -ggdb
endif

ASFLAGS = $(MCU) $(AS_DEFS) $(AS_INCLUDES) $(OPT) -Wall -fdata-sections -ffunction-sections

CFLAGS += $(MCU) $(OPT) $(INCDIR) -Wall -fdata-sections -ffunction-sections $(CSTANDARD)


# 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
else
    LIBS += -lnosys 
    LINKER_FLAGS += -u _scanf_float
    LINKER_FLAGS += -u _printf_float
endif

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) -specs=nano.specs -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 ***

Вот так выглядит пример make файла для компонента независимого сторожевого таймера

$(info IWDG_MK_INC=$(IWDG_MK_INC) )
ifneq ($(IWDG_MK_INC),Y)
    IWDG_MK_INC=Y
    
    mkfile_path := $(abspath $(lastword $(MAKEFILE_LIST)))
    $(info Build  $(mkfile_path) )
    
    IWDG_DIR = $(WORKSPACE_LOC)bsp/bsp_stm32f4/iwdg
    #@echo $(error IWDG_DIR=$(IWDG_DIR))
    IWDG=Y
    INCDIR += -I$(IWDG_DIR)
    OPT += -DHAS_IWDG

    SOURCES_C += $(IWDG_DIR)/iwdg_drv.c

    ifeq ($(CLI),Y)
        ifeq ($(IWDG_COMMANDS),Y)
            OPT += -DHAS_IWDG_COMMANDS
            SOURCES_C += $(IWDG_DIR)/iwdg_commands.c
        endif
    endif
endif

А это 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)

include $(MK_PATH)components.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

В Makefile тоже можно делать Include guard подобно *.h файлам препроцессора.

$(info FILE_MK_INC=$(FILE_MK_INC))
ifneq ($(FILE_MK_INC),Y)
    FILE_MK_INC=Y
endif

И так далее. Для каждой сборки один Makefile и множество общих *.mk файлов.

Windows Build Tools binaries можно скачать по ссылке.

Можно скопировать утилиты Windows Build Tools  в папку:

C:\xpack-windows-build-tools-4.3.0-1\bin

Фаза 4. Подключить настройки компоновщика (Linker(а)). (*.ld файл)

После сборки *.с файлов образуются столько же *.o фалов. Их надо скомпоновать в один *.bin файл. Этим занимается утилита arm-none-eabi-ld.exe. Как и любой утилите нужен свой конфигурационный файл. Обычно это *.ld файл. Вот пример конфигурации компоновщика для сборки первичного загрузчика.


/* Entry Point */
ENTRY(Reset_Handler)

/* Highest address of the user mode stack */
_estack = ORIGIN(RAM) + LENGTH(RAM);    /* end of RAM */
/* Generate a link error if heap and stack don't fit into RAM */
_Min_Heap_Size  = 0x200; /* required amount of heap  */
_Min_Stack_Size = 0x900; /* required amount of stack */

/* Specify the memory areas */
MEMORY
{
RAM (xrw)  : ORIGIN = 0x20000000, LENGTH = 320K
FLASH (rx) : ORIGIN = 0x08000000, LENGTH = 16K
}

/* Define output sections */
SECTIONS
{
  /* The startup code goes first into FLASH */
  .isr_vector :
  {
    . = ALIGN(4);
    KEEP(*(.isr_vector)) /* Startup code */
    . = ALIGN(4);
  } >FLASH

  /* The program code and other data goes into FLASH */
  .text :
  {
    . = ALIGN(4);
    *(.text)           /* .text sections (code) */
    *(.text*)          /* .text* sections (code) */
    *(.glue_7)         /* glue arm to thumb code */
    *(.glue_7t)        /* glue thumb to arm code */
    *(.eh_frame)

    KEEP (*(.init))
    KEEP (*(.fini))

    . = ALIGN(4);
    _etext = .;        /* define a global symbols at end of code */
  } >FLASH

  /* Constant data goes into FLASH */
  .rodata :
  {
    . = ALIGN(4);
    *(.rodata)         /* .rodata sections (constants, strings, etc.) */
    *(.rodata*)        /* .rodata* sections (constants, strings, etc.) */
    . = ALIGN(4);
  } >FLASH

  .ARM.extab   : { *(.ARM.extab* .gnu.linkonce.armextab.*) } >FLASH
  .ARM : {
    __exidx_start = .;
    *(.ARM.exidx*)
    __exidx_end = .;
  } >FLASH

  .preinit_array     :
  {
    PROVIDE_HIDDEN (__preinit_array_start = .);
    KEEP (*(.preinit_array*))
    PROVIDE_HIDDEN (__preinit_array_end = .);
  } >FLASH
  .init_array :
  {
    PROVIDE_HIDDEN (__init_array_start = .);
    KEEP (*(SORT(.init_array.*)))
    KEEP (*(.init_array*))
    PROVIDE_HIDDEN (__init_array_end = .);
  } >FLASH
  .fini_array :
  {
    PROVIDE_HIDDEN (__fini_array_start = .);
    KEEP (*(SORT(.fini_array.*)))
    KEEP (*(.fini_array*))
    PROVIDE_HIDDEN (__fini_array_end = .);
  } >FLASH

  /* used by the startup to initialize data */
  _sidata = LOADADDR(.data);

  /* Initialized data sections goes into RAM, load LMA copy after code */
  .data : 
  {
    . = ALIGN(4);
    _sdata = .;        /* create a global symbol at data start */
    *(.data)           /* .data sections */
    *(.data*)          /* .data* sections */

    . = ALIGN(4);
    _edata = .;        /* define a global symbol at data end */
  } >RAM AT> FLASH

  
  /* Uninitialized data section */
  . = ALIGN(4);
  .bss :
  {
    /* This is used by the startup in order to initialize the .bss secion */
    _sbss = .;         /* define a global symbol at bss start */
    __bss_start__ = _sbss;
    *(.bss)
    *(.bss*)
    *(COMMON)

    . = ALIGN(4);
    _ebss = .;         /* define a global symbol at bss end */
    __bss_end__ = _ebss;
  } >RAM

  /* User_heap_stack section, used to check that there is enough RAM left */
  ._user_heap_stack :
  {
    . = ALIGN(4);
    PROVIDE ( end = . );
    PROVIDE ( _end = . );
    . = . + _Min_Heap_Size;
    . = . + _Min_Stack_Size;
    . = ALIGN(4);
  } >RAM

  /* Remove information from the standard libraries */
  /DISCARD/ :
  {
    libc.a ( * )
    libm.a ( * )
    libgcc.a ( * )
    libnosys.a ( * )
  }

  .ARM.attributes 0 : { *(.ARM.attributes) }
}

Фаза 5. Подключить инициализацию окружения. Ассемблерный код.

До запуска функции main() происходит множество инфраструктурных действий:

  1. Выбрать вариант загрузки по двум Boot пинам (Flash 0x0000_0000, Flash 0x0800_0000, SRAM 0x2000_0000)

  2. Проинициализировать регистр указателя SP на начало стека первым qWord(ом) бинаря.

  3. Проинициализировать глобальные переменные в RAM данными из бинаря. (интервал rwdata).

  4. Обнулить неинициализированные переменные в RAM (интервал bss).

  5. Настроить ядро вычисление с плавающей точкой FPU.

  6. Прописать в регистры процессора местонахождение адресов обработчиков прерываний.

  7. Примонтировать, если нужно, внешнюю Off-Chip RAM память.

Всё это прописано в коде на Assembler в *.S файле. Который отрабатывает до запуска функции main(). Это например файл startup_stm32f413xx.S

Фаза 6. Нужны сорцы от Vendor(ов) чипа.

Чтобы можно было начать разрабатывать какое-то приложение и бизнес логику нужно целая куча системного софта. Это базовый софт или System Software. В его состав входит всяческая инициализация. Инициализация тактирования(TIM, RCC, RTC), интерфейсов (CAN, SPI, I2S, I2C, UART, USB, GPIO, SDIO, SAI, Ethernet), системных компонент (FLASH, SRAM, DMA, MPU, IWDG, RNG, FPU, NVIC), возможностей генерации (DAC, PWM). Это десятки тысяч строк кода. К счастью часть этого кода предоставляют нормальные вендоры чипов.

При разработке на STM32 у нас по сути два вендора: Компания ARM и Компания STMicroelectronic.

Компания ARM выпускает так называемый CMSIS(Common Microcontroller Software Interface Standard). Это С обертки для ASM команд под Cortex-M чипы. Так же *.ld файлики для компоновщика. Это скачивается с их сайта https://silver.arm.com/browse/CMSIS после регистрации

Компания STMicroelectonic выкатывает HAL Drivers — базовый системный софт для инициализации периферии микроконтроллера. Самое простое это установить их компанейский код генератор и STM32CubeMX по ссылке и сгенерировать проект.

STM32CubeMX сам скачает и сохранит сорцы базового кода в папку STM32F4xx_HAL_Driver. Только скачивать предстоит через Tor browser так как РФ у ST числится санкционной территорией. Вот список сорцов STM32F4xx_HAL_Driver от вендора:

Обратите внимание никаких статических библиотек (*.а) как у Texas Instruments. Чистые сорцы (*.c *.h файлики).

Фаза 7. Как скормить прошивку микроконтроллеру? 

Накатить прошивку на чип можно при помощи программатора ST-Link через интерфейс SWD/JTAG и утилиты STM32 ST-LINK Utility.exe. Программатор может быть встроен в отладочную плату от ST, как например в семействе Nucleo_f4XXXxx:

Если вы записываете Generic *.bin артефакт(приложение), то надо указать адрес начала бинарная в On-Chip Nor Flash памяти. Запись *.hex файлов безопаснее так как вам не надо явно указывать адрес начала прошивки. Прошивка это просто бинарный массив в файле. Текстовым редактором его не проанализируешь. Анализировать содержимое бинарных файлов (*.bin) можно консольной утилитой-переходником hexdump.exe. Даешь *.bin получаешь Hex Wall в *.txt

hexdump -C nucleo_f401re_gcc_m.bin > nucleo_f401re_gcc_m.txt

Стоит убедиться, что в первом qword всегда адрес из RAM (начало стека), а во втором qword всегда адрес из Flash (Reset_Handler).  Тогда прошивка не зависнет до запуска main().

GUI окно утилиты STM32 ST-LINK Utility.exe. Можно прописать прошивку по любому отступу.

Классическая ситуация: накатили прошивку и плата зависла. Не  мигает heartbeat LED. Как вариант может помочь пошаговая отладка.

Для пошаговой отладки потребуется обновление прошивки программатора ST-Link. Это можно выполнить прямо в утилите STM32 ST-LINK Utility.exe во вкладке ST-LINK:

С точки зрения DevOps(а) надо прошивать чипы из командной строки, Batch скриптом. Это легко автоматизировать. Вот скрипт автоматического обновления прошивки при помощи утилиты ST-LINK_CLI.exe

echo off
cls

set project_name=nucleo_f413zh_generic_gcc_d_m
set project_dir=%cd%
echo project_dir=%project_dir%
set artefact_hex=%project_dir%\build\%project_name%.hex
set FlashTool="C:\Program Files (x86)\STMicroelectronics\STM32 ST-LINK Utility\ST-LINK Utility\ST-LINK_CLI.exe"
rem set Device= ID=0x463 SN=066CFF323535474B43013113 
set Device= 
set options= -c %Device% SWD freq=4000 HOTPLUG  LPM -P %artefact_hex% -V "after_programming" -Log -TVolt
call %FlashTool% %options%
rem Reset System
call %FlashTool% -Rst

 

Вот лог результата работы

Easy!
Прошивка из ST-LINK_CLI.exe эффективнее, поскольку использует драгоценный интерфейс USB-SWD, только тогда, когда это реально нужно, а не всегда как в GUI версия (STM32 ST-LINK Utility.exe).

Фаза 8. Установка Debug Server

Для пошаговой отладки надо установить GDB Server. Это утилита-переходник, которая с одной стороны допрашивает чип по SWD или JTAG, а с другой стороны обслуживает TCP сокет к которому подключится отладчик arm-none-eabi-gdb.exe к порту с номером 61234. 

Эту утилиту можно извлечь из набора утилит от Atollic TrueSTUDIO. Atollic TrueSTUDIO(R) for STM32 можно скачать с сайта ST.com.

 Надо зарегистрироваться на сайте st.com. Скачивать дистрибутив en.TrueSTUDIO_V9.3.exe.exe получится при помощи Tor Browser так как РФ у ST числится, как санкционная территория.

ST-LINK_gdbserver установлен в 

C:\Program Files (x86)\Atollic\TrueSTUDIO for STM32 9.3.0\Servers\ST-LINK_gdbserver\ST-LINK_gdbserver.exe

Нужно добавить в переменную Path путь к папке с утилитами binutils компилятора. В данном случае этот путь выглядит так:

C:\Program Files (x86)\GNU Tools ARM Embedded\5.4 2016q3\bin\

Опционально можно настроить конфигурацию отладчика в текстовом редакторе Eclipse во вкладке Run->External Tools->External Tools Configurations… или просто запустить GDB server (сервер отладки) вручную. Перейти в папку:

C:\Program Files (x86)\Atollic\TrueSTUDIO for STM32 9.3.0\Servers\ST-LINK_gdbserver

запустить скрипт  ST-LINK_gdbserver.bat.

C:\Program Files (x86)\Atollic\TrueSTUDIO for STM32 9.3.0\Servers\ST-LINK_gdbserver\ST-LINK_gdbserver.bat

Путь к отладочному серверу C:\Program Files (x86)\STMicroelectronics\STM32 ST-LINK Utility\ST-LINK Utility следует прописать в переменную Path

Фаза 9. Настройка Debug конфигурации для конкретной сборки

Неудобство Eclipse по сравнению с тем же пресловутым IAR это то, что для каждой сборки приходится настраивать конфигурацию отладки. Однако в Eclipse можно нажать Ctrl+3 появится окно быстрого поиска

и набрать там Debug Configuration. Надо прописать путь к *.elf файлу.

На вкладке Debugger надо прописать путь к отладчику от ARM GCC

C:\Program Files (x86)\GNU Arm Embedded Toolchain\10 2021.10\bin\arm-none-eabi-gdb.exe

и прописать порт от сервера отладки localhost:61234

На вкладке Startup надо прописать, что следует поставить точку останова на функции main(). Можно поставить точку останова также на более ранних функциях Reset_Handler или SystemInit().

Перед началом пошаговой отладки надо запустить отладочный сервер . Достаточно просто запустить на исполнение скрипт ST-LINK_gdbserver.bat в папке 

C:\Program Files (x86)\Atollic\TrueSTUDIO for STM32 9.3.0\Servers\ST-LINK_gdbserver

Желательно из-под командной строки cmd, чтобы были видны логи отладочного сервера.

Для того чтобы выполнять пошаговую отладку нужно пересобрать артефакты с опциями компилятора

-g3 -gdwarf-2 -ggdb

Пошаговая отладка подсвечивается прямо в текстовом редакторе Eclipse зеленой строчкой. Это благодаря утилите arm-none-eabi-addr2line.exe. Текстовый редактор Eclipse сам парсит вывод addr2line и подсвечивает активный адрес в виде зелёной строчки в коде.

Во время пошаговой отладки светодиоды программатора ST-Link должны мигать зелено-красным цветом.

Блок-схема Toolchain(а)

Все вышесказанное можно представить в виде одной блок-схемы (Helicopter view) на одном единственном листочке. Такова общая канва.

Для нас исходниками являются файлы с расширениями *.ld, *.c, *.h, *.S, *.cproject, *.project, *.Makefile, *.mk , *.bat — их и надо подвергать версионному контролю в GIT.   Автогенеренными для нас являются файлы с расширениями *.o, *.bin, *.bak, *.hex, *.map, *.elf, *.out, *.d, *.a. Отгружать следует файлы *.bin, *.hex, *.map, *.elf. Это артефакты или конечный продукт работы программиста микроконтроллера. 

Также рекомендую пользоваться GIТ(ом) исключительно

из-под командной строки

. Так вы сможете обрабатывать вывод утилиты git легендарное утилитой grep. Можно делать вложенные grep поверх grep. Вот например так.

Если бы был аналог утилиты grep в материальном мире, то вы бы могли находить иголки в стоге сена, понимаете? Вам уже нравится утилита grep?

UART CLI Для отладки (или добавьте в прошивку гласность) 

Любая разработка начинается там, где есть возможность наблюдать за тем, что получилось после изменений. Поэтому вам понадобится интерфейс командной строки CLI для отладки софта и железа. Крайне желательно использовать раскраску логов, чтобы концентрировать внимание на ошибках (красный) и предупреждениях (желтый). Плюс появление цвета в консоли это признак того, что поток символов непрерывный так как коды цветов распарсились корректно. Своего рода контрольная сумма принятых данных. Да и вообще консольные логи должны выглядеть весело. Просматривать UART-CLI логи можно в утилите TeraTerm или PuTTY. Они точно понимают символы цветов.

Поэтому надо активировать свободный UART, написать в прошивке интерпретатор команд CLI для RunTime отладки по интерфейсу UART. CLI(шку) можно также инкапсулировать в любой полу или полнодуплексный интерфейс(LoRa, CAN, UART, RS485) или протокол (TCP/UDP). При наличии CLI для общения с гаджетом вам не нужно будет писать никакую GUI(ню) на QT, .Net или Python. Достаточно только общедоступных терминалов Serial порта как TeraTerm, PyTTY, Hercules. Это же успех!

Трюки для эффективной отладки прошивок

  • Всегда проверяйте адрес функции main(). Может случится, что техник записал Generiс *.bin в область памяти для Bootloader или наоборот. Прошивка должна проверять адрес функции main, что он лежит в нужном секторе On-Chip NorFlash(а).

  • Используйте файловую систему FlashFs. Это позволит уменьшить количество сборок, так как конфигурации будут в файловой системе.

  • Используйте HeartBeat LED. Так вы поймете, что прошивка зависла, если нет мигания.

  • Используйте GPIO+Oscilloscope+DMM для физической отладки быстрых процессов.

  • Разделяйте аппаратно-зависимый и аппаратно-независимый код. Аппаратно-независимый код тестируйте на LapTop(е).

  • Используйте серверы сборки (например Jenkins) для поддержания на плаву своих сборок. У вас всегда будет готовый артефакт для отгрузки. Плюс сразу будет видно какие сборки конфликтуют и оперативно принять меры по улучшению модульности.

  • Пишите свои загрузчики. Программатор может исчезнуть, сломаться. С загрузчиком вы обновите прошивку своего гаджета буквально по 3м проводам UART. Причем делайте первичный и вторичный загрузчик. Это позволит прописывать вторичный загрузчик по произвольному адресу.

  • Используйте интерфейс SWD/JTAG для пошаговой отладки и поиска причин зависаний.

  • Используйте утилиту STM Studio для построения графиков переменных по их адресу в ячейках RAM.

  • Покрывайте код модульными тестами (программные скрепы). Это лучший способ найти ошибку в коде, который затруднительно пройти пошаговой отладкой. Плюс тесты помогут безопасно делать перестройку (рефакторинг). Сегодня российское общество испытывает явный дефицит программных скреп.

Вывод

Существуют и другие ToolChain(ы) (IAR, Keil). Тут же я написал про бесплатный способ полноценно вести разработку и отладку на STM32. Однако если разработчик научится собирать код из make, то он перестанете быть рабом IDE с их периодическими зависаниями. Плюс можно сэкономить 3500 EUR не покупая проприетарный компилятор, который еще и не продадут из-за санкций.

Ссылки на похожие посты:

STM32 + CMSIS + STM32CubeIDE

ARM-ы для самых маленьких: тонкости компиляции и компоновщик

STM32 на MAC OS

Отладка STM32 в среде Eclipse+GCC

ARM-ы для самых маленьких: компоновка-2, прерывания и hello world!

STM32 + CMSIS + STM32CubeIDE

ARM-микроконтроллеры STM32F. Быстрый старт c STM32-Discovery

Развертывание среды разработки для STM32

STM32CubeMX — продвинутый генератор проектов для STM32

Eclipse для микроконтроллеров (STM32) + FreeRTOS Task Aware Debugge

Переход из online в offline IDE при программировании Nucleo-F401RE

Начинаем изучать Cortex-M на примере STM32

Программируем микроконтроллеры stm32 при помощи QtCreator

Настраиваем бесплатную сборку для написания и отладки программ под микроконтроллеры на основе ядра ARM под Windows 10

Tutorial: Makefile Projects with Eclipse

Только зарегистрированные пользователи могут участвовать в опросе. Войдите, пожалуйста.

Вы собираете артефакты прошивок из Make файлов?

Проголосовали 44 пользователя. Воздержались 3 пользователя.

Только зарегистрированные пользователи могут участвовать в опросе. Войдите, пожалуйста.

Вы пользуйтесь текстовым редактором Eclipse?

Проголосовали 49 пользователей. Воздержались 3 пользователя.

Только зарегистрированные пользователи могут участвовать в опросе. Войдите, пожалуйста.

Вы собираете артефакты для МК компилятором GCC?

Проголосовали 46 пользователей. Воздержались 6 пользователей.

Только зарегистрированные пользователи могут участвовать в опросе. Войдите, пожалуйста.

Вы собираете прошивки в Windows?

Проголосовали 50 пользователей. Воздержались 4 пользователя.

Только зарегистрированные пользователи могут участвовать в опросе. Войдите, пожалуйста.

Вы собираете артефакты прошивок из СMake файлов?

Проголосовали 47 пользователей. Воздержались 3 пользователя.

Только зарегистрированные пользователи могут участвовать в опросе. Войдите, пожалуйста.

Вы собираете прошивки из IDE IAR?

Проголосовали 49 пользователей. Воздержались 2 пользователя.

Только зарегистрированные пользователи могут участвовать в опросе. Войдите, пожалуйста.

Вы пользуйтесь пошаговой отладкой прошивок?

Проголосовали 50 пользователей. Воздержались 2 пользователя.

Только зарегистрированные пользователи могут участвовать в опросе. Войдите, пожалуйста.

Вы пользуйтесь отладкой прошивок через интерфейс командной строки?

Проголосовали 46 пользователей. Воздержались 4 пользователя.

Только зарегистрированные пользователи могут участвовать в опросе. Войдите, пожалуйста.

Вы пользуйтесь сервером сборки (например Jenkins) для автоматической сборки артефактов?

Проголосовали 47 пользователей. Воздержались 3 пользователя.

Только зарегистрированные пользователи могут участвовать в опросе. Войдите, пожалуйста.

Вы покрываете код прошивок модульными тестами?

Проголосовали 45 пользователей. Воздержались 3 пользователя.

Только зарегистрированные пользователи могут участвовать в опросе. Войдите, пожалуйста.

Вы пользуйтесь системой контроля версий GIT?

Проголосовал 51 пользователь. Воздержались 3 пользователя.

Только зарегистрированные пользователи могут участвовать в опросе. Войдите, пожалуйста.

Этот текст нанёс вам пользу?

Проголосовали 19 пользователей. Воздержались 5 пользователей.

Только зарегистрированные пользователи могут участвовать в опросе. Войдите, пожалуйста.

Вы обнаружили в тексте 3 пасхалки?

Проголосовали 15 пользователей. Воздержались 3 пользователя.

Только зарегистрированные пользователи могут участвовать в опросе. Войдите, пожалуйста.

Вы пользуйтесь утилитой grep?

Проголосовали 19 пользователей. Воздержался 1 пользователь.

GNU Toolchain for Windows

This repository is a collection of binaries to create your own GNU Toolchain usable in Windows. The trunk of the master
branch contains the sum of the latest versions of all binaries.

Binaries are provided for the following programs:

  • GCC 7
  • GCC 8
  • GCC 9
  • GCC 10
  • GCC 11
  • GCC Trunk (12)
  • make
  • binutils
  • gdb
  • MinGW

All binaries are 64 bit but the toolchain and debugger can produce and debug 32 Bit code as well

Executable without a prefix produce and handle 64 Bit Code.
Executables with the prefix i686-w64-mingw32 produce and handle 32 Bit Code.

Only need a particular GCC version for your toolchain?

Checkout the branches:

  • GCC-7
  • GCC-8
  • GCC-9
  • GCC-10
  • GCC-11

for smaller readily available toolchains.

Features compiled in are:

  • GCC:
    • Modules support in GCC-11
    • Shared and static versions of runtime libraries such as libstdc++. By default programs are linked against shared
      versions. use the -static flag to compile against the static versions
    • Link Time Optimization support
    • C, C++, Fortran, ObjC, ObjC++ and D
    • OpenMP support
    • Quad Precision Math support
    • C++11 Threading using pthreads
    • Support for GCC Plugins
    • zstd LTO compression
    • iconv charset support
    • Version specific runtimes: Allows multiple GCC installations to live next to each other. This is done using version
      prefixes to runtime folders as well as version suffixes for each program. E.g. Executable of GCC 9 is called gcc-9.
      To create a symlink for the default version of gcc you want to use run one of the make-gcc-*-*-default.bat
      which will create symlinks such as gcc.exe and others (master branch only).
  • binutils:
    • Plugin support (needed for LTO)
  • gdb:
    • Pretty Printer support thanks to Python 2.7 statically linked into the binary
    • gdbserver
    • multi-arch support allowing debugging any target supported by gdb when remote debugging
    • iconv charset support
    • Minidebuginfo support with lzma compression
    • Precise floating point emulation with MPFR and GMP
  • MinGW:
    • Posix Threading
    • Default windows version of 0x601 (Windows 7)
    • MSVCRT Runtime instead of ucrt (Needed by e.g. Golang compiler)
    • Builds of winpthreads and winstorecompat

If you have any problems with the configuration used or are in need of any additional options and settings feel free
to open an issue.

All binaries are either fully relocatable or only have a dependency on libwinpthread-1.dll.
For GCC to function it requires the folder it’s located in (the bin folder) to be in the system PATH.

Trunk version of this repository currently contains following versions:

  • GCC 7.5.0
  • GCC 8.5.0
  • GCC 9.4.1
  • GCC 10.3.1
  • GCC 11.1.1
  • GCC Trunk (12.0.0)
  • GDB Trunk (11.0.50)
  • Binutils Trunk (2.36.50)
  • MinGW Trunk (10.0.0)
  • Make Trunk (4.3.90)

For repositories, configure options and commit revisions see BUILDINFO.txt

Последнее обновление: 05.12.2023

Установка Arm GNU Toolchain на Windows

Наиболее популярным инструментом для компиляции кода ассемблера для arm представляет компилятор GAS от проекта GNU, который входит в состав комплекта инструментов
для разработки под ARM — Arm GNU Toolchain. Итак, вначале установим данный набор инструментов. Для этого перейдем на официальный сайт компании Arm
на страницу https://developer.arm.com/downloads/-/arm-gnu-toolchain-downloads.
Здесь представлены поседние версии Arm GNU Toolchain для разных архитектур.

GNU Arm Embedded Toolchain для ARM64 ассемблера

(Если в силу географической принадлежности доступ к сайту блокируется, то необходимый пакет инструментов для Windows можно загрузить отсюда —
arm-gnu-toolchain-13.2.rel1-mingw-w64-i686-aarch64-none-elf.exe)

Каждая версия Arm GNU Toolchain привязана к определенной версии компиляторов GCC. Например, последняя на момент написания этой статьи версия Arm GNU Toolchain 13.2.Rel1
привязан к версии 13.2 набора компиляторов gcc.

Для ОС Windows доступно несколько групп пакетов по различные архитектуры:

  • AArch32 bare-metal target (arm-none-eabi): для компиляции программ под 32-битные архитектуры без привязки к конкретной операционной системе

  • AArch32 GNU/Linux target with hard float (arm-none-linux-gnueabihf): для компиляции программ под 32-битную ОС Linux

  • AArch64 bare-metal target (aarch64-none-elf): для компиляции программ под 64-битные архитектуры без привязки к конкретной операционной системе

  • AArch64 GNU/Linux target (aarch64-none-linux-gnu): для компиляции программ под 64-битную ОС Linux

Как видно из названия, наборы компиляторов имеют названия типа arm-none-linux-gnueabi, arm-none-eabi, arm-eabi и т.д. Все эти названия формируются по шаблону

arch[-vendor] [-os] - eabi
  • arch: указывает на архитектуру

  • vendor: указывает на производителя

  • os: указывает на целевую операционную систему

  • eabi: сокращение от Embedded Application Binary Interface

Например, пакет инструментов arm-none-eabi предназначен для 32-х битной архитектуры, не зависит от конкретного вендора, операционной системы и компилируется с помощью ARM EABI.

Другой пример: пакет инструментов arm-none-linux-gnueabi предназначен для 32-х битной архитектуры, но создает бинарники непосредственно для ОС Linux и использует GNU EABI.

Поскольку в данном случае в данном случае мы рассматриваем именно arm64, то нас будет интересовать прежде всего те пакеты, которые начинаются на AArch64.
И поскольку пакет AArch64 bare-metal target (aarch64-none-elf) не привязан к определенной ОС, то выберем его. Кроме того, он доступен для всех основных ОС. Однако отмечу, что, если планируется писать код именно под
Linux (в том числе Android), то лучше использовать AArch64 GNU/Linux target (aarch64-none-linux-gnu) — он создает более компактные (иногда намного меньшие) исполняемые файлы.

Для Windows доступны пакеты в двух вариантах: установочный файл exe, который устанавливает все необходимые файлы в папку C:\Program Files (x86), и
zip-архив — по сути те же самые файлы, которые мы можем распаковать в любое нужное для нас расположение. Большой разницы между файлами из exe и zip нет, но для простоты выберем exe-файл (в моем случае это файл
arm-gnu-toolchain-12.3.rel1-mingw-w64-i686-aarch64-none-elf.exe

Установка GNU Arm Embedded Toolchain для ARM64 ассемблера под Windows

После загрузки запустим установщик

Установка компилятора gas из GNU Arm Embedded Toolchain для ARM64 под Windows

Прощелкаем по шагам и в конце на последнем окне после установки установим флажок Add path to environment variable, чтобы добавить путь к компилятору и другим инструментам
в переменные среды:

Добавление пути к компилятору GNU Arm Embedded Toolchain для ARM64 в переменные среды

Если мы посмотрим на добавленный в переменные среды путь (в данном случае каталог C:\Program Files (x86)\Arm GNU Toolchain aarch64-none-elf\12.3 rel1\bin),
то мы найдем файлы компилятора и ряд других файлов:

ассемблер as из GNU Arm Embedded Toolchain для ARM64 под Windows

В этом комплекте нам понадобится прежде всего сам ассемблер — файл aarch64-none-elf-as.exe, который по коду ассемблера Arm64 создает объектный файл. Кроме того,
также потребуется файл aarch64-none-elf-as.ld, который также располагается в этой папке и который генерирует из объектного файла исполныемый файл.

Для проверки настройки откроем терминал/командную строку и выведем версию компилятора следующей командой:

aarch64-none-elf-as --version

Мы должны получить вывод типа следующего:

C:\Users\eugen>aarch64-none-elf-as --version
GNU assembler (Arm GNU Toolchain 12.3.Rel1 (Build arm-12.35)) 2.40.0.20230627
Copyright (C) 2023 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License version 3 or later.
This program has absolutely no warranty.
This assembler was configured for a target of `aarch64-none-elf'.
C:\Users\eugen>

Создание первой программы

Теперь напишем первую простейшую программу, которая просто будет выводить на консоль некоторую строку. Для этого создадим на жестком диске какой-нибудь каталог, например, C:\arm.
Создадим в этого каталоге новый файл hello.s (обычно файлы с кодом ассемблера arm имеют расширение .s). Определим в этом файл следующий код:

.global _start          // устанавливаем стартовый адрес программы

_start: mov X0, #1          // 1 = StdOut - поток вывода
 ldr X1, =hello             // строка для вывода на экран
 mov X2, #19                // длина строки
 mov X8, #64                // устанавливаем функцию Linux
 svc 0                      // вызываем функцию Linux для вывода строки

 mov X0, #0                 // Устанавливаем 0 как код возврата
 mov X8, #93                // код 93 представляет завершение программы
 svc 0                      // вызываем функцию Linux для выхода из программы

.data
hello: .ascii "Hello METANIT.COM!\n"    // данные для вывода

Для большего понимания я снабдил программу комментариями. GNU Assembler использует тот же самый синтаксис комментариев, что и C/C++ и другие си-подобные
языки: одиночный комментарий начинается с двойного слеша //. Также можно использовать многострочный комментарий с помощью символов /∗ и ∗/, между которыми помещается
текст комментария (/* текст комментария */

Вначале надо указать линкеру (в нашем случае программа ld) стартовую точку программы. В данной программе стартовая точка программы проецируется
на метку _start. И чтобы линкер получил к ней доступ, определяет _start в качестве глобальной переменной с помощью оператора global.

.global _start

Одна программа может состоять из множества файлов, но только один из них может иметь точку входа в программу _start

Далее идут собственно действия программы. Вначале вызывается инструкция mov, которая помещает данные в регистр.

mov X0, #1

Значения X0-X2 представляют регистры для параметров функции в Linux. В данном случае помещаем в регистр X0 значение «#1». Операнды начинаются со знака «#»
Число 1 представляет номер стандартного потока вывода «StdOut», в данном случае, грубо говоря, вывод на консоль.

Далее загружаем в регистр X1 адрес строки для вывода на экран с помощью инструкции ldr

ldr X1, =hello 

Затем также с помощью инструкции mov помещаем в регистр X2 длину выводимой строки

mov X2, #19

Для любого системного вызова в Linux параметры помещаются в регистры X0–X7 в зависимости от количества. Затем в регистр X0 помещается код возврата. А сам системный вызов
определяется номером функции из регистра X8. Здесь помещаем в X8 функцию с номеро 64 (функция write)

mov X8, #64

Далее выполняем системный вызов с помощью оператора svc

svc 0 

Операционная система, используя параметры в регистрах и номер функции, выведет строку на экран.

После этого нам надо выйти из программы. Для этого помещаем в регистр X0 число 0

mov X0, #0

А в регистр X8 передаем число 93 — номер функции для выхода из программы (функция exit)

mov X8, #93

И с помощью svc также выполняем функции. После этого программа должна завершить выполнение.

В самом конце программы размещена секция данных

.data
hello: .ascii "Hello METANIT.COM!\n"    // данные для вывода

Оператор .data указывает, что дальше идет секция данных. Выражение .ascii выделяет память и помещает в нее указанную далее строку.

Строка завершается символом перевода строки «\n», чтобы не надо было нажимать на Return, чтобы увидеть текст в окне терминала.

Компиляция приложения

Для компиляции приложения откроем терминал/командную строку и командой cd перейдем к папке, где расположен файл hello.s с
исходным кодом программы. И для компиляции выполним команду:

aarch64-none-elf-as hello.s -o hello.o

Компилятору aarch64-none-elf-as в качестве параметра передается файл с исходным кодом hello.s. А параметр -o указывает, в какой файл будет компилироваться
программа — в данном случае в файл hello.o. Соответственно в папке программы появится файл hello.o

Затем нам нужно скомпновать программу с исполняемый файл с помощью линкера aarch64-none-elf-ld командой:

aarch64-none-elf-ld hello.o -o hello

Полный вывод:

C:\Users\eugen>cd c:\arm

c:\arm>aarch64-none-elf-as hello.s -o hello.o

c:\arm>aarch64-none-elf-ld hello.o -o hello

c:\arm>

После этого в папке программы появится исполняемый файл hello, который мы можем запускать на устройстве с архитектурой ARM под управлением Linux.

компиляция и линковка программы на ассемблере arm64 на Windows

Тестирование приложения на Android

Итак, у нас есть исполняемый файл программы. Мы ее можем протестировать. Для этого нам нужен Linux на устройстве с архитектурой ARM. В качестве такого устройства я возьму самый распространенный вариант
— смартфон под управлением Android. Поскольку Android построен на базе Linux и как правило устанавливается на устройства с arm архитектурой.

Для установки файла на Android нам понадобится консольная утилита adb, которая устанавливается в рамках Android SDK. Android SDK обычно устанавливается
вместе с Android Studio. Но если Android Studio не установлена, то можно загрузить пакет https://dl.google.com/android/repository/platform-tools-latest-windows.zip.
В составе этого пакета или в составе SDK в папке platforms-tools можно найти нужную нам утилиту adb.

тестирование на Android программы на ассемблере arm64, скомпилированной на Windows

Для упрощения работы путь к этой утилите лучше добавить в переменные среды, чтобы не прописывать к ней полный путь.

Теперь переместим скомпилированный файл hello на устройство под Android. Для этого подключим через usb к компьютеру смарфтон с Android и перейдем в консоли с помощью команды cd к папке с файлом hello используем следующую команду

[Путь_к_файлу_adb]/adb push hello /data/local/tmp/hello

То есть в данном случае используем команду push для помещения копии файла hello на смартфон в папку /data/local/tmp/

Далее перейдем к консоли устройства Android с помощью команды:

adb shell

Далее перейдем к папке /data/local/tmp с помощью команды

cd /data/local/tmp

Затем изменим режим файла, чтобы его можно было запустить:

chmod +x hello

и в конце выполним файл hello

./hello

И на консоль должна быть выведена строка «Hello METANIT.COM!»

Первая программа на ассемблере arm64 на Android с компиляцией на Windows

Downloads

Arm GNU Toolchain is a community supported pre-built GNU compiler toolchain for Arm based CPUs.

Arm GNU Toolchain releases consists of cross toolchains for the following host operating systems:

  • GNU/Linux
    • Available for x86_64 and AArch64 host architectures
    • Available for bare-metal and Linux targets
  • Windows
    • Available for x86 host architecture only (compatible with x86_64)
    • Available for bare-metal and Linux targets
  • macOS
    • Available for x86_64 host architecture only
    • Available for bare-metal targets only

Please download the correct toolchain variant that suits your development needs.

If you need to access the previous releases of GNU Arm Embedded Toolchain or the previous releases of GNU Toolchain for the A-profile architecture, please refer to:

  • GNU toolchain releases for Embedded processors (discontinued)
  • GNU toolchain releases for A-profile processors (discontinued)

Please refer to the Release Note (linked from this page), for the full installation instructions. Each downloadable toolchain package contains a readme.txt file with full installation instructions.

The GNU Embedded Toolchain for Arm is a ready-to-use, open source suite of tools
for C, C++ and Assembly programming targeting Arm Cortex-M and Cortex-R family
of processors. It includes the GNU Compiler (GCC) and is available free of
charge directly from Arm for embedded software development on Windows, Linux and
macOS operating systems.

This repository is the original Windows version of the GNU Compiler from Arm
packaged for Visual Studio Code:

GNU Arm embedded toolchain

Install

In Visual Studio Code goto extensions (Shift+Ctrl+X), search for ‘metalcode-eu
and install the extension that is suited for your operating system.

The extension has four paths for the toolchain. You can use this in the
tasks.json.

  • arm-none-eabi.bin
  • arm-none-eabi.include
  • arm-none-eabi.lib
  • arm-none-eabi.libgcc

Here is an example of tasks.json for GNU make.

{
  "version": "2.0.0",
  "tasks": [
    {
      "label": "build firmware",
      "type": "shell",
      "command": "make test",
      "options": {
        "env": {
          "INCLUDE": "${config:arm-none-eabi.include}",
          "LIB": "${config:arm-none-eabi.lib}",
          "LIBGCC": "${config:arm-none-eabi.libgcc}/thumb/v6-m/libgcc.a",
        }
      },
      "osx": {
        "options": {
          "env": {
            "PATH": "${config:arm-none-eabi.bin}:${env:PATH}",
          }
        },
      },
      "linux": {
        "options": {
          "env": {
            "PATH": "${config:arm-none-eabi.bin}:${env:PATH}",
          }
        },
      },
      "windows": {
        "options": {
          "env": {
            "PATH": "${config:arm-none-eabi.bin};${env:PATH}",
          }
        },
      },
      "group": {
        "kind": "build",
        "isDefault": true,
      },
      "problemMatcher": "$gcc"
    }
  ]
}

With the following makefile:

.PHONY: test

test:
	@echo $(PATH)
	@echo $(INCLUDE)
	@echo $(LIB)
	@echo $(GCCLIB)

Release Notes

Version 0.1.6

Version 8-2018-q4-major for Windows
Released: December 20, 2018

Version 0.1.2

Fixed typo in path to repository causing a wrong link in the marketplace.

Added a path to the libgcc files.

  • arm-none-eabi.libgcc

When you do bare metal development, you often exclude all standard libraries
but you still need libgcc.a for integer division etc. The path to this file
contains a version number that changes with every release of the toolchain.
Using this variable you do not need to update your makefiles with every new
release of the toolchain.

Version 0.1.0

Version 7-2018-q2-update for Windows

Version 0.0.5

Operating system specific PATH environment variable.

Version 0.0.2

Changed ${env:HOME} to ${env:USERPROFILE}.

Version 0.0.1

GNU Make 4.2.1

Version 7-2017-q4-major for Windows
Released: December 18, 2017

Понравилась статья? Поделить с друзьями:
0 0 голоса
Рейтинг статьи
Подписаться
Уведомить о
guest

0 комментариев
Старые
Новые Популярные
Межтекстовые Отзывы
Посмотреть все комментарии
  • Windows export certificate to pem
  • Как сделать копию рабочего стола на windows 10
  • How to change network profile in windows
  • Телеграмм демонстрация экрана windows
  • Браузеры для windows на gecko