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

Понятно, в чём дело: компилятор не знает о файле 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 и получить слепок нужной вам области памяти.

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

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

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

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

Итак, схема конструкции

Все очень примитивно. Это просто подключение кнопок и индикатора к микроконтроллеру. Есть еще компорт для прошивки. Здесь же хотел сначала добавить два светодиода, на которые я хотел вывести знак минус для отрицательных чисел и индикатор записи в регистр памяти. Но в итоге я их не стал делать, а вывел сигналы в старший разряд индикатора. Просто потому что два светодиода вживую смотрелись довольно плохо и не наглядно. Соответственно максимальное число на индикаторе будет +- 9999999. Меньше чем обычно, но достаточно. Минус – это будет привычная средняя палочка в восьмом разряде, а память – это точка там же. И буква «Е» в случае переполнения или ошибки.

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

Получилось вот так:

Кнопочка сверху – сброс микроконтроллера. Используется для заливки прошивки. Ну или просто как сброс, если хочется. Остальные кнопки имеют стандартный смысл.

С обратной стороны как обычно паутинка. На этот раз небольшая.

Бокс с батарейками приклеен на суперклей.

Прошивка и схема в хорошем качестве, если кому интересно, здесь: https://github.com/viktand/calculator

Хотя логика калькулятора кажется довольно примитивной, но на практике это оказалось неожиданно трудно. Пришлось повозиться с тем, чтобы правильно выводить на индикатор числа в процессе их ввода и после вычислений. Особенно разочаровало преобразование между long и double, приводящее к тому, что вместо, например, «4.5» калькулятор показывал «4.499999».

На этом все.