Консолехолопы

• текстовый редактор. Любой;

• утилита make;

• компилятор, способный создать исполняемый файл для МК;

• сервер gdb, способный работать по интерфейсу SWD с МК;

  • при использовании ST-LINK_gdbserver (см. ниже) понадобится консольный stm32programmer;

• клиент gdb, умеющий в инструкции процессора МК.

С редактором, думаю, более-менее ясно.

Компилятор и клиент GDB можно достать из уже установленного кубоида (если у вас его в принципе нет, можно ограничиться пакетом STM32CubeCLT (CLT означает command-line tools). Там нам понадобится найти расположение файлов arm-none-eabi-gcc и arm-none-eabi-gdb.

Собственно, arm — это архитектура процессора, для которого мы собираем программу, none-eabi означает отсутствие какой бы то ни было ОС, взяимодействующей с исполняемым файлом (всяческие RTOS в данном случае не в счёт).

Вот по серверу есть варианты. Можно использовать openOCD, st-util либо stlink-gdbserver. Я буду использовать stlink-gdbserver просто потому, что он идёт в поставке с кубиком (на самом деле у него есть ещё два преимущества: он умеет более чем в одно подключение одновременно, а главное — в отладку двухъядерных МК).

Поищем (я предполагаю, что кубик установлен в /opt/st/stm32cubeide_1.12.0, в зависимости от ОС, кончено, нужно использовать подходящие инструменты для поиска):

(Б) На самом деле, конечно, это всё можно найти и глазами, но в любом случае с непривычки будет сильное желание выкинуть эти длинные буквы подальше.Пути до (не включительно) arm-none-eabi-gdb и ST-LINK_gdbserver следует добавить к системной переменной PATH (нет, как это делается, я здесь пояснять не буду, это относится не к нашей теме, а к общей компьютерной грамотности).
(Ъ) А вот путь до arm-none-eabi-gcc нужно добавить в PATH обязательно.

(В) Для использования ST-LINK_gdbserver нам отдельно понадобится путь к программе STM32_Programmer_CLI. Примерно так:

(А) Далее, make можно использовать как системный, так и из поставки кубоида (так же, поищите make). В принципе, нет причин не использовать штатный make — если только у вас не windows. Но тут подскажу мало: вживую видел make в составе платформы msys2, по идее, должно быть достаточно make из кубика. Точно так же, добавьте её в PATH, и будет работать.

Отлично. если вы проделали это — треть работы позади.

Теперь перейдём к сборке проекта. Для этого необходимо зайти в терминале в каталог с проектом, далее в каталог Debug (посмотреть, где он лежит, можно из Cube IDE: щелчок правой кнопкой мыши → Show In → System Explorer

Теперь, узнав, где мы сидим (в моём случае это ~/STM32CubeIDE/other/test/Debug), открываем там терминал:
cd ~/STM32CubeIDE/other/test/Debug
и собираем проект (во всяком случае, те, кто не прогуливал лекцию про make):
make all

Для этого у нас должны быть установлены make (см (А) ) и переменная PATH должна указывать на каталог с arm-none-eabi-gcc (см. (Ъ)). Если make пишет что-то вроде /bin/bash: команда не найдена: arm-none-eabi-gcc), то возвращаемся к пункту (Ъ).

Если же эти два требования выполнены, то внезапно собирается. Почему?

Потому что в каталоге Debug кубик создаёт makefile, а также воссоздаёт примерную структуру каталогов проекта. В каждом из подкаталогов лежит фай subdir.mk, описывающий, как собирать данный подкаталог (в самом Debug эти инструкции вынесены в файлы с названиями objects.list, objects.mk, sources.mk). В принципе, мне по нраву такой подход. В сами файлы мы залезем чуть позже. А пока посмотрим, что получилось на выходе:

(grep -v использовал просто чтобы не выводить полотно текста).

У нас собрался файл Debug/lesson1.elf. Ура. Он модержит в себе инструкции и данные для работы программы; адреса, по которым эти инструкции и данные должны располагаться; отладочную информацию в соответствии с тем профилем сборки, который настроили в кубике — для Debug это практически весь исходный текст программы. Он нам и понадобится далее.

Теперь треть работы позади.

Подключаемся к МК.

Как уже упоминал, работать будем с ST-LINK_gdbserver; при желании можете использовать st-util, она чуть проще в запуске, а результат для нас будет тем же. Или openOCD, если он у вас уже есть.

Предполагаю, что (Б) и (В) мы уже прошли. Тогда запускаем:
ST-LINK_gdbserver -p 4242 -d -t -cp $PATH_TO_PROGRAMMER
Здесь -p 4242 — это указание порта для работы с клиентом gdb; по умолчанию ST-LINK_gdbserver использует 61234, делайте как вам удобно, я обычно пишу его явно, чтобы не забыть.
-d — использовать SWD (подозреваю, что ключ необязателен).
-t — тоже необязательный для нас, разрешает множественные подключения.
-cp $PATH_TO_PROGRAMMER — обязательно нужно указать путь к STM32_Programmer_CLI (см. (В))

Если контроллер подключён, то увидим сообщение типа Waiting for debugger connection
Это означает, что мы смогли подключиться по USB к программатору и через него к целевому контроллеру. Если не смогли — проверяем контакты (в том числе разрешение на доступ к USB, мало ли…)

Далее в отдельном терминале заходим в каталог с файлом elf и запускаем клиент отладчика. Примечание для пользователей windows: здесь следует использовать именно стандартный терминал windows, штуковины типа git bash или терминала msys2 в данном конкретном случае не дадут работать автодополнению клиента gdb.

Собственно, программа запущена. Далее изучайте команды gdb (начните с: breakpoint, info breakpoint, delete, next, step, continue, run, disconnect, target, quit, print, x, frame; несколько особняком — dump, потому что на тему неё я позже ещё напишу пару слов). Имейте в виду, что здесь работает автодополнение команд (клавишей Tab), история (клавиши «Вверх» и «Вниз»), поиск по истории (Ctrl + r), сокращения команд (например, 'c' эквивалентно continue). Также если нажать ВВОД при пустой строке ввода, будет повторена последняя команда (это не очень удобно, но увы, без пересборки gdb этого не исправить; для отдельных команд можно отменить повтор последней команды при помощи «dont-repeat».

В следущей серии помигаем светодиодиком.