Программирование микроконтроллеров STM32 в среде Eclipse/GCC

В этой статье рассматривается технология разработки и отладки прикладных программ для микроконтроллеров семейства STM32 с ядром Cortex-M3 в среде Eclipse/GCC. Процесс конфигурации и настройки инструментальных средств Eclipce/GCC, создания нового проекта был описан в предыдущей статье [1].

Структуру проекта и процесс его обработки в среде Eclipse/GCC мы будем далее рассматривать на примере тестирующей программы многофункционального модуля TE-STM32F103 компании «Терраэлектроника».

Модуль TE-STM32F103 реализован на микроконтроллере STM32F103RET6 компании STMicroelectronics, который в корпусе LQFP64 объединяет процессорное ядро с максимальной тактовой частотой 72 МГц, 512 Кбайт флэш-памяти программ, 64 Кбайт ОЗУ и обширный набор периферийных устройств, среди которых 12-разрядные АЦП и ЦАП. Сбалансированная структура этого микроконтроллера, который относится к линейке Performance семейства STM32, позволила реализовать модуль с быстрым вычислительным ядром, большой встроенной памятью и развитым набором блоков обработки сигналов и обмена данными.

TE-STM32F103 позиционируется компанией «Терраэлектроника» как универсальный модуль, который может, в том числе, служить учебно-демонстрационным средством для освоения 32-разрядных микроконтроллеров.

Модуль включает микроконтроллер STM32F103RET6 со схемами обвязки, слот карты microSD; разъем miniUSB и интерфейс USB 2.0 device Full-Speed; мост USB-UART, CAN-порт. Модуль сопровождается тестовой программой, исходный текст которой доступен и может быть полезен разработчикам, осваивающим архитектуру Cortex-M3. Программа проверяет работу внутреннего АЦП микроконтроллера, обращение к карте microSD, проверку интерфейсов CAN и USB.

1. Структура проекта в среде Eclipce/GCC

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

– содержание входных данных и формат их хранения;

– файловая структура проекта;

– среда разработки (IDE);

– набор инструментальных программ и сопутствующие средства;

– метод управления состоянием проекта;

– формат выходных и промежуточных данных.

В программном проекте тестирующей программы модуля TE-STM32F103 входными данными являются файлы на языке С/C++. Файловая структура представляет собой дерево директорий, в которых хранятся все данные проекта, за исключение тех, которые могут быть использованы разными проектами, например внешние библиотеки. Среда разработки — Eclipse, позволяющая изменять состояние проекта посредством редактирования исходных текстов и выдачи команд на управление проектом. В качестве инструментальных программ используются компилятор GCC, отладчик GDB, JTAG-интерфейс OpenOCD. Для управления проектом используется утилита GСС make с деревом сопутствующих скриптов (make-файлов). Выходной код помещается в файл формата .elf, который с помощью OpenOCD можно записать во флэш-память микроконтроллера.

Утилита make позволяет автоматизировать процесс преобразованию файлов при помощи инструментальных средств. Чаще всего это компиляция исходного кода в объектные файлы и последующая компоновка в исполняемые файлы или библиотеки. Утилита управляет состоянием проекта с помощью специальных make-файлов, в которых указаны зависимости файлов прикладной программы друг от друга и правила для их преобразования. На основе информации о времени последнего изменения каждого файла утилита make определяет и запускает необходимые программы. Для использования утилиты make необходимо создать make-файл (GNUmakefile). После того как требуемый make-файл или их дерево создано, простой команды make all будет достаточно для выполнения всех необходимых перекомпиляций, если какие-либо из исходных файлов программы были изменены. Используя информацию из make-файла и зная время последней модификации файлов, утилита make решает, какие из файлов должны быть обновлены. Для каждого из этих файлов будут выполнены указанные в make-файле команды.

При вызове утилиты make в командной строке могут быть заданы параметры — цели (targets), указывающие, какие действия по изменению состояния проекта следует выполнить. Заметим, что утилита make никак не интерпретирует данные проекта, она лишь умеет запускать программы и анализировать файлы на основе правил и зависимостей, которые программист указал в make-файлах.

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

Структура дерева файлов рабочего пространства (workspace) среды Eclipse приведена ниже (жирным шрифтом выделены папки, обычным — файлы) (см. лист. 1).

Из приведенной структуры видно, что в Eclipse рабочее пространство (workspaсe) реализуется в виде корневой папки, в которой объединены проекты по какому-либо признаку, например, по типу микроконтроллера. Кроме файлов проектов в ней находятся папка SDK_embedded (software development kit) и файлы настроек Eclipse (папка .metadata и файлы .cdtproject, .cproject, .project). Файлы настроек Eclipse создает самостоятельно, разработчик не должен их модифицировать.

С точки зрения разработчика, наибольший интерес представляют собой папка SDK_embedded и папки проектов. Рассмотрим их подробнее.

Папка SDK_embedded предназначена для хранения файлов общей документации, необходимой разработчику, файлов внешних библиотек и общих скриптов, т.е. всего того, что можно вынести за рамки конкретного проекта, но в нем может быть использовано. Например, файлы исходных кодов внешних библиотек для различных проектов одинаковы, но их сборка может быть произведена разными способами с разным результатом. Поэтому логично исходные коды внешних библиотек хранить в SDK_embedded/libs, a информацию о том, как компилировать исходные файлы и результаты компиляции, — в самом проекте. Папка SDK_embedded содержит три папки:

– doc — документация по микроконтроллерам, среде разработки, утилитам и т.д.

– libs — исходные коды библиотек; в текущей реализации хранит папки с FreeRTOS, miniini-0.7.1, uip-1.0, CMSIS, STM32F10x_DSP_Lib, STM32F10x_StdPeriph_Driver.

– scripts — файлы скриптов make, gdb, openocd, общие для всех проектов.

Таким образом, если разработчик захочет добавить общую для всех проектов библиотеку, ему необходимо создать папку в SDK_embedded/libs и разместить там файлы исходных кодов. При минимальных манипуляциях в конкретном проекте библиотека будет собрана с заданными в проекте ключами компиляции и определениями препроцессора в файле библиотеки и скомпонована с объектными файлами приложения. Аналогично, если разработчику требуется внести какое-либо усовершенствование в систему сборки, например, добавить команду по созданию архивного файла текущей версии прошивки и передаче его в репозиторий с помощью системы контроля версий, ему необходимо добавить цель (target) в файл SDK_embedded/scripts/make/rules.mk, которая предпишет утилите make запустить архиватор и передать полученный архив клиенту системы контроля версий на отправку. С этого момента функциональность становится доступна во всех проектах. Папка SDK_embedded/doc позволяет иметь под рукой в одном месте различную документацию.

Рассмотрим структуру папки проекта. Она содержит:

– doc — документацию по проекту;

– lib — папку с файлами собранных библиотек;

– out — папку с результатами сборки конечных файлов;

– pc — папку с программами, утилитами или их исходными текстами, которые предназначены для работы на PC и для совместной работы с разрабатываемым устройством;

– scripts — папку со скриптами, используемыми в работе с проектом;

– src — корневую папку исходных текстов проекта, которая содержит папки приложения и библиотек;

Остановимся подробнее на некоторых позициях. Папка out после удачной сборки содержит следующие фалы:

– image.bin — бинарный файл прошивки, содержащий непосредственно программу, готовую для записи в память программ разрабатываемого устройства;

– image.dmp — дамп файла прошивки, который позволяет анализировать размещение секций и перечень всех символов (переменные и функции) программы;

– image.elf — ELF-файл программы, результат компиляции и компоновки проекта, содержит исполняемый код программы и полную информацию о ней, включая отладочную;

– image.hex — hex-файл прошивки, текстовый аналог image.bin;

– image.lss — листинг дезассемблированной программы, незаменимое средство анализа выходного исполняемого кода;

– image.map — листинг карты памяти, который позволяет анализировать содержание секций и расположение в адресном пространстве переменных и функций программы.

Папка pc, как сказано выше, должна содержать средства, относящиеся к инструментальному компьютеру. Это могут быть терминалы, usb-hosts, tcp-ip клиенты, серверы и прочие программы, обеспечивающие связь разрабатываемого устройства с компьютером.

Папка scripts содержит скрипты, специфичные для проекта. Например, в ней размещен файл скрипта компоновщика GNU ld, который определяет алгоритм сборки ELF-файла программы из объектных файлов и библиотек.

Папка src содержит папку application и папки используемых в проекте библиотек, а также три файла системы сборки. Папка application должна содержать файлы исходного кода, один из которых включает функцию main — точку входа в программу. Файлы могут содержать текст, написанный на C, C++, Fortran или ассемблере — система сборки по расширению файла автоматически определит, какой из компиляторов необходимо задействовать для получения объектного файла. Папки библиотек содержат файлы исходных кодов. Все без исключения папки содержат файл GNUmakefile. Существуют два принципиальных различия между папкой application и папками библиотек:

– наличие в папке application файла с определением функции main — в исходных текстах библиотек этого быть не должно;

– разное содержимое GNUmakefile.

Остановимся на втором пункте подробнее. Рассмотрим GNUmakefile из папки application (см. лист. 2) и папки библиотеки libhardware (см.  лист. 3).

Первый содержит переменную APPNAME, которая предписывает согласно целям сборки компиляцию исходных текстов в объектные файлы и компоновку приложения совместно с указанными в переменной LIBS библиотеками. Второй содержит переменную LIBNAME, которая указывает на необходимость сборки библиотеки (в приведенном случае — libhardware.a). Она помещается в папку lib проекта. GNUmakefile библиотеки может содержать определение переменной LIB_SRC_DIR, либо определение переменной может отсутствовать — в первом случае система сборки считает, что файлы исходного кода находятся за пределами проекта (внешняя общая библиотека), а во втором — что файлы в текущей папке. Это позволяет подключать к проекту как внешние библиотеки, так и локальные — выделенные участки кода приложения. Объектные файлы при компиляции помещаются в локальную папку.

Важным элементом проекта является система сборки — набор средств выполнения утилитой make действий по формированию выходного файла, готового к записи в память программ микроконтроллера. Система сборки состоит из утилиты make и набора скриптов, называемых GNUmakefile, а также дополнительных файлов, которые включаются в GNUmakefile приложения или библиотеки.

Как было сказано, обычная работа утилиты make состоит в считывании файла GNUmakefile с диска и выполнении определенных в нем целей; необходимость выполнения цели определяется зависимостями. Это можно пояснить так: при указании make выполнить цель — создать image.elf (выходной файл собранной программы) — утилита make проверяет наличие этого файла. Если его нет, то, пользуясь указанными правилами, она собирает его. Если файл есть, то утилита make проверяет зависимости от других целей — объектных фалов и библиотек, из которых компонуется приложение. Если существует новый объектный файл, то утилита make пересоберет приложение. Аналогичным образом объектные файлы зависят от своих файлов исходного кода. Итак, утилита make обнаруживает изменение любого файла исходного кода и по цепочке выполняет компиляцию измененных файлов и сборку проекта.

Содержимое GNUmakefile может для сложного проекта быть довольно сложным, поэтому принято общие сущности выносить во включаемые файлы:

– SDK_embedded/scripts/make/options.mk — включаемый файл общих для всех проектов рабочего пространства настроек, таких как унифицированная файловая структура проектов, имена файлов инструментов сборки (компиляторы, утилиты работы с бинарными файлами, архиваторы и т.д.);

– SDK_embedded/scripts/make/rules.mk — включаемый файл общих для всех проектов рабочего пространства правил сборки. Это основа системы сборки, файл содержит информацию о правилах компиляции, компоновки, архивации, очистки проекта и т.д., т.е. о стандартных для проекта действиях, которые можно выполнить. Этот скрипт содержит инструкцию включения файла SDK_embedded/scripts/make/options.mk;

– project_N/src/options.mk — включаемый файл настроек, индивидуальных для проекта, — опции компиляции, пути к используемым внешним библиотекам, определения препроцессора, имена скрипта компоновщика и т.д.;

– project_N/src/rules.mk — простой файл, который за счет механизма включения файлов объединяет все перечисленные выше файлы в project_N/src/options.mk и SDK_embedded/scripts/make/rules.mk. В результате утилита make получает полное описание целей и зависимостей для выполнения действий над проектом.

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

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

2. Библиотеки для микроконтроллеров STM32

Производители микроконтроллеров и поставщики инструментария предлагают библиотеки поддержки для ускорения разработки прикладных программ. Это исходные коды или скомпилированные библиотеки, которые облегчают разработку приложения, дают доступ к необходимым алгоритмам, структурно упрощают проект и его отладку. Рассмотрим библиотеки, которые могут быть использованы при разработке приложений для устройств на микроконтроллерах STM32.

Библиотека CMSIS (Cortex Microcontroller Software Interface Standard) — это интерфейс программного обеспечения Cortex, независимый от производителя микросхемы, абстрактный слой программного обеспечения уровня аппаратуры. Эта библиотека предназначена для предоставления коду приложения возможностей процессоров серии Cortex, которые непосредственно не доступны на языках высокого уровня. CMSIS обеспечивает:

– интерфейс доступа к периферийным регистрам;

– определения таблиц векторов исключений;

– определения имен регистров «основной периферии», к которой относится ФАПЧ и система управление питанием, контроллер прерываний NVIC, интерфейс отладки ITM уровня приложения, системный таймер SysTick;

– независимый программный интерфейс для RTOS, включая канал отладки;

– С-интерфейс доступа к инструкциям процессора.

Библиотека STM32F10x_StdPeriph_Driver — библиотека драйверов периферийных устройств для микроконтроллеров STM32. В отличие от CMSIS, эта библиотека предоставляется компанией STMicroelectronics и обеспечивает интерфейс периферийных модулей, реализованных за рамками ядра Cortex — периферии, которую в микроконтроллер добавил производитель микросхемы. Эта библиотека содержит драйверы и вспомогательные функции, которые обслуживают периферию микроконтроллеров STM32:

– контроллер прерываний NVIC;

– системный таймер SysTick;

– аналого-цифровые преобразователи ADC;

– независимую зону сохранения данных BPK;

– модули CAN;

– модуль CEC;

– модуль расчета контрольной суммы CRC;

– модуль цифро-аналогового преобразователя DAC;

– модуль интерфейса отладки DBGMCU;

– модуль прямого доступа к памяти DMA;

– модуль внешних прерываний EXTI;

– контролер флэш-памяти;

– контролер внешней памяти FSMC;

– модуль линий ввода-вывода GPIO;

– модуль интерфейса I2C;

– модули сторожевых таймеров IWDG и WWDG;

– модуль управления питанием PWR;

– модуль управления шинами и ФАПЧ RCC;

– модуль часов реального времени RTC;

– модуль интерфейса SDIO;

– модуль интерфейса SPI;

– модуль TIM;

– модуль интерфейса USART.

3. Проверка работоспособности модуля TE-STM32F103

Исходный текст тестирующей программы модуля TE-STM32F103 может служить для демонстрации приемов программирования микроконтроллеров STM32. Тестирующая программа проверяет функционирование ядра микроконтроллера и связанных с ядром внешних схем, а также его периферийных блоков и внешних схем, связанных с этими блоками. Проверяется функционирование:

– блока АЦП и цепей подключения к разъему;

– блока SDIO и подключение слота карты microSD;

– блока USB и цепи подключения разъема miniUSB;

– блока CAN, микросхемы драйвера и цепи подключения разъема;

– блока UART, моста UART-USB и подключение разъема miniUSB;

– светодиодов и цепей их подключения к выводам GPIO.

Стенд для тестирования включает компьютер с утилитой программирования микроконтроллеров STM32, тестируемый модуль TE-STM32F103, стендовый модуль TE-STM32F103 (заведомо исправный, реализующий CAN-сервер), резистивный делитель для проверки АЦП, шлейф для соединения плат по шине CAN, карту microSD с файловой системой FAT32. Тестируемый и стендовый модули предварительно программируются, программа тестирования для них одна. Соединение модулей TE-STM32F103 при выполнении тестирующей программы представлено на рисунке 1.

Рис. 1. Соединение модулей TE-STM32F103 при выполнении тестирующей программы

После подачи напряжения питания стендовый модуль выполняет:

– проверку слота SD. Обнаружив в нем отсутствие карты, он переходит в режим CAN-сервера;

– для индикации активности мигает светодиодом;

– выполняет прослушивание CAN-шины;

– в случае успешного приема пакета данных выполняет отправку источнику копии принятого пакета и мигает другим светодиодом.

Тестируемый модуль после подачи питания выполняет:

– проверку слота SD. Обнаружив наличие карты, переходит в режим тестирования. Как результат теста устанавливается флаг прохождения теста и диагностические данные;

– тестирование интерфейса CAN. Отсылается широковещательный пакет в шину CAN и ожидается ответ. В случае приема «эхо-пакета» устанавливается флаг удачного прохождения теста;

– тестирование модуля АЦП. Производится многократное измерение тестового напряжение c делителя на выводе PC.04, усреднение результата и сравнение модуля разности результата и константы с заданным порогом. Если порог не превышен, устанавливается флаг удачного прохождения теста;

– микроконтроллер активирует USB-интерфейс и прослушивает шину USB;

– согласно значениям флагов выполняется индикация светодиодами результатов тестирования;

– по получению USB-запросов выполняется их обработка.

Состояние светодиодов после выполнения тестов приведено в таблице 1.

Таблица 1. Индикация результатов тестирования светодиодами

Результат тестирования	Светодиод D12	Светодиод D11	Светодиод D10
Стендовый модуль (CAN-сервер)
Прослушивание шины	0	0
Был принят пакет	0
Тестируемый модуль
Ни один тест не пройден	0	0
SD ОК	0	1
ADC ОК	1	0
SD+ADC ОК	1	1
CAN ОК	0
CAN+SD ОК	1
CAN+ADC ОК		0
CAN+SD+ADC ОК

Примечание: 0 — светодиод погашен; 1 — светодиод зажжен;  — светодиод мигает (период ~100 мс)

 

3. Тестирующая программа модуля TE-STM32F103

Структурно тестирующая демонстрационная программа разделена на три уровня — прикладной, уровень пользовательских библиотек и уровень системных библиотек (см. рис. 2).

Рис. 2. Структурные уровни программы

Прикладной уровень для доступа к аппаратным ресурсам модуля использует библиотеки драйверов периферии STM32 и библиотеку FatFS. Точкой входа в программу является функция main в файле src/application/main.c.

Эта функция реализует общий алгоритм функционирования программы. Рассмотрим ее листинг 4.

Первой вызывается функция SystemStartup(), которая выполняет инициализацию микроконтроллера, системы синхронизации и т.д. После ее вызова микроконтроллер готов к функционированию на штатной тактовой частоте. Далее устанавливаются флаги sb_can_mode и can_activity, переводящие модуль в режим CAN (в данном микроконтроллере периферийные модули CAN и USB разделяют общие аппаратные ресурсы и не могут функционировать одновременно). Затем вызывается функция DebugLedInit(), подключающая выводы GPIO к светодиодам в качестве выходов. Далее выполняется проверка наличия карты microSD в слоте. Если ее нет, то модуль переводится в режим сервера CAN и слушает шину (can_test(cgtServer)). В противном случае происходит тестирование платы. Следующим шагом является проверка работоспособности интерфейса CAN — can_test(cgtClient). Затем выполняется тест интерфейса SDIO вызовом функции sdio_test() и завершается программа тестом АЦП — adc_test(). По результатам тестов выставляются флаги, которые влияют на индикацию светодиодов после всех проверок. По окончании теста АЦП модуль переводится в режим периферийного устройства USB — функция UsbStartup(), который обеспечивает возможность передачи результатов программы на компьютер. После инициализации состояния индикации DebugLedInitIndication(….) программа входит в бесконечный цикл, в котором каждые 200 мс происходит обновление состояния светодиодной индикации. Рассмотрим файлы, реализующие использованные в main() функции.

Файл adc.c содержит реализации функций:

1. adc_init() — функция инициализации АЦП.

2. adc_start() — запуск АЦП.

3. adc_stop() — останов АЦП.

4. adc_test() — код теста.

Все функции кроме adc_test() используют напрямую функции фирменной библиотеки драйверов STM32. Последняя из перечисленных функций реализует выполнение собственно теста. Ее листинг имеет следующий вид (см. лист. 5)

Вызовом memset(ADCConverted
Value , 0 , 256 * 2) обнуляется буфер, в который будут записываться измеренные значения напряжения. adc_init() инициализирует АЦП на циклическую запись в буфер с помощью периферийного модуля DMA, затем АЦП запускается вызовом функции adc_start(), и выполняется задержка, в течение которой буфер заполняется измеренными значениями. После задержки АЦП останавливается — adc_stop(). Затем происходит усреднение измеренного значения, вычисление значения напряжения в вольтах и сравнение с заданной величиной. По результатам сравнения формируются флаги результата теста.

Файл can.c содержит единственную функцию void can_test(TCANGateType gate_type). Тело функции содержит инициализирующие вызовы драйверы блоков GPIO и CAN, а также код теста обмена по шине CAN (см. лист. 6).

Если в модуль установлена SD-карта, то он явится инициатором обмена и приемником эхо-ответа — флаг can_gate_type установлен в значение cgtClient. В этом случае заполняется структура CAN-сообщения. В поле TxMessage.Data[] записываются передаваемые тестовые данные.

Вызовом функции Transmit
Mailbox=CAN_Transmit(CAN1, &TxMessage) выполняется передача сообщения в шину с опросом состояния while((CAN_TransmitStatus(CAN1, TransmitMailbox) != CANTXOK) &&
(i != 0xFFFF)). После отправки сообщения выполняется задержка ожидания приема. При приеме эхо-сообщения приемник CAN запросит прерывание, в обработчике которого (файл stm32f10x_it.c) выполнится проверка и установка флагов результата теста. После задержки ожидания приема модуль CAN деинициализируется CAN_DeInit(CAN1) и выключается вызовом функции RCC_APB1PeriphClockCmd(RCC_APB1Periph_CAN1, DISABLE ). Это необходимо для перевода блока в режим работы периферийного устройства USB.

Файл crt.c является стандартным для микроконтроллеров STM32. Он содержит таблицу векторов прерываний IrqHandlerFunc flash_vec_table[] и функцию Reset_Handler(void), которая вызывается при сбросе процессора и содержит два вызова — функции crt_init() для стандартной инициализации секций и функции инициализации системной библиотеки libc. По окончании инициализации вызывается функция main().

Файл debug_led.c содержит следующие реализации функций:

– void DebugLedInit() — инициализация GPIO для управления состоянием светодиодов D10,D11,D12;

– void DebugLedToggleD10() — изменение состояния светодиода D10 на противоположное;

– void DebugLedToggleD11() — изменение состояния светодиода D11 на противоположное;

– void DebugLedToggleD12() — изменение состояния светодиода D12 на противоположное;

– void DebugLedInitIndication
( bool can_state , bool adc_state , bool sd_
state ) — установка флагов состояния индикации;

– void DebugLedsToggle() — изменение состояния светодиодов по флагам.

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

Файл sdio.c содержит реализацию функций TestStatus sdio_test() (см. лист. 7).

Функция FatFS f_mount выполняет инициализацию SDIO и монтирует файловую систему, затем выполняет запись дампа прошивки микроконтроллера на SD-карту. По результатам записи выставляется флаг sdio_test_result.

Файл usb_request_handlers.c содержит таблицу адресов и реализации обработчиков USB-запросов.

4. Трансляция и отладка программы

Для сборки проекта, получения образа прошивки и отладочных файлов необходимо воспользоваться возможностями Eclipse по работе с проектами, основанными на make-файлах. Для этого необходимо открыть окно Make Target (см. рис. 3), в котором для текущего проекта отображаются цели сборки — действия, позволяющие собрать или очистить весь проект или его отдельные библиотеки.

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

Если сборка успешно завершилась, в папке out будут размещены выходные файлы image.elf и image.bin. Первый содержит код программы и отладочную информацию для GDB, второй — образ прошивки. Их можно увидеть в окне Project Explorer.

Теперь можно переходить к отладке. Необходимо сделать проект активным и в меню отладки Debug вызвать TE-STM32F103 write.

В результате IDE Eclipse запускает отладчик GDB, который через интерфейс MI взаимодействует со средой, а по интерфейсу TCP/IP с сервером OpenOCD. Последний, в свою очередь, обеспечивает связь с микроконтроллером через интерфейс JTAG. После выполнения скрипта инициализации (который обеспечивает запись прошивки) отладчик останавливает устройство на точке прерывания main. На рисунке 4 представлен экран IDE Eclipse после запуска процесса отладки. Вид экрана изменяется при переходе из режима сборки проекта (C/C++) в режим отладки (Debug). Выбор отображаемых на экране окон может осуществляться с использованием команды Window/Show View.

Рис. 3. Экран IDE Eclipse в режиме сборки проекта программы

Рис. 4. Экран IDE Eclipse в режиме отладки программы

4. Комплексирование и настройка аппаратно-программных средств

На сайте компании «Терраэлектроника» в каталоге есть карточка модуля TE-STM32F103, где представлена техническая информация о модуле и микроконтроллере STM32F103RET6. Имеется также ссылка на статью, в которой эти аппаратные средства описаны подробнее. Архивы файлов системы Eclipce/GCC и проекта тестирующей программы также можно получить, пройдя по ссылкам на этой карточке. Кроме того, они имеются на компакт-диске из комплекта модуля. Все файлы должны быть установлены в одной директории (например, A_ECLIPSE). Чтобы указать пути к папкам с исполняемыми файлами обработчиков проекта и собственно среды Eclipse, необходимо дополнить строку системной переменной Path компьютера (например, добавить C:/A_ECLIPSE/kgp_arm_eabi/bin; C:/A_ECLIPSE/eclipse_arm). Изменения строки переменной Path возможны в разделе Переменные среды после нажатия клавиши Изменить под окном Системные переменные (Мой компьютер/Свойства/Дополнительно/Переменные среды/Системные переменные).

В текущей версии инструментального пакета все описанные ранее установки уже сделаны. После запуска файла eclipse.exe из папки …/eclipse_arm/*.* сразу открывается проект тестирующей программы, который можно изучать, менять и транслировать.

Для совместной отладки аппаратуры и программы описываемая сборка Eclipse/GCC позволяет использовать эмуляторы TE-ARM-LINK, ARM-USB-OCD, ARM-USB-TINY. При подключении одного из них предварительно в файле …/SDK_embedded/scripts/openocd/stm32ret6 следует удалить символ комментария в соответствующей строке.

Разработчики могут для своих проектов приобрести в «Терраэлектронике» как модули TE-STM32F103, так и микроконтроллеры STM от одной штуки со склада, а также получить технические консультации инженеров компании по вопросам их применения.

Литература

1. В. Бродин, С.Чернов. Конфигурация среды Eclipse/GCC для разработки программ STM32. Электронные компоненты. №8. 2010 г. С. 15—20.