Когда пишут программу HelloWorld на C, обычно выводят текст “Hello, World!”. Но когда программа пишется для микроконтроллера, часто ограничиваются миганием светодиода, особенно для микроконтроллеров семейства STM32.

В статье я разберу, как можно вывести “Hello World” в программе для микроконтроллеров этого семейства.

Для микроконтроллера RP2040 вывести “Hello world” проще, чем для микроконтроллеров STM32, пишешь printf("Hello, world!\n"); и в CMakefiles.txt указываешь использовать USB или UART для вывода. Для STM32 ситуация другая — нужно больше действий от программиста.

Вывод отладочной информации не доступен «из коробки» и может потребовать дополнительной настройки: выбора UART, подключения USB-UART преобразователя или использования отладочного интерфейса ST-LINK/J-Link

Я использовал отладочную плату WeAct Studio на базе микроконтроллера STM32H750VBT6. Плата не имеет встроенного аппаратного отладчика ST-Link и не предоставляет виртуальный COM-порт для отладки, у отладочных плат Discovery и NUCLEO, поэтому я использовал китайские клоны отладчиков ST-Link и J-Link.

Разрабатывая простую программу “Hello world” на микроконтроллере STM32, можно узнать много нового, систематизировать и улучшить свои знания.

Примеры, приведённые в статье, доступны в моём GitHub репозитории

Начнём с краткой теории.

После RP2040 разработка для STM32 кажется гораздо сложнее.

Если у RP2040 это один чип, то STM32 объединяет множество чипов от простых Cortex-M0 (серия F0/G0) до Cortex-M7 (серия H7) с частотами под 480 МГц, DSP и аппаратным ускорением графики. Под каждую задачу подбирают свой чип STM32.

Разработка для STM32 может вестись на трёх уровнях: CMSIS, LL и HAL.

• CMSIS — прямой доступ к регистрам. Максимальная скорость и минимальный размер кода, но нужно наизусть знать тысячестраничный Reference Manual.

• LL (Low-Layer) — лёгкая обёртка из inline-функций над регистрами. Быстро и прозрачно, но привязано к конкретному чипу.

• HAL (Hardware Abstraction Layer) — тяжёлый высокоуровневый API. Позволяет легко переносить код между разными STM32, но расплачиваться приходится раздутым размером прошивки и медлительностью.

Перед началом работы с микроконтроллером в программном коде его необходимо сконфигурировать: настроить периферию и тактовые частоты для неё.

Главный шок после RP2040 — это дерево тактирования (Clock Tree). На RP2040 частоты настраиваются парой строчек. В STM32 нужно вручную связать цепочку из кварцев (HSI/HSE), множителей PLL и делителей Bus Prescalers. Поэтому обычно конфигурацию выполняют при помощи STM32CubeMX с последующей генерацией кода под разные IDE или системы сборки.

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

Для меня это выглядит неуклюже, так как код содержит визуальный мусор, который отвлекает. Но видимо, от Legacy здесь не откажешься.

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

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

Естественно, что нужен сам микроконтроллер, вернее, нужна отладочная плата с микроконтроллером.

Как я говорил ранее, я использовал плату WeAct Studio. Вы можете использовать её или какую-нибудь другую плату на базе STM32, например, так называемые Blue Pill и Black Pill.

Моя отладочная плата на базе STM32H750VBT6

Как и для любых других микроконтроллеров, кроме самого микроконтроллера, для разработки под STM32 необходимы:

1. Кросс-тулчейн.

2. Система сборки.

3. Интегрированная среда разработки.

4. SDK и библиотеки.

5. Программатор.

6. Аппаратный отладчик.

7. USB-UART преобразователь.

8. Сервер отладки.

Можно обойтись и частью из этого списка. Если вы хорошо владеете командной строкой и понимаете, как работают компилятор, компоновщик, система сборки — интегрированная среда разработки будет опциональна. Если для отладки достаточно вывода текстовых логов по UART, аппаратный отладчик будет лишним.

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

Процесс получения прошивки для микроконтроллера

Типовая архитектура подключения инструментов разработки к микроконтроллеру (MCU) для прошивки, отладки и мониторинга данных

Они будут справедливы для многих микроконтроллеров (MCU) и STM32 тоже.

Тулчейн (toolchain) — это набор программных инструментов, используемых для создания исполняемого файла из исходного кода для конкретной программно-аппаратной платформы.

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

Кросс-тулчейн (Cross Toolchain) отличается от тулчейна тем, что с помощью него собирают бинарный код, предназначенный для другой платформы, отличной от той, на которой разрабатывают.

В отличие от тулчейна (который просто транслирует код), система сборки (например, Make, CMake, Ninja, MSBuild) автоматизирует весь процесс.

Вы описываете конечную цель (target), исходные файлы и зависимости, а система сама решает, в каком порядке и с какими параметрами вызывать компилятор и компоновщик.

Система сборки (Build System) управляет процессом через три ключевых понятия:

• Цели (Targets): Что именно нужно получить. Это может быть исполняемый файл, статическая/динамическая библиотека или даже промежуточный этап (например, генерация документации).

• Зависимости (Dependencies): Файлы или другие цели, которые необходимы для создания текущей цели. Например, чтобы собрать исполняемый файл app, сначала нужно скомпилировать файлы main.o и utils.o, а для них, в свою очередь, нужны исходники main.c, utils.c и заголовочные файлы .h.

• Артефакты: Результаты сборки (объектные файлы, библиотеки и сам итоговый исполняемый файл).

Для разработки и отладки STM32 существует несколько сред разработки (IDE).

• STM32CubeIDE: Официальная бесплатная среда от компании STMicroelectronics, основанная на Eclipse и GCC. STM32CubeIDE: считается базовым и самым надёжным выбором для старта.

STM32CubeIDE

• VS Code (Visual Studio Code) с плагинами: Универсальный текстовый редактор, который превращается в мощную IDE с помощью расширений (например, PlatformIO или официального расширения STM32 VS Code Extension). Часто используется в связке с CMake и отдельно запущенным CubeMX для генерации кода.

VS Code

• CLion: Платная профессиональная IDE от JetBrains с поддержкой Embedded-разработки. Доступна бесплатная лицензия для образовательных целей или 30-дневный пробный период.

CLion

Существуют ещё платные профессиональные среды IAR Embedded Workbench и Keil MDK, но для “Hello World" подойдут и первые три.

В процессе подготовки статьи я обнаружил, что каждая из сред имеет свои особенности. При использовании клонов J-Link v9 и ST-Link не всегда удобно или возможно вывести отладочное сообщение в той или иной среде.

Замечание о кроссплатформенности: Изначально экосистема STM32 была жёстко привязана к Windows, но сегодня разработка на Linux и macOS стала полноценным стандартом. Вся разработка в рамках этой статьи выполнялась под Linux.

Чтобы не работать с регистрами микроконтроллера напрямую «по адресам в памяти», используются готовые библиотеки от производителя или сообщества:

• CMSIS (Cortex Microcontroller Software Interface Standard): Абстракция ядра от ARM.

• HAL / LL от STMicroelectronics: Официальные библиотеки. HAL предоставляет высокоуровневый API, а LL (Low-Layer) — быстрые inline-обёртки над регистрами.

• LibOpenCM3: Альтернатива официальному SDK с чистым и лаконичным API.

Часто аппаратный отладчик (Debug Probe) совмещён с программатором (Programmer).

Так как мы выводим “Hello World” на микроконтроллере STM32, рассмотрим программаторы ST-Link первыми. Если вы используете отладочную плату STM32 NUCLEO или STM32 DISCOVERY, то программатор ST-Link уже распаян на ней.

Также существуют отдельные устройства: как оригинальные от STMicroelectronics, так и их китайские клоны. Главное отличие большинства дешёвых клонов — отсутствие поддержки вывода SWO (Serial Wire Output), что ограничивает возможности быстрой отладки и трассировки.

Китайский клон ST-Link V2

J-Link — аппаратный отладчик от компании SEGGER, совместно с ПО для компьютера поддерживает множество различных микроконтроллеров и отладочных плат.

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

Китайский клон J-Link V9

DAP-Link — это референсная имплементация CMSIS-DAP с открытым программным кодом от ARM для аппаратных отладчиков.

Pico Debug Probe является примером ещё одной реализации CMSIS-DAP.

Так как у Pico Debug Probe используется RP2040, который не содержит модуля ITM, использование SWO невозможно.

Многие IDE для STM32 не содержат встроенной поддержки СMSIS-DAP, но если установить сервер отладки OpenOCD, то теоретически можно прошить и отладить код для STM32.

ST-Link и J-link это и физические устройства, и прошивка микроконтроллера. Имея прошивку, можно плату с микроконтроллером превратить в аппаратный отладчик и программатор.

Прошивки, поддерживающие стандарт CMSIS-DAP, также можно установить на микроконтроллеры и отладочные платы и получить из них программатор и аппаратный отладчик. Так, например, получается Pico Debug Probe из Raspberry Pi Pico.

USB-UART преобразователь

USB-UART преобразователь, наверное, самое простое и привычное устройство для получения диагностических сообщений от микроконтроллера. Если вы когда-нибудь разбирали роутер или телевизионную приставку, то видели нераспаянный 4 пиновый разъём на плате (TX, RX, GND, Vcc). Это и есть разъём для подключения преобразователя.

Пины TX и RX платы и преобразователя подключаются перекрёстно. TX платы с RX преобразователя, RX платы с TX преобразователя.

Для просмотра того, что выводит микроконтроллер на печать на компьютере, должен быть запущен эмулятор терминала, который подключён к виртуальному COM-порту (VCP), создаваемому драйвером USB-UART преобразователя.

Времена, когда нужно было искать и устанавливать драйвер в операционной системе вручную прошли. Но если у вас преобразователь на базе CH340 и операционная система Windows, вечер, потраченный на понимание, как же всё-таки загружаются драйвера в Windows, вам гарантирован.

Для просмотра сообщений, приходящих по UART, под Windows я обычно использую Putty, в Linux — picocom. Вам нужно знать параметры UART-протокола, который использует устройство (скорость передачи, используется ли проверка бита чётности (parity), количество стоп-бит). Если вы укажете их неправильно при старте эмулятора терминала, вы увидите мусор или вообще ничего.

Обычно используются три пина из четырёх: TX, RX и GND, а пин питание не используется, так как питание подаётся на устройство обычным образом.

Также нужно быть внимательным к используемым уровням логики. Может быть 1.8 В, 3.3 В, 5 В. Чтобы ничего не сжечь, они должны быть одинаковые. Узнать, какие уровни использует устройство можно, замерив напряжение на пине ТХ.

Обычно производители оставляют поддержку вывода диагностики по UART даже в потребительских устройствах.

UART можно успешно использовать для вывода “Hello, World”, но существуют другие способы, позволяющие это сделать.

Для взаимодействия микроконтроллера с аппаратным отладчиком или программатором используется несколько аппаратных интерфейсов:

• JTAG,

• SWD,

• UART.

Последний интерфейс не обязательно используется для подключения к аппаратному отладчику. Микроконтроллер можно подключить к компьютеру через USB-UART преобразователь.

• JTAG — классический многопроводный интерфейс (TDI, TDO, TMS, TCK).

• SWD (Serial Wire Debug) — двухпроводная альтернатива от ARM (SWDIO, SWCLK).

• UART (Universal Asynchronous Receiver-Transmitter) — текстовая связь (TX, RX).

Sеmihosting — самый медленный метод вывода отладочных сообщений, так как при выводе строки или символа процессор микроконтроллера прерывает свою работу и ожидает обработки компьютером.

Текстовая отладочная информация выводится в консоль отладчика, также информацию можно посмотреть, подключившись к telnet-серверу, который создаёт сервер отладки.

У меня упорно не хотел работать semihosting при использовании сервера отладки J-Link совместно с аппаратным отладчиком J-Link. При использовании сервера отладки STLink и аппаратного отладчика STLink всё работало как положено. Мне удалось добиться работы semihosting с аппаратным отладчиком JLink, используя сервер отладки OpenOCD.

На микроконтроллерах с ядрами Сortex M3 и старше доступен метод вывода отладочных сообщений через отдельный пин SWO. В архитектуру встроен специальный модуль трассировки ITM (Instrumentation Trace Macrocell), который позволяет выводить отладочные сообщения через один выделенный пин SWO (Serial Wire Output). На более младших ядрах вроде Cortex-M0 и Cortex-M0+ этот функционал отсутствует. Для включения ITM нужно правильно сконфигурировать микроконтроллер. Также нужно правильно настроить частоту для SWV.

SWO поддерживается аппаратными отладчиками ST-Link и J-Link. Но китайские клоны ST-Link могут не содержать пина SWO. У меня именно такой.

На пин SWO информация выводится с использованием асинхронного протокола. SWO очень напоминает работу пина TX в UART. Когда SWO корректно сконфигурирован и находится в состоянии IDLE, на пине логическая единица.

На пин SWO может выводиться не только текстовые отладочные сообщения, но и другая отладочная информация.

Если у вас аппаратный отладчик J-Link можно воспользоваться фирменной технологией от SEGGER, которая называется RTT (Real Time Transfer).

UART — самый привычный способ вывода отладочной информации. Большинство устройств оставляют пины UART (TX, RX, GND, VCC) куда выводится отладочная информация при загрузке устройства.

Хотя многие аппаратные отладчики содержат пины TX и RX и создают виртуальный COM-порт для взаимодействия с устройством по UART, просмотреть отладочную информацию можно и без аппаратного отладчика. Достаточно подключить UART-USB адаптер.

При использовании UART в STM32, его необходимо настроить в CubeMX.

1. Запускаем STM32CubeMX.

2. Выбираем свою модель микроконтроллера или отладочной платы:

   

   Выбор модели микроконтроллера

3. Создаём проект в STM32CubeMX, нажав Start Project.

4. Выполняем конфигурирование UART-интерфейса. Обратите внимание, какие значения у Basic Parameters, и какие пины используются для выбраного UART-интерфейса. Это понадобится позже для подключения UART-адаптера.

   

   Конфигурирование UART-интерфейса

5. Заходим на вкладку Clock Configuration и соглашаемся на автоматическое конфигурирование.

   

6. На вкладке Project Mananager заполняем поля Project Name и Project Location. Выбираем значение CMake в поле Toolchain/IDE.

   

7. На вкладке Code Generator ставим флажок Generate peripheral initialization as pair of '.c/.h' files per peripheral.

   

8. Нажимаем кнопку GENERATE CODE.

9. Запускаем STM32CubeIDE и создаём новый Workspace.

10. Импортируем проект в STM32CuberIDE:

    

11. Выбираем свою модель микроконтроллера:

    

12. Собираем проект.

13. Создаём конфигурацию для отладки.

14. STM32CubeMX сгенерировал большинство кода за нас. Нам нужно подключить заголовочный файл stdio.h в файле main.c

    /* Private includes ----------------------------------------------------------*/
    /* USER CODE BEGIN Includes */
    #include <stdio.h>
    /* USER CODE END Includes */
    

15. Определяем функцию _write:

    /* Private user code ---------------------------------------------------------*/
    /* USER CODE BEGIN 0 */
    int _write(int file, char *ptr, int len)
    {
        HAL_UART_Transmit(&huart3, (uint8_t *)ptr, len, HAL_MAX_DELAY);
        return len;
    }
    /* USER CODE END 0 */
    

16. Вызываем функцию printf():

    /* USER CODE BEGIN WHILE */
    while (1)
    {
    /* USER CODE END WHILE */
    
    /* USER CODE BEGIN 3 */
          printf("UART Hello world \n");
          HAL_Delay(1000);
    }
    /* USER CODE END 3 */
    

17. Перед запуском нужно подключить аппаратный отладчик и USB-UART преобразователь к микроконтроллеру и компьютеру. Я использовал J-Link, который может параллельно работать как USB-UART преобразователь.

18. Запускаем отладку. Результат можно посмотреть в эмуляторе терминала, подключённому к виртуальному COM-порту. Такой эмулятор терминала можно или создать в STM32CubeIDE или запустить командой:

    sudo picocom -b 115200 /dev/ttyACM1
    

    где ttyACM1 — имя виртуального COM-порта в Linux.

Вывод с использованием Semihosting немного сложнее, так необходимо выполнить несколько неочевидных действий.

1. Создаём и импортируем проект из STM32CubeMX, как мы делали ранее.

2. Создаём и настраиваем конфигурацию отладки, выбрав отладчик STLink.

3. Добавляем опцию для компоновщика в файл CMakeLists.txt

   target_link_options(${CMAKE_PROJECT_NAME} PRIVATE
    --specs=rdimon.specs
   )
   

4. Добавляем библиотеку rdimon в файле CMakeLists.txt

   # Add linked libraries
   target_link_libraries(${CMAKE_PROJECT_NAME}
      stm32cubemx
      # Add user defined libraries
      rdimon
   )
   

5. Чтобы проект смог собраться, нам нужно исключить из компиляции файл c заглушками syscalls.c, который сгенерировал STM32CubeMX, так как rdimon добавляет свои.

   set_source_files_properties(Core/Src/syscalls.c PROPERTIES HEADER_FILE_ONLY TRUE)
   

6. В файле main.c подключаем заголовочный файл stdio.h:

   /* Private includes ----------------------------------------------------------*/
   /* USER CODE BEGIN Includes */
   #include <stdio.h>
   /* USER CODE END Includes */
   

7. В файле main.c добавляем объявление функции initialise_monitor_handles

   /* USER CODE BEGIN PFP */
    extern void initialise_monitor_handles(void);
    /* USER CODE END PFP */
   

8. Не забываем её вызвать в начале функции main():

   int main(void)
   {
   
     /* USER CODE BEGIN 1 */
     initialise_monitor_handles();
     /* USER CODE END 1 */
   ...
   

9. Используем обычную функцию printf() для вывода с использованием semihosting.

   while (1)
   {
      /* USER CODE END WHILE */
      /* USER CODE BEGIN 3 */
      printf("Hello World from Semihosting!\n");
      HAL_Delay(1000);
   }
   

1. Создаём и импортируем проект из STM32CubeMX, как мы делали ранее.

2. Создаём и настраиваем конфигурацию отладки, выбрав отладчик J-Link.

3. В конфигурации отладки активируем SWO.

4. В файле main.c подключаем заголовочный файл stdio.h:

   /* Private includes ----------------------------------------------------------*/
   /* USER CODE BEGIN Includes */
   #include <stdio.h>
   /* USER CODE END Includes */
   

5. Определяем функцию SWO_PrintString():

   /* USER CODE BEGIN 0 */
   void SWO_PrintString(const char *str) {
     while (*str) {
     ITM_SendChar(*str++);
     }
   }
   /* USER CODE END 0 */
   

6. Для вывода сообщений вызываем функцию SWO_PrintString():

      /* USER CODE BEGIN WHILE */
      while (1)
      {
      /* USER CODE END WHILE */
   
      /* USER CODE BEGIN 3 */
         SWO_PrintString("Hello world from SWO\n");
         HAL_Delay(1000);
      }
      /* USER CODE END 3 */
   

7. Чтобы увидеть вывод, необходимо отобразить окно SWV ITM Data Console:

   

8. Запускаем отладку.

9. В SWV ITM Data Console активируем мониторинг, нажав на кнопку с красным кружочком:

   

10. Нажимаем на кнопку с изображением инструментов и активируем Stimulus port 0:

    

11. Наблюдаем вывод.

1. Создаём и импортируем проект из STM32CubeMX, как мы делали ранее.

2. Создаём и настраиваем конфигурацию отладки, выбрав отладчик J-Link.

3. В терминале клонируем библиотеку RTT:

      git clone https://github.com/SEGGERMicro/RTT.git
   

4. В директорию Core/Src копируем два файла из библиотеки RTT – SEGGER_RTT.c и SEGGER_RTT_printf.c.

5. В директорию Core/Inc копируем два файла из библиотеки RTT - SEGGER_RTT.h и SEGGER_RTT_ConfDefaults.h.

6. Директории Core/Inc создаём пустой файл SEGGER_RTT_Conf.h

   touch  SEGGER_RTT_Conf
   

7. В файле CMakeLists.txt добавляем исходные файлы RTT:

   # Add sources to executable
   target_sources(${CMAKE_PROJECT_NAME} PRIVATE
      # Add user sources here
      Core/Src/SEGGER_RTT.c
      Core/Src/SEGGER_RTT_printf.c
   )
   

8. В файле main.c подключаем заголовочный файл SEGGER_RTT.h:

   /* Private includes ----------------------------------------------------------*/
   /* USER CODE BEGIN Includes */
   #include "SEGGER_RTT.h"
   /* USER CODE END Includes */
   

9. Выводим текст:

   /* USER CODE BEGIN WHILE */
   while (1)
   {
    /* USER CODE END WHILE */
   
    /* USER CODE BEGIN 3 */
        SEGGER_RTT_printf(0, "Hello World from SEGGER!\n");
        HAL_Delay(1000);
   }
   /* USER CODE END 3 */
   

10. Запускаем отладку.

11. Запускаем из консоли JLinkRTTViewer:

    

Маркетологи не зря хлеб едят, но когда гордо заявлено о поддержке той или иной фичи, всё-таки нужно самому смотреть, что и как реализовано.

Например:

1. Мне не удалось вывести “Hello World” средствами semihosting, используя сервер отладки J-Link. Пробовал все доступные версии для моей операционной системы, похоже на то, что в ПО J-Link здесь присутствует долгоживущий баг, по крайней мере, для ОС Linux.

2. Я не обнаружил простого способа отладки с использованием semihosting для аппаратного отладчика ST-Link в CLion.

3. Я долго не мог вывести в CLion отладочное сообщение средствами SWO для аппаратного отладчика J-Link, пока не обновил ПО J-Link на компьютере на самую свежую версию.

На первый взгляд Hello World для микроконтроллера кажется совсем простой задачей. Но в случае STM32 за привычным printf() скрывается целая цепочка: микроконтроллер должен быть правильно настроен, сообщение — перенаправлено на выбранный интерфейс, а компьютер — получить и отобразить его.

В этой статье мы посмотрели на несколько способов сделать это: обычный UART, semihosting, SWO/ITM и SEGGER RTT. У каждого способа есть свои особенности, преимущества и ограничения. UART прост, понятен и не требует полноценного аппаратного отладчика. SWO позволяет получать отладочную информацию через интерфейс отладки, не занимая обычный UART. RTT предлагает удобный способ обмена данными с микроконтроллером при использовании J-Link. Semihosting прост с точки зрения программы, но сильно зависит от отладчика и при этом заметно влияет на выполнение программы.

На практике оказывается, что выбор способа вывода зависит не только от возможностей микроконтроллера, но и от используемого аппаратного отладчика, его прошивки, сервера отладки и среды разработки. Поэтому одинаковый проект может вести себя по-разному в STM32CubeIDE, VS Code или CLion и с разными ST-Link или J-Link.

Именно поэтому Hello World для STM32 — хороший учебный пример. Он позволяет не просто увидеть строку в терминале, а разобраться, что происходит между вызовом printf() и появлением символов на экране. За этим простым примером обнаруживается довольно большой пласт технологий: периферия STM32, UART, SWD, SWO, ITM, отладочные серверы и инструменты разработки.

После этого printf() уже не выглядит магией. Становится понятно, куда именно отправляется сообщение и какие компоненты обеспечивают его появление в терминале.

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

© 2026 ООО «МТ ФИНАНС»