🏠 Главная · Программирование микроконтроллеров · 4 курс · Лекции · Лекция 5 4 Инструментальные средства

МДК.02.02 «Программирование микроконтроллеров»
Специальность 09.02.01 «Компьютерные системы и комплексы»
Таврический колледж, 7-й семестр. Продолжительность: 2 академических часа (90 минут).

Тема по РПД: Arduino IDE, PlatformIO, STM32CubeIDE, CMSIS, HAL и LL. Структура проекта, компиляция и загрузка прошивки.

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

• 1. От программы к работающему устройству
• 2. Среда, платформа и библиотека
• 3. Arduino IDE и устройство скетча
• 4. Что Arduino делает перед компиляцией
• 5. PlatformIO: проект как набор настроек
• 6. Сборка и загрузка в PlatformIO
• 7. STM32CubeIDE и STM32CubeMX
• 8. Структура проекта STM32
• 9. CMSIS: единый язык работы с ядром
• 10. HAL и LL: выбор уровня управления
• 11. Этапы сборки: почему возникает ошибка
• 12. ELF, HEX, BIN и карта памяти
• 13. Загрузка прошивки и отладка
• 14. Типовые неисправности и их локализация
• 15. Воспроизводимый проект и выбор инструмента
• 16. Вопросы для самоконтроля
• Источники

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

Прошивкой называют встроенное программное обеспечение устройства, а также подготовленный для записи образ этого программного обеспечения. Среда разработки объединяет средства, которые помогают создать такой образ. IDE — Integrated Development Environment, интегрированная среда разработки. Обычно она содержит редактор, средства запуска сборки, сообщения об ошибках и инструменты загрузки или отладки. Компилятор при этом является отдельным инструментом, который IDE запускает с нужными параметрами.

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

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

Рисунок 1 — Общий путь от исходного кода к работающему устройству

Arduino IDE, PlatformIO и STM32CubeIDE относятся к инструментам разработки. CMSIS, HAL и LL относятся к программной поддержке микроконтроллеров. Эти названия встречаются рядом, но выполняют разные задачи.

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

PlatformIO — экосистема разработки встроенного программного обеспечения. Она включает командные инструменты PlatformIO Core и интеграцию с редакторами, в том числе Visual Studio Code. PlatformIO управляет платформами, библиотеками и параметрами проекта. Важно различать platform, board и framework: платформа определяет семейство инструментов, board описывает целевую плату, framework задаёт программную основу. Для одной платы иногда доступно несколько framework.

STM32CubeIDE предназначена для разработки и отладки проектов STM32. STM32CubeMX помогает настроить выводы, периферию и тактирование и сформировать код инициализации. CMSIS стандартизирует программную поддержку Arm, HAL предоставляет функции управления периферией STM32, LL предлагает операции ближе к регистрам.

Таблица 1 — Назначение инструментов и программных компонентов

Скетч — проект Arduino. Его основной файл имеет расширение .ino, а имя основного файла совпадает с именем папки скетча: например, BlinkDemo/BlinkDemo.ino. Проект может включать дополнительные исходные и заголовочные файлы. Функция setup() выполняется один раз после запуска, а loop() вызывается повторно. Их вызывает код ядра Arduino, поэтому отсутствие написанного пользователем main() не означает отсутствие точки входа в итоговой программе.

Интерфейс Arduino IDE содержит редактор, выбор платы, команды Verify и Upload, окно сообщений и монитор последовательного порта. Verify запускает сборку и позволяет выявить ошибки кода без записи на устройство. Upload обычно сначала выполняет сборку, затем запускает инструмент загрузки. Успешная Verify подтверждает пригодность программы к сборке с выбранными настройками, но не исправность подключения.

На рисунке 2 приведён снимок Arduino IDE 2 из документации Arduino. Внешний вид и расположение некоторых элементов зависят от версии. В работе нужно ориентироваться на назначение команд, а не только на форму значков.

Рисунок 2 — Обзор интерфейса Arduino IDE 2

Для Arduino Uno R3 выбирают пакет Arduino AVR Boards и плату Arduino Uno. Uno R4 — другая аппаратная платформа, поэтому выбирать её вместо Uno R3 нельзя. Подключённая плата должна появиться в списке портов. Если она питается, но порт отсутствует, возможен кабель только для зарядки, отсутствие драйвера USB-преобразователя или неисправность соединения.

Разобранный пример для Uno R3:

void setup() {
  pinMode(LED_BUILTIN, OUTPUT);
  Serial.begin(9600);
  Serial.println("BlinkDemo 1.0");
}

void loop() {
  digitalWrite(LED_BUILTIN, HIGH);
  delay(500);
  digitalWrite(LED_BUILTIN, LOW);
  delay(500);
}

pinMode задаёт режим вывода, digitalWrite устанавливает логический уровень. Две задержки по 500 мс дают приблизительно одну секунду полного цикла мигания. delay блокирует выполнение основного потока, поэтому такой пример подходит для проверки инструментов, но сложному устройству потребуются неблокирующие алгоритмы. Serial.begin задаёт скорость обмена. В мониторе последовательного порта выбирают 9600 бод. Стартовое сообщение может быть пропущено, если монитор открыли после запуска; на Uno R3 открытие порта часто вызывает автоматический сброс.

LED_BUILTIN связан с определением выбранной платы. Для Uno R3 встроенный светодиод подключён к D13. Нельзя переносить это число на все STM32 и ESP32: встроенный светодиод может иметь другую полярность, другой вывод или отсутствовать.

Файл .ino содержит код C++, но проходит дополнительную подготовку. Arduino объединяет файлы .ino скетча, добавляет подключение Arduino.h при необходимости и формирует прототипы функций. После этого обычный компилятор C++ обрабатывает подготовленный исходный файл. Для некоторых сложных объявлений автоматическое создание прототипов может оказаться недостаточным, и объявления нужно написать явно.

Файлы .cpp не получают все удобства предварительной обработки .ino. Поэтому при переносе примера в main.cpp обычно явно добавляют #include <Arduino.h> и соблюдают обычные правила C++: объявление функции должно быть известно до её использования. Заголовочные файлы .h содержат объявления и общие определения, а реализацию функций обычно размещают в .c или .cpp.

Библиотека тоже участвует в сборке. Её наличие в каталоге не гарантирует совместимость с целевой архитектурой. Например, библиотека, обращающаяся непосредственно к регистрам AVR, не заработает на ESP32 только потому, что обе платы поддерживают Arduino API. Предупреждение о несовместимой архитектуре следует изучать до загрузки.

В небольшом скетче часть настроек выбирают в меню. В PlatformIO основные параметры записывают в platformio.ini в корне проекта. Такой подход облегчает передачу проекта: вместе с исходным кодом другой разработчик получает описание целевой платы и программной основы. Для воспроизводимости дополнительно фиксируют фактически использованные версии платформ и библиотек.

На рисунке 3 показан пример проекта PlatformIO в Visual Studio Code из официальной документации. Файлы программы находятся в src, а результаты сборки формируются отдельно.

Рисунок 3 — Проект PlatformIO в Visual Studio Code

Таблица 2 — Основные элементы проекта PlatformIO

Пример конфигурации для Uno R3:

[env:uno]
platform = atmelavr
board = uno
framework = arduino
monitor_speed = 9600

env:uno — имя среды сборки. platform = atmelavr выбирает платформу AVR, board = uno — описание платы, framework = arduino — ядро и программные интерфейсы Arduino. monitor_speed относится к терминалу, а не к компилятору и не к скорости загрузки.

В src/main.cpp помещают разобранный ранее пример с явной строкой #include <Arduino.h>. При первой сборке PlatformIO может скачать платформу и инструменты. Это требует доступного соединения с соответствующими ресурсами. Если загрузка пакета завершилась ошибкой, причина находится в подготовке инструментов, а не обязательно в программе.

Команды выполняют в терминале PlatformIO Core из корня проекта, где находится platformio.ini. В обычном терминале команда pio доступна только при соответствующей настройке PATH. Установка расширения сама по себе не гарантирует её доступность в любом внешнем терминале.

pio run -e uno
pio run -e uno -t upload
pio device monitor -b 9600

Первая команда собирает выбранную среду без записи в плату. Вторая собирает проект и загружает результат. Третья открывает монитор последовательного порта. При нескольких подключённых устройствах задают конкретный порт параметром -p для monitor или через upload_port для загрузки. Значение порта берут из своей системы, например из списка pio device list.

Изолированная проверка сборки помогает локализовать неисправность. Если pio run завершилась успешно, а upload — нет, сначала исследуют порт, кабель, права доступа, настройки загрузки и состояние устройства. Переписывать алгоритм мигания в такой ситуации обычно бессмысленно.

Разные среды в одном platformio.ini позволяют собирать общий исходный код для разных плат. Однако это не обещание автоматической переносимости. Нужно проверить наличие светодиода, уровни напряжения, выводы и совместимость библиотек. Одна и та же строка digitalWrite может управлять разными физическими выводами.

Для STM32 существенно не только написать алгоритм, но и согласовать выводы, источники тактирования, периферию и память. STM32CubeMX показывает доступные функции выводов и помогает сформировать начальную конфигурацию. На рисунке 4 приведён снимок окна настройки выводов из опубликованного методического пособия STM32. Это пример прежнего встроенного интерфейса CubeMX в CubeIDE, а не снимок актуального размещения окон CubeIDE 2.x.

Рисунок 4 — Пример графической настройки выводов STM32 в интерфейсе CubeMX

В STM32CubeIDE 2.x STM32CubeMX используется как отдельное приложение. Последовательность работы: открыть CubeMX, выбрать точный микроконтроллер или плату, настроить проект, выбрать STM32CubeIDE как целевую инструментальную среду, сгенерировать код, затем открыть или импортировать проект в CubeIDE. В ветке 1.x конфигуратор мог открываться непосредственно внутри IDE. Поэтому старые видеоматериалы полезны для понимания настроек, но расположение команд может отличаться.

Для учебного примера можно использовать NUCLEO-F401RE со встроенным ST-LINK. Это конкретный пример, а не утверждение о составе лаборатории. При выборе другой платы проверяют её схему и документацию. ST-LINK предоставляет отладочную связь с микроконтроллером, тогда как виртуальный COM-порт служит для обмена сообщениями. Наличие COM-порта не заменяет настройку отладчика.

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

Конкретная структура зависит от генератора и выбранных компонентов. В типовом проекте CubeMX папка Core/Src содержит main.c и другие исходные файлы приложения, Core/Inc — заголовки. Drivers/CMSIS содержит поддержку ядра и устройства, Drivers/STM32...HAL_Driver — драйверы соответствующего семейства. Файл .ioc хранит конфигурацию CubeMX. Сценарий компоновки .ld задаёт области памяти и размещение секций.

Стартовый файл содержит таблицу векторов и код начального запуска. После сброса Cortex-M получает исходное значение указателя стека и адрес обработчика сброса из таблицы векторов. Стартовый код подготавливает среду C: в типичном проекте копирует начальные значения изменяемых данных из Flash в RAM, обнуляет область .bss и передаёт управление main(). Точное расположение вызова SystemInit() зависит от стартового кода.

В main() проекта HAL часто видны HAL_Init(), SystemClock_Config(), MX_GPIO_Init() и бесконечный цикл while (1). HAL_Init подготавливает базовую поддержку HAL, SystemClock_Config задаёт тактирование проекта, MX_GPIO_Init — конфигурацию портов. Код управления выходом должен выполняться после необходимой инициализации.

CubeMX может повторно генерировать часть файлов. Пользовательские фрагменты размещают в предусмотренных областях USER CODE BEGIN / END при включённом сохранении пользовательского кода, либо выносят в отдельные модули. Резервная копия и контроль версий остаются необходимыми: специальные комментарии не защищают произвольные правки в любой строке.

Связь основных файлов с начальным запуском показана на рисунке 5.

Рисунок 5 — Память программы и подготовка среды C перед main

CMSIS — Common Microcontroller Software Interface Standard, стандарт программных интерфейсов и компонентов для микроконтроллеров Arm. В этой лекции прежде всего рассматривается CMSIS-Core для Cortex-M. Он задаёт согласованные определения регистров ядра, функции доступа к NVIC и SysTick и правила поддержки устройства.

Например, NVIC_EnableIRQ(USART2_IRQn) включает разрешение соответствующего прерывания в контроллере NVIC. Эта операция сама по себе не настраивает USART, не включает его тактирование и не создаёт обработчик. Она выполняет только свою часть общей настройки.

Заголовок конкретного устройства предоставляет определения адресов и полей регистров периферии. Условная операция GPIOA->ODR обращается к регистру порта GPIOA, но существование такого определения не означает, что порт уже включён и настроен.

CMSIS-Core облегчает работу с одинаковыми механизмами ядра в разных микроконтроллерах. Периферия производителей при этом может существенно различаться. Кроме Core, семейство CMSIS включает другие компоненты, например DSP и NN, которые решают отдельные задачи обработки сигналов и вычислений. CMSIS-Core не следует отождествлять с драйверами всей периферии STM32.

HAL — Hardware Abstraction Layer, слой аппаратной абстракции. В STM32 HAL содержит функции настройки и управления периферией. Разработчик задаёт параметры через структуры и вызывает функции с понятными именами. Для некоторых периферийных устройств применяются дескрипторы handle, состояния, обработчики и обратные вызовы.

LL — Low Layer, низкоуровневые драйверы STM32. Они предоставляют операции ближе к отдельным регистрам и битовым полям. Многие LL-функции небольшие и встраиваемые. Их применение требует более подробного знания периферии и порядка её настройки. LL не является обязательной ступенью, через которую проходит каждый вызов HAL: HAL и LL обычно представляют альтернативные способы работы с периферией.

Таблица 3 — Сравнение способов управления периферией

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

На рисунке 6 HAL и LL показаны как отдельные ветви доступа к периферии. CMSIS-Core обеспечивает поддержку ядра, а заголовки устройства описывают регистры конкретного STM32.

Рисунок 6 — Приложение, HAL, LL и поддержка CMSIS

Разобранный фрагмент для STM32F401 с предварительно настроенным PA5:

/* Вариант HAL: необходим заголовок HAL выбранного семейства. */
HAL_GPIO_TogglePin(GPIOA, GPIO_PIN_5);

/* Альтернативный вариант LL: необходим stm32f4xx_ll_gpio.h. */
LL_GPIO_TogglePin(GPIOA, LL_GPIO_PIN_5);

Оба примера показывают переключение выхода и рассматриваются по отдельности. Для NUCLEO-F401RE PA5 связан со светодиодом LD2. Перед вызовом нужны включённое тактирование GPIOA и настройка PA5 как выхода. Совместное выполнение обеих строк быстро переключит вывод дважды, и видимого изменения может не быть. Смешивать HAL и LL в сложном драйвере нужно осознанно, чтобы не нарушить состояние, которое отслеживает HAL.

Сборка включает несколько стадий. Препроцессор обрабатывает #include, #define и условную компиляцию. Компилятор переводит исходный код в представление для целевого процессора, а ассемблер формирует объектные файлы. Компоновщик, или линкер, соединяет объектные файлы и библиотеки, разрешает ссылки на функции и размещает код и данные по правилам проекта.

Объектный файл .o содержит машинный код своего модуля и информацию, необходимую для объединения с другими модулями. Если один модуль вызывает функцию, реализация которой не попала в сборку, компоновщик выдаёт undefined reference. Если заголовок не найден, ошибка появляется раньше, при обработке исходного файла. Если забыта точка с запятой, компилятор сообщает о синтаксической ошибке.

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

Последовательность обработки файлов показана на рисунке 7. IDE управляет запуском инструментов и показывает их вывод, а сами преобразования выполняет инструментальная цепочка, toolchain.

Рисунок 7 — Стадии сборки и промежуточные файлы

При чтении журнала полезно начинать с первой содержательной ошибки. Итоговая строка exit status 1 сообщает о неудаче процесса, но обычно не объясняет причину. Несколько последующих ошибок могут быть следствием одной пропущенной скобки.

После компоновки часто получается ELF — Executable and Linkable Format. Он может содержать секции программы, адреса, таблицы символов и отладочную информацию. Отладчик использует эти сведения, чтобы связать машинные команды со строками исходного кода.

Intel HEX представляет данные в текстовых записях с адресной информацией. BIN содержит последовательность байтов без такой структуры адресов. Поэтому для BIN загрузчику нужно отдельно сообщить подходящий адрес записи. Файлы ELF, HEX и BIN — разные представления результата сборки. Переименование расширения не преобразует один формат в другой.

MAP-файл помогает понять размещение секций и вклад модулей в размер программы. Во Flash обычно находятся код и постоянные данные. RAM нужна для изменяемых данных, стека и при наличии динамического выделения — кучи. Начальные значения некоторых изменяемых данных одновременно занимают место в образе Flash и место в RAM после запуска.

Предположим, у условного устройства 64 КиБ Flash и 20 КиБ RAM, а сборка сообщает 28 КиБ программных данных и 5 КиБ статических данных в RAM. Это ещё не доказывает, что RAM хватает: стек, динамические объекты и некоторые буферы во время выполнения могут увеличить расход. Пример условный и не описывает конкретную плату.

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

Загрузка — перенос результата сборки в память устройства. Для Uno R3 обычный путь использует USB-последовательный преобразователь и загрузчик в микроконтроллере. Для STM32 в рассматриваемом примере используется ST-LINK через SWD — Serial Wire Debug. Для ESP32 распространена загрузка через последовательное соединение и загрузочный режим, но способ подключения зависит от конкретной платы и варианта чипа.

Один USB-разъём может обеспечивать питание, последовательный обмен, собственный USB-интерфейс микроконтроллера или связь со встроенным отладчиком. Назначение определяет схема платы. Поэтому наличие разъёма не позволяет автоматически выбрать способ загрузки.

На рисунке 8 сравниваются два конкретных пути записи: последовательная загрузка Uno R3 и отладочное подключение STM32. Они служат для объяснения маршрута данных и не являются монтажными схемами внешнего программатора.

Рисунок 8 — Последовательная загрузка и запись через отладчик

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

После записи проверяют фактическое поведение: мигает ли нужный светодиод, выводится ли версия, сохраняется ли работа после сброса. Перед изменением физического подключения отключают питание. Вопросы загрузчиков, обновления, OTA и совместимости версий подробно рассматриваются в следующей теме 5.5.

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

Таблица 4 — Примеры диагностики

Первая полезная информация — точный текст ошибки, выбранная плата и стадия отказа. Формулировка «не работает» не позволяет отличить неисправный USB-кабель от ошибки компоновки. Изменять несколько настроек одновременно нежелательно: тогда трудно понять, какая из них повлияла на результат.

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

Чтобы проект можно было продолжить на другом компьютере, сохраняют исходники, конфигурацию платы, описание зависимостей и способ сборки. Для STM32 важны .ioc, сценарий компоновки и сведения об использованном пакете поддержки. Для PlatformIO важен platformio.ini. Для Arduino полезны сведения о пакете платы, версии ядра и библиотеках.

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

Для первого опыта и демонстрации простого устройства Arduino IDE сокращает число начальных настроек. Для модульного проекта с несколькими средами удобен PlatformIO. Для изучения периферии STM32 и аппаратной отладки полезны CubeMX и CubeIDE. Выбор определяется платой, задачей и необходимыми инструментами, а не только знакомым интерфейсом.

Основной результат темы: студент различает редактор, компилятор, библиотеку и загрузчик, понимает структуру проекта и способен объяснить, на каком этапе возникла неисправность. Эти знания поддерживают практическую работу № 9 по настройке среды, созданию, сборке и загрузке тестовой программы, указанную в РПД.

1. Чем IDE отличается от компилятора и framework?
2. Почему выбор платы влияет на сборку и работу программы?
3. Кто вызывает setup() и loop() в проекте Arduino?
4. Чем отличается обработка .ino от обычного файла .cpp?
5. Для чего нужен platformio.ini и что означают platform, board, framework?
6. Чем сборка отличается от загрузки?
7. Как взаимодействуют STM32CubeMX и STM32CubeIDE 2.x?
8. Для чего нужны стартовый файл и сценарий компоновки?
9. Какие задачи решает CMSIS-Core?
10. Чем отличаются HAL и LL? Почему LL не является обязательным внутренним слоем HAL?
11. На каком этапе возникает undefined reference?
12. Чем ELF отличается от HEX и BIN?
13. Почему небольшой расход статических данных ещё не гарантирует достаточный объём RAM?
14. Чем монитор последовательного порта отличается от аппаратного отладчика?
15. Что проверить, если сборка успешна, но загрузка не выполняется?
16. Какие файлы и сведения нужны для воспроизводимой сборки?

Дата проверки интернет-материалов: 05.10.2026. Примеры и пояснения адаптированы для студентов колледжа.

1. РПД МДК.02.02, 2026.
2. Arduino: документация IDE.
3. Arduino: Sketch build process.
4. Arduino: Sketch specification.
5. PlatformIO: Quick Start.
6. PlatformIO: конфигурация проекта.
7. PlatformIO: интеграция с VS Code.
8. ST: STM32CubeIDE.
9. ST: новый порядок работы в CubeIDE 2.0.
10. Arm: CMSIS-Core.
11. ST: HAL/LL STM32F4 и совместимость компонентов.
12. Методическое пособие STM32: источник снимка прежнего интерфейса.

← Лекция 5.3. Системы тактирования, сброса и энергопотребления · Тема 5.5. Загрузчики и обновление встроенного программного обеспечения →

Оригинал материала на GitHub