VSCode, SourceCraft Code Assistant и микроконтроллеры

Сегодня разработка прошивок для микроконтроллеров обычно требует заметно больше времени и ресурсов, чем создание собственно схемы и платы. Со времён ковида прошли времена безраздельного владычества STM32, и теперь регулярно приходится осваивать новые железки. При этом для них зачастую приходится ваять программный инструментарий и библиотеки — поскольку предоставленное производителем обычно неудобно.

В этой статье я расскажу, как использовать VSCode для разработки прошивок под разные архитектуры и как мне в этом помогает SourceCraft Code Assistant от разработчиков Yandex Cloud & Yandex Infrastructure.

Зачем нужна ещё одна статья, как настроить VSCode для разработки под микроконтроллеры

В сети (и в том числе на Хабре) существует масса инструкций про настройку VScode для работы с микроконтроллерами. Зачем yet another one? Потому что в тех, что есть, я не обрёл детального и полного решения для своих требований. Тем не менее — спасибо авторам!

Я люблю, когда мне удобно, и не люблю, когда мне неудобно. Поэтому тут я описал, как я делал себе удобно. Возможно (скорее всего), для других начальных данных и других предпочтений мой опыт будет неприменим — и это нормально.

Я разработчик электроники, и практически весь нужный мне инструментарий существует только под Windows. Поэтому про Windows в дальнейшем и будет идти речь.

Требования же диктуются решаемыми задачами. Моя деятельность состоит в написании и поддержке десятков прошивок в год для разных железок с микроконтроллерами от различных производителей, с разными ядрами. Конечно, есть разработчики, которые годами пилят один и тот же проект под одну и ту же железку — им мой дискомфорт чужд. Я работаю с STM32, GD32, WCH, а также софтверным RISC‑V ядром в ПЛИС GOWIN. И ещё пишу на Verilog для тех же GOWIN. А ещё мне зачастую нужно кодить всякие штуки на Python.

Кратко скажу, что описанные ниже примеры взяты из реальных, а не синтетических проектов. Verilog и Risc‑V — это код для наших заводских стендов‑джиг, которые тестируют тысячи плат Яндекс Станций в день. Код для STM32, GD32 и WCH — в основном RND‑проекты для Яндекса, а также Pet Projects, разошедшиеся по всей стране, типа плат для школьных соревнований на квадрокоптерах под эгидой «Кружкового движения». И ещё мне нужно рассказывать про это всё студентам и помогать им с железом и прошивками. Поэтому я избегаю дорогих решений типа J‑Link и CLion, да и вообще платные типа Keil не жалую.

Я не пользуюсь HAL от производителей: пишу на регистрах или делаю свой, который мне удобен. HAL от ST мне противен, HAL от GD ещё хуже, а HAL от GOWIN содержит неприятные баги типа uint8_t для адресов, которые могут быть 16-битными. Впрочем, «HAL или не HAL» — это тема для священной войны, не будем об этом.

Обычно производитель предоставляет свою среду разработки: как правило, на основе Eclipse со своим плагином, компилятором GCC и своим отладчиком — например, форком OpenOCD. У ST это CubeIDE, у GOWIN — MCU Designer, у WCH — MounRiver Studio (с форком GCC, в котором поддерживается реализованное в их MCU аппаратное ускорение переключения стека при прерывании attribute((interrupt("WCH-Interrupt-fast")) ). При этом, конечно же, плагины несовместимы между собой, поэтому предполагается держать на компе несколько этих Eclipse. А версия компилятора в комплекте та, которую производитель заложил семь лет назад и с тех пор не трогал, потому что кому нужен этот С++20. А мне нужен (например, std::span), и вообще я не люблю искусственных ограничений.

Более того, в плагинах порой выпилено удобное и добавлено ненужное. Например, в плагине MCU Designer от GOWIN убрана возможность по кнопке запускать произвольный exe, а значит, нельзя сделать заливку прошивки прямо из IDE по кнопке. Нужно переключаться на окно их утилиты программатора и мышью в GUI запускать процесс заливки. Меня такое, признаться, бесит. Но зато в указанном плагине сделана проверка лицензии! А больше там ничего и нет.

GigaDevice стоят особняком: они предоставляют не IDE, а расширения для Keil, который пользователям предлагается купить самостоятельно. Мне не нравится Keil, я не хочу изучать отдельную IDE ради GD, меня вполне устраивает бесплатный инструментарий.

В итоге я многие годы жил на наборе: стандартный Eclipse IDE for Embedded C/C++ Developers без всяких сторонних плагинов + скачанные GCC‑компиляторы для ARM и RiscV. Не всё гладко с Eclipse: он очень долго запускается, нередко виснет, отладка работает медленно и ненадёжно, а ещё там есть бага с Code Folding, которую за последние 15 лет так и не поправили:

Эта функция была свёрнута, но самопроизвольно как бы развернулась. Но не совсем, а как‑то половинчато, с квадратиками этими. Бесит, знаете ли.

Друзья не раз советовали мне перебираться на VScode. Я делал несколько подходов к этому снаряду, но всякий раз отступал. Несмотря на обилие инструкций о настройке, построить удобную систему не получалось.

Вообще, VScode — это продвинутый текстовый редактор, который умеет запускать внешние исполняемые файлы при помощи механизма tasks и у которого есть мощный магазин плагинов. Поэтому подходов к задаче «VScode + MCU» есть два: находим Единый‑Правильный‑Плагин‑Для‑Всего или качаем кучу специализированных плагинов и настраиваем их.

Проблема Плагина‑Для‑Всего в том, что он содержит не Всё, а то, что разработчики сочли нужным и полезным. А остальное осталось под капотом, и это никак не настроить. Например, мне нужны разные компиляторы для ARM и RiscV — причём порой разных версий для разных проектов. Или настройки выходного формата: выберите что‑то одно — bin или hex. А если мне нужны оба? Увы мне. Или поддержка железных программаторов‑отладчиков: есть STLink, J‑Link, но нет Black Magic Probe (а у меня именно он, благодаря универсальности).

Я попробовал — с одинаковым результатом неприменимости к моим требованиям — EmbeddedIDE и PlatformIO.

Куча специализированных плагинов норм, но в инструкциях я не нашёл, как сделать себе удобно. Я хочу, чтоб я мог добавить‑удалить‑переименовать файлы в проекте и чтобы при этом не нужно было каждый раз что‑то настраивать. Например, мне претит изучать ещё один язык программирования, чтобы написать скрипт CMake, класть в каждую папку проекта CMakeLists.txt и редактировать его при каждом изменении. В Eclipse в этом смысле всё удобно.

И тут я познакомился с AI-ассистентом

В сентябре прошлого года Яндекс выпустил в публичную бету Code Assistant. На Хабре об этом тоже есть отдельный рассказ. Если кратко, это AI‑помощник для разработчиков, который совместим с популярными интегрированными средами разработки.

Для работы с ассистентом были плагины под PyCharm Community и VScode. Я спросил: «А под Eclipse?» «Нет, — ответили мне. — Но если нужен, то можешь помочь нам с этим».

Тогда коллеги выразили сомнение, что нейросеть будет хорошо справляться с кодом для микроконтроллеров — учили‑то её на более высокоуровневом коде. Ха, не попробуешь — не узнаешь. Но ладно человеческий С++, а как насчёт верилога? Мне как раз нужно было соорудить сигма‑дельта‑модулятор.

Я поставил VScode, нашёл плагин для подсветки верилога и начал писать. Просто как в текстовом редакторе. SourceCraft Code Assistant стал предлагать приятную мелочь:

Как он догадался, что я именно так хотел назвать этот регистр?

Потом блоки покрупнее:

Потом он предложил целый блок для синхронизации: почитав предложенное, я понял, что оно лучше, чем собирался написать я.

Дальше я попробовал уже С++, тоже используя VScode просто как редактор, переключаясь в Eclipse для компиляции и прошивки.

И более крупные блоки:

Конечно, нужно внимательно смотреть, что он предлагает, потому что эта штука всё же не читает мысли и нередко промахивается в своих предположениях. Но процесс написания кода ускорился многократно. Исчезла необходимость вручную писать простыни следующего толка:

Там ещё 15 подобных строк, и SourceCraft Code Assistant мне их последовательно предлагает. Остаётся принимать предложенное и править делитель — ИИ просто не знает, какой у меня на какой цепи стоит.

Попробовав на следующий день кодить в Eclipse по‑старому, я понял, что всё — по‑старому мне неудобно. Это что, нужно руками писать этот вот очевидный кусок?

Ещё я попробовал другой ИИ‑плагин под Eclipse. Их есть с десяток во главе с Copilot от GitHub, но почти все обложены санкциями, а меня бесит идея включать VPN, чтоб покодить. Тот плагин, который заработал, мне понравился гораздо меньше, чем AI‑ассистент Яндекса, — хуже угадывает.

В общем, я пришёл к необходимости всё же сделать VScode рабочим инструментом.

Компоненты и инструментарий

Общий обзор

Для начала нам понадобятся компиляторы и смежные инструменты типа OpenOCD, то есть tools, или Toolchain. В корне диска С создаётся папка, инструменты скачиваются из открытых источников или комплектов софта производителей и складываются в эту папку.

Я пробовал использовать x‑packs, но мне не понравилось: для этого нужно поставить менеджер пакетов xpm, а для этого нужно поставить менеджер пакетов npm от Node.js, а для этого нужно поставить ещё что‑то. Важно внимательно следить, чтобы инструменты ставились в нужную папку, в пути которой нет пробелов и русских букв. Ещё я не люблю напихивать кучу путей в системный PATH, особенно длинных.

Кроме того, производители пишут свои утилиты, а также не стесняются делать уникальные форки инструментов — и всё это отсутствует в x‑packs. Эти инструменты нужно положить в удобное место — причём так, чтобы они не подрались с ранее установленными. Например, компилятор от WCH, OpenOCD от GigaDevice и прошивальщик от GOWIN.

Теперь про проекты. В корне папки проекта есть папка для VSCode и несколько файлов, которые копируются из проекта в проект без изменений или с минимальными изменениями:

• папка.vscode, в которой лежат четыре файла настроек VScode:

  • tasks.json — набор тасков для билдинга, очистки и заливки прошивки;

  • settings.json — настройки разных плагинов;

  • launch.json — настройки для запуска отладки;

  • c_cpp_properties.json — настройки плагина C/C++, в частности, особенности анализа кода;

• самописный makefile;

• файлы version.h и version.cpp, в которых есть строковые константы с временем компиляции и названием конфигурации;

• файл.svd (если удалось найти).

Примеры всех этих файлов есть на Gitverse. Уточнение: это по большей части мои Pet Projects и проекты для Бауманки, к Яндексу они прямого отношения не имеют.

Переходим к железным программаторам‑отладчикам. Я проверил работу с STLink + stlink_server (нативный, поддерживает только STM32), STLink + OpenOCD (работает и с GD32), DAP‑Link + OpenOCD, Black Magic Probe. Всё работает, то есть позволяет прошивать и построчно отлаживаться. Есть ощущение, что Black Magic Probe работает немного быстрее. И это логично — здесь нет дополнительной прокладки в виде сервера OpenOCD. Всё при этом работает быстрее и надёжнее, чем в Eclipse.

И немного про процессы разработки:

• компиляция и очистка — вызов make через таски VSCode;

• прошивка — через таски: вызов make или нужной прошивальной утилиты;

• отладка — Launch с нужными опциями.

А теперь подробности.

Папка с компиляторами и прочим 

Папку я назвал YaStudio (Yet Another Studio). И вот что в ней есть:

• arm‑none‑eabi‑gcc — набор компиляторов для ARM;

• build‑tools — там лежит make.exe и присные;

• Gowin Programmer — прошиватор для ПЛИС GOWIN;

• OpenOCD — сервер для прошивки и отладки;

• Quetima — наш терминал, написанный для удобства, потому что другие не так хороши, типа того же Terminal_bray.exe (который лежит ниже просто на всякий случай);

• riscv‑none‑elf‑gcc — набор компиляторов для RiscV;

• versions.txt — файл с версиями компиляторов в папке.

Плагины VSCode

Необходимое:

• C/C++ Extension Pack;

• Cortex‑Debug;

• RTOS Views (ставится вместе с Cortex‑Debug, нужно для удобной отладки RTOS).

Полезное:

• IntelliBoba — SourceCraft Code Assistant от Яндекса, ради него всё и затевалось;

• ARM assembly editor — если нужно редактировать ассемблерные файлы;

• GNU Linker Map files — подсветка для.map‑файлов, если нужно их анализировать;

• ELFInsight — анализатор.elf‑файлов с удобной таблицей ресурсов и графом вызовов;

• LinkerScript — если хочется удобно редактировать скрипты линкера;

• MemoryView — для удобного вида содержимого памяти при отладке;

• Peripheral View — анализирует.svd‑файл, в котором содержится информация про все регистры и все биты, и во время отладки показывает их значения (увы, не для всех МК получается добыть такой файл).

Приятные мелочи:

• Overtype — по кнопке Insert переключает режим ввода: вставка или замена. Я часто пользуюсь режимом замены, а в VScode его исходно нет. Но вот есть плагин.

• Task Buttons — позволяет поместить на строку статуса кнопки и запускать таски по нажатию на них:

• TODO Highlight v2 — подсвечивает определённые слова в коде, например, TODO, FIXME, DEBUG. Как в Eclipse, но только более мощно, гибко и настраиваемо.

Ещё приятная настройка — при сохранении файла удалять пробелы в конце строк (как в Eclipse): Ctrl + Shift + P → (ввести user) → Preferences: Open User Settings → (искать files trim) → поставить галку Files: Trim Trailing Whitespace.

Отдельно скажу про плагины для Python и Verilog. Они мне нужны, поскольку требуется кодить на питоне и верилоге.

• Verilog‑HDL / SystemVerilog / Bluespec SystemVerilog;

• Python (он поставит и остальные в комплекте);

• Python debugger;

• Pylance.

makefile

Утилита make использует скриптовый файл makefile, в котором написано, что и с какими настройками запускать. И она же запускает исполняемые файлы компилятора, передавая им настройки и исходники. Скрипт makefile — это по сути ещё один язык программирования.

Откуда берётся файл makefile?

В случае Eclipse его генерирует плагин. Плагин анализирует проект и создаёт файлы makefile для каждой папки. Опции makefile задаются галочками в окнах плагина:

Галочек много, поэтому с гибкостью Eclipse я почти не имел проблем. Тут речь про обычный плагин, а не уникальные плагины от производителя — там бывает урезанный набор опций.

Точно так же работают и плагины PlatformIO и EmbeddedIDE: в их настройках можно указать опции, в соответствии с которыми будут генерироваться файлы makefile. Опций удручающе мало (очевидно, чтобы не пугать ардуинщиков и начинающих), и гибкости мне катастрофически не хватило.

Я перебрал несколько вариантов генерации makefile и понял, что make — достаточно мощная система, чтобы решить мои задачи просто на языке makefile, без всяких дополнительных инструментов. Например, в одной из инструкций описано использование CMake с плагином CMake Tools. Но мне тогда нужно было бы изучить его скриптовый язык, чтоб CMake сгенерировал скрипт для генератора Ninja или nmake, чтобы этот генератор сгенерировал нужные скрипты makefile. Логичный вопрос: зачем изучать скриптовый язык CMake, если можно изучить скриптовый язык makefile и сразу написать на нём?

Конечно, есть задачи, для которых CMake является мощным и необходимым инструментом. Например, если у вас здоровенный проект на сотни‑тысячи файлов, которые нужно скомпилировать под три платформы (Windows, Linux, iOS), при этом автоматически подключив нужные библиотеки (для каждой платформы свои). Но это не мой случай: у меня куча проектов, в каждом меньше сотни файлов, единственная платформа и нет внешних библиотек.

Так что я написал свой универсальный makefile (один), который умеет всё нужное. Я просто копирую его из проекта в проект, редактируя только список папок и настройки ядра. Makefile лежит в корневой папке, а make анализирует все подпапки и компилирует все найденные исходники, так что список исходников не нужен.

Угадайте, кто помогал мне писать makefile. Точнее, что: он всё‑таки неодушевлённый.

makefile для ARM 

Основы работы make я описывать не буду, поскольку этой информации много и её легко найти здесь же, на Хабре.

Начнём писать на скриптовом языке makefile.

######################### Project Settings #########################
PRJ_NAME = Prj
# What to include, in form dir1 dir2 dir3...
INCLUDE_DIRS = ./ Audio FileSys lib usb yartos
# What to define in form MYDEF1 MYDEF2=18 MYDEF3... 
DEFINS = 

Тут всё просто: переменная PRJ_NAME задаёт, как будут называться итоговые файлы .elf, .hex, .bin. Я в конце концов перестал менять это название от проекта к проекту: Prj и Prj, ничем не плохо. Заодно нет нужды при смене имени заменять настройки отладки VScode (об этом дальше).

INCLUDE_DIRS — список папок через пробел, в которых искать файлы, которые нужно инклюдить. (Как это сказать по‑русски? «Подключаемые файлы»? Смысл сильно страдает, так что давайте не будем русифицировать термины в ущерб понятности.)

DEFINS — список defines, если понадобится. В этом проекте он не нужен, поэтому после знака = ничего нет.

Дальше утилите нужно понять, что делать. Обычно для компиляции и сборки вызывают make all. Но у меня несколько конфигураций:

• Release, в которой включены все оптимизации и убрана вся отладочная информация.

• Debug, где вся оптимизация отключена, а отладочной информации по максимуму.

• FromBoot — это как Release, только со смещением адресации. Это нужно для запуска кода бутлоадером. Бутлоадер лежит в начале флешки и занимает, скажем, 32 килобайта. А основной код кладётся дальше, и поэтому его адресация начинается со смещением.

Обычно под каждую конфигурацию делают свой makefile. Но это неудобно: они же похожи как две капли воды и отличаются только парой опций. Внёс изменения в один — изволь не забыть поправить и другие. Можно, конечно, сделать один основной makefile и инклюдить его из других, уникальных для каждой конфигурации. Но зачем всё это? Давайте просто сделаем один универсальный и будем запускать компиляцию в виде make build_Release или make build_Debug.

######################### Figure out what to do #########################
# Target must be in the following form: build_Release, clean_Debug, flash_Fromboot
# The first word is the action (build, clean, flash); 
# the second is the name of the configuration and the name of the OUT_DIR.
INPUT_WORDS = $(subst _, ,$(MAKECMDGOALS)) # Replace '_' with ' '
ACTION = $(word 1,$(INPUT_WORDS))
GOAL_NAME = $(word 2,$(INPUT_WORDS))
OUT_DIR = $(GOAL_NAME)
# Run Action (build_Release -> build; clean_Debug -> clean; flash_Fromboot -> flash)
$(MAKECMDGOALS): $(ACTION)

Опять же всё просто. При вызове таска утилите make передаётся указание build_Release, или clean_Debug, или flash_Fromboot. Указание лежит во встроенной переменной $(MAKECMDGOALS). Заменяем подчёркивание на пробел и получаем пару слов: первое — что делать, второе — название конфигурации. Для упрощения выходная папка OUT_DIR будет называться так же, как конфигурация. 

Теперь нужно, чтобы по команде build_Release было запущено собственно то, что делать. В последней строке это и достигается: она превратится в build_Release: build. 

######################### Common Cfg Settings #########################
MCU = cortex-m4
FLOAT_FLAGS = -mfloat-abi=hard -mfpu=fpv4-sp-d16 -fsingle-precision-constant -Wdouble-promotion -Wfloat-conversion -Wfloat-equal
WARNING_FLAGS = -Wall -Wlogical-op -Werror
DISABLED_WARNINGS = -Wno-address-of-packed-member -Wno-unknown-pragmas -Wno-volatile
COMMON_FLAGS = -mcpu=$(MCU) -mthumb -fmessage-length=0 -ffunction-sections -fdata-sections -ffreestanding $(FLOAT_FLAGS) $(WARNING_FLAGS)
CPP_FLAGS = -std=gnu++20 -fabi-version=0 -fno-exceptions -fno-rtti -fno-use-cxa-atexit -fno-threadsafe-statics $(DISABLED_WARNINGS) $(OUTPUT_ASM)
C_FLAGS = -std=gnu17 $(OUTPUT_ASM)
# Add this to build commands. Nothing to change here.
OBJ_FLAGS = -MMD -MP -MF"$(@:%.o=%.d)" -MT"$@" -c -o "$@" "$<"
ELF_NAME = $(OUT_DIR)/$(PRJ_NAME).elf
LINKER_FLAGS = -Xlinker --gc-sections --specs=nano.specs --specs=nosys.specs -nostartfiles -Wl,-Map,"$(OUT_DIR)/$(PRJ_NAME).map" -o "$(ELF_NAME)”

В этой части нужно настроить опции компилятора для ядра MCU. Можно было бы всё свалить в одну кучу, то есть длинную строку, но для лучшей читаемости группы флагов помещены в отдельные переменные. Я пройдусь по некоторым опциям.

Тут у нас Cortex‑M4. У него есть сопроцессор для работы с числами с плавающей точкой, поэтому добавлена переменная FLOAT_FLAGS с соответствующими опциями.

WARNING_FLAGS содержит всё про warnings: включить их все, провести логические операции и ещё трактовать warnings как ошибки.

DISABLED_WARNINGS описывает, по каким поводам не беспокоить.

-Wno-address-of-packed-member. Иногда мне нужен адрес элемента упакованной структуры, этот адрес будет не aligned (то есть не кратен 4) — и это нормально. Например, в структуре Color_t {uint8_t R, G, B, W} мне часто нужно обращаться к отдельным компонентам через указатель.

-Wno-unknown-pragmas. В VScode можно сделать сворачивание (folding) части кода при помощи такой конструкции:

#pragma region // ==== Begin of the area ====
...
#pragma endregion // End of the area

Эти две прагмы компилятору неизвестны — и норм, пусть просто игнорирует. 

-Wno-volatile. Отключает предупреждение о применении конструкций типа |= и &= к volatile‑объектам. Под спойлером подробное объяснение, как так вышло.

Сага про -Wno-volatile

В стандартах C++20 и C++23 привычные нам конструкции |=, &= и подобные, применяемые к volatile‑объектам, помечены как deprecated. При их обнаружении будет появляться предупреждение: compound assignment with 'volatile'‑qualified left operand is deprecated.

Почему? Я нашёл тому следующее обоснование.

Код A |= B создаёт впечатление атомарности, но это не так, потому что в реальности это три операции:

1. Прочитать содержимое A в регистр проца R.

2. Выполнить операцию R | B.

3. Записать содержимое R в A.

При этом на этапе (2) содержимое A может измениться. Например, это регистр флагов, и там появился новый флаг — но это уже не будет учтено, и этот новый флаг будет затёрт. И результат будет отличаться от ожидаемого.

Именно поэтому регистры флагов во всяких UART, I2C и прочих блоках сделаны хитро — флаг обнуляется при чтении или вообще read‑only. Такой подход позволяет обеспечить атомарность операций с флагами. Но это положение дел платформоспецифично, то есть обеспечивается особенностями железа, а не языка программирования C++, и это непорядок. Поэтому комитет решил ввести такое ограничение с целью принудить программистов использовать std::atomic.

Можно вместо A |= B написать A = A | B, тогда предупреждения не будет: тут видна неатомарность. Но в нашей Embedded сфере бытия конструкции |= и &= широко распространены для установки и чтения бит в регистрах, они точно работают как надо и не хочется их переписывать. Поэтому я отключаю указанное предупреждение опцией ‑Wno‑volatile.

COMMON_FLAGS — это опции и для компилятора С++, и для С, и для линкера.

CPP_FLAGS — опции, которые нужно передать компилятору C++. У нас указан стандарт языка — gnu++20. И сказано не использовать exceptions и RTTI: в рамках embedded‑системы это реализуется настолько трудно и дорого по ресурсам, что эта функциональность на практике не используется. Ещё там есть опция генерировать ассемблер, но про это чуть позже.

C_FLAGS — то, что нужно передать компилятору C. Тут указан только стандарт языка.

OBJ_FLAGS — тут указано, что делать с исходниками и что нужно создавать файлы зависимостей такие же, как объектные.

ELF_NAME — имя.elf‑файла. Оно много где используется, так что я его вынес в переменную для ясности.

LINKER_FLAGS — тут указано не использовать стандартные стартовые файлы, а стандартную библиотеку использовать в минималистичной реализации nano (потому что у нас опять же embedded‑система). А также указано, куда класть выходной.elf‑файл и что нужно сгенерировать.map‑файл (его полезно почитать, если возникает вопрос «кто съел СТОЛЬКО памяти»).

Дальше в файле три конфигурации. Они очень похожи, так что рассмотрим одну и её отличия от других.

######################### Individual Cfg Settings #########################
####### Release Cfg Settings #######
ifeq "$(GOAL_NAME)" "Release"
COMMON_FLAGS += -Os
LINKER_FLAGS += 
LD_SCRIPT = GD32F405RG.ld
# Comment / uncomment the following lines to produce .hex and/or .bin output
HEX_NAME = $(OUT_DIR)/$(PRJ_NAME).hex
# BIN_NAME = $(OUT_DIR)/$(PRJ_NAME).bin
OUTPUT_ASM = -Wa,-adhlns="$@.lst"

В конфигурации Release к пачке COMMON_FLAGS добавляется флаг оптимизации по размеру -Os. И никакой отладочной информации.

А в конфигурации Debug указано, что нужно отключить оптимизацию и обеспечить максимальное количество отладочной информации.

COMMON_FLAGS += -O0 -g3

Cтроки HEX_NAME и BIN_NAME указывают, какой формат должен иметь результирующий файл прошивки. Можно раскомментировать обе строки — тогда получим и .hex, и .bin.

Последняя строка с переменной OUTPUT_ASM указывает, нужно ли генерировать ассемблерный листинг (при этом нужно не забыть отключить, если была включена, опцию оптимизации линкера –flto). Иногда бывает нужно почитать ассемблер, чтобы выяснить, правильно ли компилятор нас понял или на сколько инструкций раскладывается какая-нибудь конструкция. Например, использует ли компилятор специальные эффективные DSP-инструкции при сооружении цифрового фильтра. 

Конфигурация Fromboot такая же, как Release, и отличается только файлом скрипта линкера:

LD_SCRIPT = GD32F405RG_FromBoot.ld

…и именем выходных файлов: к ним добавлен префикс fw, по нему бутлоадер ищет файл прошивки.

HEX_NAME = $(OUT_DIR)/fw$(PRJ_NAME).hex
BIN_NAME = $(OUT_DIR)/fw$(PRJ_NAME).bin

Затем находятся настройки компиляторов:

######################### Toolchain ######################### 
CPP_CMP = arm-none-eabi-g++
C_CMP = arm-none-eabi-gcc
OBJCPY = arm-none-eabi-objcopy
SZ = arm-none-eabi-size
GDB = arm-none-eabi-gdb  # Required for flashing using BMP
# GDB COM port: required for flashing using BMP
GDB_COM = \.COM5

Указаны имена файлов компиляторов С++ и С, утилиты objcpy (она делает .hex или .bin из .elf), утилиты size для демонстрации размера. Для прошивки мне удобно применить отладчик gdb, поскольку я использую Black Magic Probe — он подключён к COM5, что и указано.

Затем расположены функции и опции, не требующие настройки.

######################### Do not touch #########################
.PHONY: .FORCE print_size clean flash # "virtual" symbols to "rebuild" them always

Тут словом PHONY указано, что нужно всегда выполнять пункты print_size, clean, flash и всё, что помечено словом .FORCE.

# Current datetime
TIMESTAMP = $(shell "date" "+%Y%m%d_%H%M")

В эту переменную помещается время компиляции в форме 20250318_1400.

# Build include flag string out of INCLUDE_DIRS list
INCLUDE_STR = $(addprefix -I./,$(INCLUDE_DIRS))

В эту переменную помещается строка, построенная из INCLUDE_DIRS: каждый путь предваряется префиксом –I./, чтобы, например, из Audio получить –I./Audio.

# Build define flag string out of DEFINS list, surrounding with double quotes
ToUppercase = $(shell echo $(1) | tr '[:lower:]' '[:upper:]')
# add BUILD_CFG_GOALNAME=1 define, uppercasing GOAL_NAME
DEFINS += BUILD_CFG_$(call ToUppercase,$(GOAL_NAME))=1 

Тут к переменной DEFINS добавляется название компилируемой конфигурации строчными буквами: RELEASE=1, или DEBUG=1, или FROMBOOT=1. Это нужно, чтобы учесть конфигурацию в коде. Например, для ядра Cortex‑M0 при компиляции FROMBOOT требуется скопировать в RAM таблицу векторов прерываний — поскольку у этого ядра адрес таблицы не настраивается.

DEFINE_STR = $(patsubst %,-D"%",$(DEFINS))
COMMON_FLAGS += $(DEFINE_STR) 

Тут к переменной COMMON_FLAGS добавляется DEFINE_STR, а она строится из DEFINS окружением каждого дефайна кавычками и добавлением префикса ‑D. Например, RELEASE=1 превратится в ‑D «RELEASE=1».

Затем нужно найти все исходники (*.cpp, .c, .S) во всех папках проекта, в том числе вложенных. У make для этого есть функция wildcard, но она умеет искать файлы только в указанной папке. Как быть? Задача имеет несколько решений — тут применяется функция «рекурсивной wildcard»:

# Recursive wildcard to iterate subdirs of any depth
rwildcard = $(wildcard $1$2) $(foreach d,$(wildcard $1*),$(call rwildcard,$d/,$2))

Теперь ищем этой функцией все исходники и кладём их имена вместе с путём в SRCS:

# Find all .cpp, .c and .S files in all subfolders of ../ 
SRCS = $(call rwildcard,./,*.c) $(call rwildcard,./,*.cpp) $(call rwildcard,./,*.S)

Убираем из всех полных имён префикс ./:

# Remove leading ./ 
SRCS := $(patsubst ./%,%,$(SRCS))

Заменяем расширение всех файлов на.o и помещаем результат в переменную OBJS. Именно скомпилированные из исходников объектные файлы нам нужны для дальнейшей линковки.

# Replace .cpp, .c, .S with .o
OBJS = $(SRCS:.cpp=.o) # Take all srcs replacing .cpp with .o
OBJS := $(OBJS:.c=.o)  # Replace .c with .o
OBJS := $(OBJS:.S=.o)  # Replace .S with .o

Нам потребуется создать дерево папок проекта в папке компилируемой конфигурации — пусть это в дальнейшем будет Release для упрощения беседы. Например, вот такое:

Для этого нам нужны имена папок.

# Find all source-containing folders; remove ending /; remove .
SUBDIRS = $(filter-out .,$(patsubst %/,%,$(sort $(dir $(SRCS)))))

Читаем справа налево:

1. Получаем имена папок из полных путей файлов в SRCS.

2. Сортируем их. При этом удаляются повторяющиеся имена, а их там полно — ведь в каждой папке несколько файлов, значит, и имя папки будет повторяться соответствующее количество раз.

3. Удаляем символ / в конце каждого пути.

4. Вычёркиваем из списка корневую папку, обозначаемую точкой.

# Search src here. Nothing to change here.
VPATH := ../

Тут мы указываем, что путь к исходникам начинается с ../, то есть из папки выше — из корня проекта. Логично, мы же работаем в папке Release, так что для получения объектного файла lib/uart.o (полный путь Release/lib/uart.o) исходник будет найден по пути ../lib/uart.cpp.

Далее описан вполне обычный алгоритм билдинга.

######################### Build #########################
# Add OUT_DIR prefix to OBJS
OBJS := $(addprefix $(OUT_DIR)/, $(OBJS))

Тут к пути каждого объектного файла добавляем имя выходной папки.

# Include dependents *.d (ignore if not exist) to rebuild what depends on changed .h
-include $(OBJS:.o=.d) 

Тут указываем, что нам нужны не только объектные файлы, но и файлы зависимостей. Они нужны, чтобы перекомпилировать исходник, если изменился один из файлов, от которых он зависит, — например, какой-нибудь .h. Минус перед include означает, что в случае отсутствия файлов нужно их просто игнорировать. И в самом деле — в первый раз никаких .d-файлов ещё нет.

# Build: Require dir tree, .elf file, .hex, .bin, .siz
build: $(OUT_DIR)/out_subdirs $(ELF_NAME) $(HEX_NAME) $(BIN_NAME) print_size

Тут всё как обычно. Чтобы указание build стало выполненным, требуется:

• наличие всех папок out_subdirs внутри нашей выходной папки;

• файла Release/Prj.elf;

• файла Release/Prj.hex (если только HEX_NAME не был закомментирован);

• файла Release/Prj.bin (если только BIN_NAME не был закомментирован);

• а также выполнение print_size (что нужно делать всегда, поскольку выше мы пометили этот пункт словом .PHONY).

# Construct dir tree: out_dir/dir1, out_dir/dir2, ...
$(OUT_DIR)/out_subdirs:
	@mkdir -p $(addprefix $(OUT_DIR)/, $(SUBDIRS))

Тут создаётся дерево папок. При этом к пути каждой приписывается название выходной папки.

# Construct .elf
$(ELF_NAME): $(OBJS)
	@echo 'Linking $@'
	@$(CPP_CMP) $(COMMON_FLAGS) -T $(LD_SCRIPT) $(LINKER_FLAGS) $(OBJS)

Тут линкуется выходной.elf‑файл. Чтобы это сделать, есть пререквизит — наличие объектных файлов, список которых находится в переменной OBJS. Если это уже выполнено или когда это будет выполнено, запустится линкер с флагами (общими и линкера), указанием скрипта линкера и списка объектных файлов.

А чтобы выполнить пререквизит в виде объектников, их нужно скомпилировать!

### Compile objs ###
# Special rule for version.cpp: always rebuild
VERSION_DEFINS = -D"BUILD_TIME=$(TIMESTAMP)" -D"BUILD_CFG=$(call ToUppercase,$(GOAL_NAME))"
$(OUT_DIR)/version.o: version.cpp .FORCE
	@echo 'Building $<'
	@$(CPP_CMP) $(COMMON_FLAGS) $(VERSION_DEFINS) $(INCLUDE_STR) $(CPP_FLAGS) $(OBJ_FLAGS)

Тут особые условия для файла version.cpp, в котором только и есть, что две строковые константы со временем компиляции и названием конфигурации. Но значения констант известны только во время компиляции, а это значит, их нужно передать компилятору в виде дефайнов. Поэтому мы их помещаем в переменную VERSION_DEFINS и в дальнейшем передаём её компилятору.

Словом .FORCE указываем, что этот файл нужно компилировать всегда — даже если уже есть ранее скомпилированный объектник. Это нужно, чтобы в константе всегда содержалось время последней компиляции.

Затем компилируем все файлы.cpp,.c и.S.

# cpp
$(OUT_DIR)/%.o: %.cpp
	@echo 'Building $<'
	@$(CPP_CMP) $(COMMON_FLAGS) $(INCLUDE_STR) $(CPP_FLAGS) $(OBJ_FLAGS) 
# c
$(OUT_DIR)/%.o: %.c
	@echo 'Building $<'
	@$(C_CMP) $(COMMON_FLAGS) $(INCLUDE_STR) $(C_FLAGS) $(OBJ_FLAGS)
# S
$(OUT_DIR)/%.o: %.S
	@echo 'Building $<'
	@$(C_CMP) -x assembler-with-cpp $(COMMON_FLAGS) $(INCLUDE_STR) $(OBJ_FLAGS) 

В итоге у нас получится куча объектных файлов. Таким образом, условие для запуска линкера будет выполнено, и он соберёт .elf-файл. 

Затем можно соорудить .hex и .bin:

# Output .hex
$(HEX_NAME): $(ELF_NAME)
	@echo 'Constructing $@'
	@$(OBJCPY) -O ihex "$(ELF_NAME)" "$(HEX_NAME)"

# Output .bin
$(BIN_NAME): $(ELF_NAME)
	@echo 'Constructing $@'
	@$(OBJCPY) -O binary "$(ELF_NAME)" "$(BIN_NAME)"

И вывести объёмы занятых FLASH и RAM:

# Print size
print_size: 
	@echo 'Size:'
	@$(SZ) --format=berkeley "$(ELF_NAME)"

На этом билдинг закончен!

Вот что вызывается при указании clean_Release:

######################### Clean #########################
clean:
	@rm -rf $(OUT_DIR)
	@echo 'Done.'

Очень просто — удаляется выходная папка. Release или Debug, например.

А вот как происходит заливка прошивки при указании flash_Release:

######################### Flash it ######################### Using BlackMagicProbe
flash:
	@$(GDB) -q -ex "target extended-remote $(GDB_COM)" -ex "mon swdp_scan" -ex "att 1" -ex "load $(HEX_NAME)" -ex "det" -ex "quit"

Вызывается arm-none-eabi-gdb с указанием:

• подключиться к отладчику через COM5;

• просканировать SWD;

• подключиться к первому найденному процу (он у нас всегда один);

• загрузить Release/Prj.hex;

• отключиться;

• выйти.

Можно было бы устраивать заливку не через make, а прописать вызов exe с флагами напрямую в таске. Как лучше? В целом без разницы. Можно так, можно эдак. 

makefile для RiscV

В наших стендах‑джигах используется ПЛИС GOWIN 2A-18C. В ней сооружено микроконтроллерное ядро picoRV — это форк исходно открытого ядра, которое есть на GitHub. Ядро очень маленькое, занимает всего 2к лутов (для сравнения: ARM Cortex‑M3 съедает 18к). В нём мы даже прерывания не используем, поскольку его задачи — принимать команды по UART и управлять Realtime блоками, реализованными в плисовой части.

Рассмотрим только отличия.

######################### Common Cfg Settings #########################
ARCH = rv32imc_zicsr # Specify MCU arch here

В этой переменной описана архитектура используемого ядра. Их бывает много разных.

WARNING_FLAGS = -Wall -Wlogical-op
DISABLED_WARNINGS = -Wno-address-of-packed-member -Wno-unknown-pragmas -Wno-volatile
RISCV_FLAGS = -march=$(ARCH) -mabi=ilp32 -mtune=size -mcmodel=medany -msmall-data-limit=8 -mstrict-align -msave-restore

Тут — специфичные для RiscV опции.

COMMON_FLAGS =  $(RISCV_FLAGS) -fmessage-length=0 -ffunction-sections -fdata-sections -fno-builtin -ffreestanding $(WARNING_FLAGS)

Здесь вместо типа ядра ARM теперь расположены опции RiscV. Остальное не изменилось.

Вот как выглядят настройки конфигурации Release:

####### Release Cfg Settings #######
ifeq "$(GOAL_NAME)" "Release"
COMMON_FLAGS += -Os
LINKER_FLAGS += 
LD_SCRIPT = sections.lds

Я тут хочу особо отметить отсутствие опции -flto — оптимизации на уровне линкера. При её включении объём кода уменьшается примерно на 6%, но после прошивки ядро не стартует. Почему — я пока не разбирался, нужно почитать выходной ассемблер.

А вот настройки Toolchain:

######################### Toolchain ######################### 
CPP_CMP = riscv-none-elf-g++
C_CMP = riscv-none-elf-gcc
OBJCPY = riscv-none-elf-objcopy
SZ = riscv-none-elf-size
GW_FLASHER = C:/YaStudio/GowinProgrammer/bin/programmer_cli.exe

Помимо изменения имён компиляторов, появился ещё файл прошивальщика от GOWIN. И вот как выглядит команда прошивки:

######################### Flash it #########################
flash:
	@$(GW_FLASHER) -d GW2A-18C -r 38 --spiaddr 0x400000 --mcuFile "$(CURDIR)/$(OUT_DIR)/$(PRJ_NAME).bin"

Тут велено запустить programmer_cli.exe с указанием типа ПЛИС, приказом № 38 — прошить внешнюю SPI FLASH с использованием GAO Bridge, с адреса 0×400 000, ну и дальше полный путь к.bin‑файлу.

На этом закончим наконец с makefile и пойдём дальше.

Папка .vscode

Её я тоже таскаю из проекта в проект, чтобы настройки вместе с проектом лежали в репозитории. Посмотрим на некоторые.

settings.json

В начале расположены настройки пути PATH к исполняемым файлам компиляторов и прочему. Я не люблю настраивать глобальный PATH в Windows, к тому же для компиляторов он будет другим в случае RiscV. Что лучше — локальные настройки или глобальные — не хочу спорить, принципиальной разницы нет, мне удобнее так.

Здесь и в следующих разделах — про json‑файлы.

"C_Cpp.default.intelliSenseMode": "gcc-arm",

Это настройки подсветки С++ кода.

Далее настройки для плагина cortex-debug: пути и названия.

"cortex-debug.gdbPath": "C:/YaStudio/arm-none-eabi-gcc/bin/arm-none-eabi-gdb.exe",
"cortex-debug.armToolchainPath": "C:/YaStudio/arm-none-eabi-gcc/bin",
"cortex-debug.armToolchainPrefix": "arm-none-eabi",
"cortex-debug.openocdPath": "C:/YaStudio/OpenOCD/bin/openocd.exe",

А в следующей опции указывается, в каком формате показывать значения переменных при отладке: десятеричном или шестнадцатеричном. Подробнее про это будет в главе «Отладка».

"cortex-debug.variableUseNaturalFormat": true, // False is hex, true is decimal
"terminal.integrated.env.windows": {
        "PATH": "C:/YaStudio/arm-none-eabi-gcc/bin; C:/YaStudio/build-tools; C:/YaStudio/OpenOCD; C:/YaStudio/OpenOCD/bin"
    },

А тут указан PATH терминала VScode: он используется при запуске тасков. В частности, для запуска make и OpenOCD.

Далее расположены настройки плагина подсветки TODO Highlight, они почти без изменений из примера к плагину.

Для RiscV есть очевидные изменения:

"cortex-debug.armToolchainPath": "C:/YaStudio/riscv-none-elf-gcc/bin",
"cortex-debug.armToolchainPrefix": "riscv-none-elf",
"terminal.integrated.env.windows": {
	"PATH": "C:/YaStudio/riscv-none-elf-gcc/bin;C:/YaStudio/build-tools"
},

tasks.json

Тут расположен список тасков. У меня их по три для каждой конфигурации — Build, Clean и Flash.

{
    "version": "2.0.0",
    "tasks": [
        // ==== Release ====
        {
            "label": "Build Release",

Как этот таск будет называться. Любая строка. 

            "type": "shell",

Тип таска — запуск из командной строки.

            "command": "make",

Что запускать, собственно. Путь, в смысле PATH, прописан в settings.json.

            "args": [
                "build_Release"
            ],

С какими аргументами вызывать make. В данном случае будет вызвано make build_Release.

            "group": {
                "kind": "build",
                "isDefault": true
            },

Тут указано, что этот таск нужно поместить в группу Build. Это позволяет нажать Ctrl + Shift + B и выбрать таск из выпадающего списка:

Это удобно, когда пишешь код и не хочешь тянуться за мышью.

"presentation": { 
                "clear": true,
                "showReuseMessage": false
            }

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

Следующие таски отличаются только названием и аргументами вызова:

            "label": "Clean Release",
...
            "args": [
                "clean_Release"
            ],
...
            "label": "Flash Release",
...
            "args": [
                "flash_Release"
            ],

Можно залить прошивку и при помощи OpenOCD, без make.

            "label": "Flash Release w OpenOCD",
            "type": "shell",
            "command": "openocd",

Тут всё очевидно, из интересного только аргументы дальше:

"args": [
"-f interface/stlink.cfg", // Configuration file name
  // Command
   "-c "program ${workspaceRoot}/Release/Locket.hex verify reset exit""

Тут указано использовать файл конфигурации stlink.cfg, поскольку прошивать будем через STLink. Далее указан путь к .hex‑файлу и команды: прошить, проверить, отрезетить, выйти.

c_cpp_properties.json

Тут расположены настройки плагина C/C++ и, что важно, IntelliSense — то есть подсветки.

{
    "configurations": [
        {
            "name": "Win32",
            "includePath": [
                "${workspaceFolder}/**"
            ],
            "defines": [
                "-D_GNU_SOURCE"
            ],
            "windowsSdkVersion": "10.0.22621.0",
            "cStandard": "gnu17",
            "cppStandard": "gnu++20",
            "compilerPath": "C:/YaStudio/arm-none-eabi-gcc/bin/arm-none-eabi-g++.exe"
        }
    ],
    "version": 4
}

Всё довольно очевидно: где лежат подключаемые файлы, какие версии С и C++, а также путь к компилятору. Версии С / С++ нужно указать такие же, как в makefile — тогда у IntelliSense мнение об ошибках будет совпадать с мнением компилятора.

launch.json

Тут лежат настройки для отладки. Может быть несколько конфигураций этих настроек, например, для разных программаторов. Рассмотрим для примера настройку для DAPlink.

{
    "version": "0.2.0",
    "configurations": [
        {
            "name": "Debug with OpenOCD DAPLink",

Название — любая строка, для отображения в выпадающем списке:

"type": "cortex-debug",

Какой плагин использовать.

"cwd": "${workspaceRoot}",

В какой папке работать — в корневой папке проекта.

"device": "GD32F4xx", // The name of the MCU, which matches the <name> tag at the top of the svd file.

Эта опция нужна для отображения состояния регистров при наличии .svd‑файла. В процессе отладки это выглядит вот как:

"executable": "./Debug/Prj.elf",

Это путь к файлу .elf. Я потому и использую везде Prj вместо индивидуального названия проекта, чтобы не менять название ещё и в launch.json.

"runToEntryPoint" : "main",

При старте прошивки, до начала выполнения функции main, происходит ещё немало всего: записываются нужные числа в указатели стека, настраивается таблица векторов прерываний, инициализируется FPU, обнуляются глобальные переменные, запускаются конструкторы. Но это всё, как правило, неинтересно и неизменно, а интересное начинается с функции main. В этой опции и указано выполнить всё до main и остановиться в её начале.

Есть подход, при котором инициализация всякой периферии выполняется до main, в рамках функции, например, EarlyInit(). Но я такое не одобряю, потому что при инициализации часты всякие неприятности, и тогда придётся вспомнить, что перед main() есть ещё EarlyInit(). Вопрос вкуса, впрочем.

"showDevDebugOutput": "none",

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

"svdFile": "${workspaceRoot}/GD32F4xx.svd",

Путь к .svd-файлу. Эти файлы добываются из утилит ST для STM32, а для GD — из блоков расширения для Keil. 

"armToolchainPath": "C:/YaStudio/arm-none-eabi-gcc/bin/",

Путь к компиляторам и gdb.

Далее настройки сервера: прокладки между gdb и аппаратным программатором. В данном случае это OpenOCD.

// Server
"servertype": "openocd",
"configFiles": [ 
    "interface/cmsis-dap.cfg", 
    "target/stm32f4x.cfg" 
],

Тут указано, какой программатор используется и какой проц. 

"interface": "swd"

По какому интерфейсу подключаемся.

// "preLaunchTask": "Build Debug",

Тут можно указать, какой таск выполнить перед началом отладки. Я закомментировал, потому что мне удобнее перед запуском отладки вручную запустить сборку Debug‑конфигурации. Но можно было бы собирать автоматически.

// "preLaunchCommands": [ "set output-radix 16" ],

А это команда, указывающая, в каком формате показывать значения переменных: двоичном, десятеричном (по умолчанию), шестнадцатеричном. Про это поговорим позже.

Вот, собственно, и всё.

Давайте посмотрим на другие варианты «сервер + программатор». Для нативного STLink достаточно двух строк:

"servertype": "stlink",
"interface": "swd"

Минус, как я уже говорил, в том, что STLink работает только с МК STM32. Если подсунуть GD32F405 под видом STM32F405 — это будет обнаружено и пресечено.

Для связки STLink + OpenOCD:

"servertype": "openocd",
"configFiles": [ 
	"interface/stlink.cfg", 
	"target/gd32f4xx.cfg"
],
"interface": "swd"

Нужно указать файлы конфигурации — для программатора и микроконтроллера. Так можно отлаживать GD32 при помощи STLink. Авторы OpenOCD молодцы!

Для Black Magic Probe:

"servertype": "bmp",
"BMPGDBSerialPort": "COM5",
"interface": "swd",
"preRestartCommands" : [ "load", "enable breakpoint", "monitor reset" ]

Нужно указать COM-порт, к которому подключён отладчик, и команды: прошить прошивку, разрешить breakpoints, отрезетить МК.

Отладка

Отладка с выбранной конфигурацией запускается кнопкой Launch.

У отладки в VScode есть недостаток по сравнению с Eclipse: все переменные показываются в десятеричном виде (кроме указателей — там только шестнадцатеричный, и это норм). Это неудобно — в Eclipse можно посмотреть значение любой переменной в любом виде: и двоичном, и десятеричном, и шестнадцатеричном.

Как же быть? Нам, эмбеддерам, нужно одно в hex, другое в dec, третье в bin.

Есть такие пути.

А. Завести переменную в окошке watch и через запятую указать формат. Минус в том, что для большого количества переменных это утомительно.

Б. В настройках запуска указать «показывать все переменные в нужном формате». Есть два варианта, где это можно сделать:

• settings.json: опция "cortex-debug.variableUseNaturalFormat",

• launch.json: задать "preLaunchCommands": [ "set output-radix 16" ].

Минус в том, что тогда все переменные будут в этом формате. Но если нам нужно кучу всего смотреть в hex, а некоторые в dec — то последние можно завести в окне watch.

В. Менять отображение всех переменных при помощи специальной кнопки:

Кнопка появляется только при наведении мыши на строку Watch. И тогда всё переменится:

Минус и его решение такие же, как в пункте Б, но теперь у нас есть интерактив.

Г. А ещё есть сочетание клавиш Ctrl + Shift + X! Эффект тот же.

Мелочи, приятности и неприятности

В этом разделе я расскажу про настройки редактирования и перемещения, с которыми мне стало удобно.

Допустим, у меня в коде есть словечко MySuperMegaClass. Я хочу по нему быстро перемещаться, зажав Ctrl и нажимая стрелочки. Я ожидал, что прыжки будут между частями слова:

Но в VScode курсор прыгает на всё слово целиком.

Это можно исправить в настройках. Заходим туда (Ctrl + K или Ctrl + S), вводим в строку поиска cursorWord. По умолчанию есть команды cursorWordLeft (Ctrl + LeftArrow) и cursorWordRight (Ctrl + RightArrow). Чтобы курсор прыгал по частям слова, находим команды cursorWordPartLeft и cursorWordPartRight и назначаем им Ctrl + LeftArrow и Ctrl + RightArrow соответственно. Эти сочетания клавиш, естественно, пропадают из cursorWordLeft и cursorWordRight. После этого курсор прыгает ожидаемо.

Но не всё так просто. Есть SourceCraft Code Assistant (IntelliBoba) — наш ИИ‑ассистент, и его настройки по умолчанию оказались неудобны. Например, он предлагает кусок кода. Я могу нажать Tab и принять его целиком. Но если я хочу не целый кусок, а его часть?

Исходно можно было нажимать Ctrl + RightArrow и принимать слово за словом:

Но после смены этого сочетания с cursorWordRight на cursorWordPartRight оно перестало работать. Пришлось назначить другое сочетание. Нужная команда — Accept Next Word Of Inline Suggestion. Я выбрал сочетание Alt + Shift + RightArrow.

Ещё одно сочетание — Ctrl + Пробел — это запрос предложения кода от ассистента. Но это же сочетание должно вызывать предложение от IntelliSense. Тут побеждает ассистент, и это нехорошо: IntelliSense мне нужен часто, для всяких мелочей вроде полей структуры. Поэтому я назначил Ctrl + Пробел команде Trigger Suggest, а Ctrl + Enter — команде Yandex Code Assistant Suggest.

Файл .svd и регистры с битовыми полями

Помимо применения во время отладки, которое я описал выше, есть ещё одно. 

Инструментарий ST содержит файл с описаниями номеров прерываний, регистров и битовых полей. Для иллюстративности давайте поговорим про I2C. Например, stm32l151xb.h содержит нижеследующую структуру (язык C):

typedef struct
{
  __IO uint32_t CR1; 
  __IO uint32_t CR2;
  __IO uint32_t OAR1;
  __IO uint32_t OAR2; 
  __IO uint32_t DR; 
  __IO uint32_t SR1; 
  __IO uint32_t SR2; 
  __IO uint32_t CCR; 
  __IO uint32_t TRISE;
} I2C_TypeDef;

Ниже есть адреса I2C1 и I2C2:

#define I2C1_BASE             (APB1PERIPH_BASE + 0x00005400U)
#define I2C2_BASE             (APB1PERIPH_BASE + 0x00005800U)

И далее — маппинг структур на эти адреса:

#define I2C1                ((I2C_TypeDef *) I2C1_BASE)
#define I2C2                ((I2C_TypeDef *) I2C2_BASE)

Ещё дальше есть макросы битовых полей регистров, например:

#define I2C_CR1_PE_Pos                      (0U)                               
#define I2C_CR1_PE_Msk                      (0x1U << I2C_CR1_PE_Pos) 
#define I2C_CR1_PE                          I2C_CR1_PE_Msk 

Этот набор — структуры, их маппинг и битовые поля — позволяет довольно удобно писать «свой HAL на регистрах». Для установки в единицу бита PE в регистре CR1 блока I2C2 мы напишем следующее:

I2C2->CR1 |= I2C_CR1_PE;

Но не таковы GigaDevice. Их инструментарий не содержит структур: I2C0 или I2C1 — это просто число, базовый адрес соответствующего блока I2C. Регистры — тоже числа: это абсолютные адреса регистров. Есть дефайны битов. Для работы с этим можно либо использовать функции HAL, либо писать хотя и похоже, но непривычно:

I2C_CTL0(I2C1) |= I2C_CTL0_I2CEN;

Мне так неудобно. Переучиваться лень. Но писать руками файл периферии — ещё больше лень (я как‑то писал, не понравилось). Что же делать?

Так вот, есть утилита SVDConv.exe, которая принимает на вход.svd‑файл и генерирует.h‑файл со структурами и битовыми полями. Можно указать вид этих битовых полей: просто макросы, как у ST, или enum, или в виде битовых структур. В последнем случае это выглядит так:

union {
    __IOM uint32_t CTL1;
    
    struct {
      __IOM uint32_t I2CCLK     : 6;
            uint32_t            : 2;
      __IOM uint32_t ERRIE      : 1;
      __IOM uint32_t EVIE       : 1;
      __IOM uint32_t BUFIE      : 1;
      __IOM uint32_t DMAON      : 1;
      __IOM uint32_t DMALST     : 1;
            uint32_t            : 19;
    } CTL1_b;
} ;

Тут __IOM — это макрос для volatile. 

Тогда для записи числа clk_MHz в поле I2CCLK можно написать в «стиле ST»:

I2C1->CTL1 = (I2C1->CTL1 & ~I2C_CTL1_I2CCLK) | clk_MHz;

Тут велено прочитать текущее значение регистра, очистить младшие 6 бит, выполнить побитовое ИЛИ с числом clk_MHz. Оно тут в младших битах, поэтому смещение не требуется.

А можно проще и нагляднее:

I2C1->CTL1_b.I2CCLK = clk_MHz;

Я не поленился посмотреть ассемблер и сравнить код в обоих случаях. Оказывается, второй вариант ещё и эффективнее: три инструкции против четырёх. Потому что в первом случае, как и написано, сначала делается побитовое И, а потом побитовое ИЛИ; а во втором — используется специальная инструкция установки битового значения со смещением.

---

SourceCraft Code Assistant — это мощный инструмент, который позволяет избавиться от рутинной работы и сильно ускоряет написание кода. Тот самый лозунг IBM «Машина должна работать, человек — думать» обрёл новое значение. Моя задача — отсеять плохие варианты и принять хорошие, а если машина не справляется со спецификой — написать самому. И наконец не нужно набивать длинные скучные строки, которые необходимы, но суть их очевидна.

Говорят, по мере роста профессионализма программиста он всё меньше печатает и всё больше думает. И ИИ помогает мне расти ещё быстрее. Так что теперь VScode в паре с ИИ‑ассистентом — мой рабочий тандем для написания кода. И мне удобно — удобнее, чем было в Eclipse.