Серия «Технические заметки»

И Core/inc/our_file.h:

Затем в Core/Src/main.c после строки /* USER CODE BEGIN Includes */ добавим #include "our_file.h", а в суперцикл добавим value ++;

Попробуем собрать:

Понятно, в чём дело: компилятор не знает о файле our_file.c, где идёт выделение памяти под переменную value. В GUI кубика мы в таком случае нажимаем ПКМ на нужном файле → Resource configuration → снимаем галочки «Exclude from build». Стало быть, некий аналог этих галочек есть и в генерируемых кубиком makefilах. Откроем файл Debug/Core/Src/subdir.mk. Здесь три переменных — C_SRCS, OBJS и C_DEPS. Первая содержит все исходные файлы текущего каталога, вторая — получающиеся из них объектные файлы. Добавим в них строчки с именем нашего файла и соответствующим объектником:

Признаться, мне больше нравится такой синтаксис, чем склеивание строк через бэкслеши, но если вы решите добавлять строки в сите кубика, не забывайте про пробелы перед бэкслешами. Последняя переменная (C_DEPS) нужна больше для внутренний надобностей CubeIDE, но для единнобразия можете добавить и строчку для неё (по аналогии — базовое имя файла + расширение .d). В системе сборки кубика есть небольшая нелогичность: чтобы добавить объект в сборку, должно не только присутствовать правило для его сборки в файле subdir.mk, но его ещё нужно внести в общий список объектов проекта. Откроем файл Debug/objects.list и добавим в него строку

Теперь соберём ещё раз проект (make), переключимся на терминал с отладчиком (arm-none-eabi-gdb) и нажмём Ctrl-C, чтобы приостановить выполнение прогарммы (аналогично нажатию кнопки «Pause» в интерфейсе CubeIDE). Вновь дадим команду load. Отладчик при этом определит, что файл был обновлён с последнего запуска, и загрузит новый файл в микроконтроллер. Вновь запустим и приостановим программу:

Отлично. Работает.
Маленькое пояснение: сперва я установил бряк на начало функции main. Дошёл до неё командой c(ontinue). Проверил состояние переменной value (сразу после загрузки прошивки проверять value бессмысленно: она ещё не инициализирована). Продолжил выполнение программы и тут же остановил её уже вручную, комбинацией Ctrl+c. Отладчик написал мне, где я нахожусь, за что ему спасибо, а затем я ещё раз проверил, что переменная докуда-то досчитала.

Сейчас попробуем помигать светодиодом. Для этого нам понадобится подключить в Core/Src/main.c файл stm32f4xx_hal_gpio.h. А вот подключать соответствующие исходники не понадобится, так как конкретно GPIO используется много где, и кубик пропишет его даже для пустого проекта. Останется лишь добавить в наш main.c функцию инициализации (по аналогии с тем, как это делает кубик при создании функции MX_GPIO_Init()):

И вызвать её в main(), где-нибудь во второй секции. А затем в суперцикле помигать HAL_GPIO_TogglePin(GPIOA, GPIO_PIN_10), HAL_Delay(300);

В принципе, на этом всё, осталась пара замечаний:

1) то, что gpio тянется по умолчанию, это хорошо, но давайте рассмотрим чуть иной пример. Скажем, нам нужно подключить АЦП и померить что-нибудь. Если мы хотим работать на чуть более низком уровне, скажем, CMSIS, то нам достаточно подключить заголовочный файл stm32f401xc.h (он лежит среди доступных к подключению каталогов, а именно в Drivers/CMSIS/Device/ST/STM32F4xx/Include). Если же мы, как уважающие себя люди, привыкли оперировать горячими закусками, то заметим, что в Drivers/STM32F4xx_HAL_Driver/Inc лежат далеко не все нужные нам файлы. Здесь мы можем либо скопировать недостающее из репозитория (где он расположен, можно глянуть в кубике: Window→Preferences→STM32Cube→Frimware Updater), либо указать на нужный каталог в строке сборки в файле Debug/Core/Src/subdir.mk (после ключа -I). Здесь я предполагаю первый вариант и скопировал в проект файлы, относящиеся к АЦП: *adc.h и *adc_ex.h — в Drivers/STM32F4xx_HAL_Driver/Inc, а *adc.c и *adc_ex.c — в Drivers/STM32F4xx_HAL_Driver/Src (заметьте, там будут не только файлы HAL, но и LL; впрочем, …ll….h действительно нужен). Добавил их в соответствующий subdir.mk, а также в список объектов. Также неплохо бы добавить соответстующие файлы или шаблоны в команду очистки проекты (внизу файлы Debug/Drivers/STM32F4xx_HAL_Driver/Src/subdir.mk — цель clean-Drivers-2f-STM32F4xx_HAL_Driver-2f-Src) (я добавил ./Drivers/STM32F4xx_HAL_Driver/Src/*.su ./Drivers/STM32F4xx_HAL_Driver/Src/*.o ./Drivers/STM32F4xx_HAL_Driver/Src/*.d ./Drivers/STM32F4xx_HAL_Driver/Src/*.cyclo )

Скомпилировал. Успешно. Но если сейчас попробовать вызвать любую функцию АЦП, то компилятор выдаст ошибку:

Дело в том, что о нашем намерении собрать данную часть HAL нужно уведомить не только утилиту make, но и саму библиотеку. Для этого необходимо найти в файле Core/Inc/stm32f4xx_hal_conf.h строку #define HAL_ADC_MODULE_ENABLED и раскомментировать её. Зачем это сделано, признаться, не до конца понимаю, но у богатых свои причуды.

Собственно, на этом всё. Единственное, давайте на сладкое всё же запустим АЦП и при помощи отладчика извлечём какие-никакие данные.

И проверим в работе. Не забудем собрать, а затем — загрузим обновлённую прошивку и запустим её:

Здесь я прервал программу в произвольном месте при помощи Ctrl+C, затем поставил точку останова где-то в main.Теперь посмотрим, что прочиталось в массив:

Что-то прочиталось, уже неплохо. А теперь — ради чего всё это:

Теперь мы получили в файле набор двоичных данных из массива data и можем относительно легко его разобрать, скажем, в таблицу примерно так:

Помимо двоичных данных команда dump умеет сохранять данные и в виде формата inetl hex и некоторых других.

К чему я это всё? А, на самом деле просто к тому, что команду dump очень полезно знать, даже если вы работаете в GUI STM32CubeIDE. Ведь её можно ввести во вкладке Debugger Console и получить слепок нужной вам области памяти.

Итак, мы запустили кубоид, создали в нём проект, а теперь хотим закрыть кубоид и далее работать с этим проектом. На самом деле для того, чтобы всё получилось без лишней головной боли, сперва соберите проект в кубе. У вас создастся каталог Debug (ну, я пока предполагаю, что вы ничего не трогали), а в нём — исполняемый файл, и куча промежуточных файлов. Теперь вы можете сделать Project →Clean, при этом удалится большинство промежуточнх файлов, но останутся иструкции для утилиты make, которой мы и воспользуемся.

Для этого нам понадобятся

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

• утилита 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».

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