Разработка для STM32F4Discovery с помощью mbed в QtCreator

В последнее время библиотека mbed набирает обороты. Одновременно с этим у замечательного C/C++ IDE от команды Qt средства работы с голым железом достигли нового уровня. Осторожно, много картинок (меньше 1Мб). Qt Creator имеет гибкую систему плагинов. Для этого проекта мы будем использовать плагины BareMetal и QbsProjectManager.

После включения плагинов надо перезапустить QtCreator.

К этому моменту у нас настроено удалённое подключение к серверу gdb. Сервером gdb может быть st-util или OpenOCD под windows, linux и OS X.

В моём тулчейне в gdb отсутствовала поддержка python, поэтому потребовалась пересборка

Код проекта можно найти по адресу.

Для работы с baremetal в QtCreator можно использовать cmake или просто make файлы, но с помощью Qbs мы сможем описать сборку проекта проще и быстрее.

Скрипт сборки использует язык, подобный javascript для задания опций компилятору, дефайнов (DEBUG), путей к библиотекам и файлам. К сожалению, ассемблерные файлы можно задать только через опции линковщика, но это будет исправлено в новых релизах qbs.

• Работает загрузка прошивки одной кнопкой из IDE
• Работает отладка на уровне исходных текстов с просмотром текущих значений, точками останова и прочее
• Есть правильное автопродолжение как С так и С++ кода
• Быстрая навигация (alt+click/command+click)по функциям, переменным, структурам
• Информация о типе, наборе параметров для функций, переменных
• Подсветка одинаковых элементов кода в пределах файла, подсветка кнопок
• С mbed программировать под stm гораздо проще: автоматически включается тактование переферии и производится настройка нужных ножек.

Для Windows настройка описанная в статье будет совершенно аналогична.

1. Поставить драйвера для stlink через zadig
2. Поставить OpenOCD
3. Поставить GCC тулкит
4. Распаковать GDB с поддержкой arm и python тот же архив прикреплён к этой статье
5. Настроить QtCreator как описано в статье порт для gdb указывать 3333
6. Запустить openocd

, , , , ,

• +13
• 04 мая 2014, 10:55
• 1

это OS X, под linux будет совершенно аналогично: 1) собрать stlink 2) скачать и распаковать компилятор с лаунчпада 3) собрать gdb 4) скачать и поставить Qt 5.2.1 qt-project.org 5) настроить как в статье.

mbed не обязателен, я собрал свой проект на 4000 строчек кода (без коментариев и пустых строчек, 40 файлов не считая cmsys, StdPeriph, USB_Device) который до этого был на makefile. До этого ещё была безуспешная попытка перехода на cmake

code::blocks в сравнении со свежими QtCreator — сложный (много меню, тулбаров) — медленный (залипает на несколько секунд) — нулевая поддержка макросов в С — нестабильный (аварийное завершение на полу-пустом файле) — не нашёл поддержки редактирования как в Vim — не работает со сборочной системой напрямую, нужны файлы проектов + есть довольно много расширений + есть шаблоны проекта для AVR + есть поддержка языков отличных от C/C++ + Если я правильно понял, то есть поддежка wxWidgets

Мне кажется, что если что-то держит на code::blocks то имеет смысл попробовать Sublime, по функциям будет похоже, но работает быстрее и стабильней и не такой перегруженный интерфейс.

— с автодополнением может, с clang на отлично, с ctags как везде — с поиском определения может (ctrl+r вроде) — есть плагины, чтобы тултипы показывать с документацией на функцию

Ну или прямо из этого поста код использовать

Планировать какие пины как использовать удобно в STM32CubeMX (искать на сайте st.com). Подключенную переферию (как из примера) можно посмотреть в схеме платы, ноги все названы как в документации на чип, только через подчёркивание (PA_0).

Полный список: mbed-for-baremetal-qtcreator/mbed-src/targets/hal/TARGET_STM/TARGET_STM32F4DISCOVERY/PinNames.h

Qt принадлежит Digia.

Если не требуется статическая линковка библиотек Qt или доработка кода самих библиотек Qt без выкладывания кода этих изменений, то уже больше пяти лет как коммерческая лицензия не требуется, потому что LGPL.

К этому топику не относится, потому что тут мы используем софт на основе Qt как простые пользователи, а не как разработчики.

Эти нюансы важны только если у вас есть коммерческое графическое приложение с использованием Qt под Linux/Windows/OS X/iOS/Android.

Debug/Start Debugging/Attach to remote GDB server

Можно использовать cmake вместо Qbs. Или по-старинке генерировать список файлов для проекта Qt

надо только ещё добавить monitor reset halt load полный_путь_к_elf monitor reset halt в файл (Server start script).

Как я понимаю это делает ненужным baremetal

Не выходит почему-то…

Qt Creator 3.0.1, Qt 5.2.1. GDB 7.7 собран с поддержкой Python:

При Attach to Remote Debug Server нет никакой реакции на содержимое Server Start Script. Вывод OpenOCD такой:

Если вручную выполнить в этом gdb

вывод будет такой:

Рылся в исходниках, так и не понял, как на stm32 заработает этот код:

#include «mbed.h» Serial pc(USBTX, USBRX); // tx, rx int main() Тем более, на Нуклео нативный УСБ вообще наружу не выведен, как я понял.

Кстати, у кого-нибудь есть Makefile для mbed? Что-то у меня qbs не завёлся ((

USBTX, USBRX — должны быть ножки на которых у контролера выведен USART. Например, для моей платы — STM32F4Discovery, это USART2 (ноги PA_2(tx) и PA_3(rx))

mbed поддерживает 4 платы Discovery и 4 плат nucleo. Посмотрите определения дефайнов USBTX, USBRX для вашего таргета в mbed, сверьтесь со схемой.

Для Nucleo пины дефолтового ком порта идут через встроенный stlink и, как я понимаю, stlink кроме питания, дебага, даёт ещё устройство виртуального com порта.

Только у меня падает QtCreator при отладке при нажатии на кнопки Interrupt и Stop Debugger?

Пишу под Windwos 7. GDB из этой статьи, gdb-arm-none-eabi.exe. Плата stm32f4discovery, проект из статьи (https://git.gitorious.org/mbed-for-baremetal-qtcreator/mbed-for-baremetal-qtcreator.git).

аналогично для windows 7 64bit

Попробуйте: — использовать короткие пути для проекта — на 64битной win надо использовать 64битный openocd — родные драйвера к stlink не должны быть установлены, только драйвера поставленные через Zadig для stlink — в архиве несколько gdb, нужный: qtcreator-gdb-7.7-mingw32_nt-6.1-i686\gdb-arm-none-eabi.exe — gcc я брал с лаунчпада, exe поставил по дефолтным путям

Сделал все как сказали, — Пути короче некуда — Скачал отсюда последний OpenOCD -> www.freddiechopin.info/en/download/category/10-openocd-dev/ Но раньше, да запускал 32-битную версию — С Zadig'ом поковырялся оставил только libusbK драйвера — gdb использую именно этот, только путь ему покороче сделал — gcc использую тоже launchpad'овский В итоге: отладка, если предварительно выбрать точку останова, может начаться, а может и не начаться. И если началась, то перезапустить уже нельзя, а если остановишь, то в следующий раз придется перезапускать OpenOCD, так как он не запуститься и опять упадет креатор. Настройки OpenOCD сделал по статье hertaville.com/2012/09/16/part-3-debugging-openocd-0-6-0/

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

Никто не заметил, но в «Добавляем кит» у вас неверный скриншот )

А как создавать новый проект? Он даже не показывает добавленный кит в «C project» и так далее.

> А как создавать новый проект? New Project => Non-Qt Project => Plain C Project (Qbs Build) Создали пустой проект. Открываем Вкладку Projects из левой колонки Add kit => ваш кит (у меня stm32) Если кита ещё нет, тогда надо идти в Manage Kits и делать его.

Выбор кита при создании проекта происходит если выбрать просто C project, т.к. qmake. Я не знаю, можно ли qmake использовать для кросплатформенной сборки. Даже если можно, этот пост не имеет к qmake никакого отношения.

у меня сейчас только 10.10 под рукой и там всё сложно с питонами: qt-creator работает с систеный, при сборке gdb скриптами из исходников qt-creator используется ещё один питон. Всё усугубляется тем что в ратнайме получается дикая смесь из .so файлов в питоновский модулях.

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

Внутри qt-creator-opensource-src-3.2.2/dist/gdb/Makefile.osx модифицированный для сборки с системным питоном.

скомпилированный gdb для arm: gdb-arm-none-eabi qt-creator-opensource-src-3.2.2/dist/gdb/qtcreator-gdb-7.8-darwin-x86_64.tar.gz

Через пайпы в связке openocd-gdb не заработало, но нормально работает дебаг и заливка если запускать openocd из командной строки в терминале: openocd -f board/stm32f4discovery.cfg

Если что-то не заработает: ./gdb-arm-none-eabi запущенный из командной стоки не должен выдавать ошибок Ещё стоит посмотреть что пишет qt-creator в консоль если его запустить из терминала cd "/Users/ihanick/devel/Qt/Qt Creator.app/Contents/MacOS" ./Qt\ Creator и пытаемся стартануть дебаг.

Если будет писать что не gdb находит каких-то библиотек надо пересобрать: cd qt-creator-opensource-src-3.2.2/dist/gdb make -f Makefile.osx

./gdb-arm-none-eabi выдал такое

warning: Could not load the Python gdb module from `/usr/local/Cellar/isl/0.12.2/share/gdb/python'. Limited Python support is available from the _gdb module. Suggest passing --data-directory=/path/to/gdb/data-directory.

удалил все пересобрал как Вы сказали export PATH=/usr/bin:/bin:/usr/sbin:/sbin:/opt/X11/bin cd qt-creator-opensource-src-3.2.2/dist/gdb make -f Makefile.osx

результат тот же, удалять homebrew, поможет?

В архив файлы питоновские из дистрибутива gdb не попадали: qtcreator-gdb-7.8-darwin-x86_64.tar.gz

Также убрал все зависимости от /usr/local (от brew и тех пакетов, которые у меня стоят).

Запускать / указывать путь в qt creator надо gdb-arm-none-eabi.sh (этот скрипт добавляет параметр, где gdb будет искать свои питоновские файлы

да кажется работает, огромное спасибо Вам.

у меня плата дискавери с 429 камнем, я так понял у mbed нет для нее поддержки. буду искать способ прикрутить проект из cubeFx

Вдруг поможет, чтобы не с нуля делать: Это пример для stm32f4discovery: cubeblink.zip

В нём: работающий пример проекта сгенерированного в STM32CubeMX. Генерация производилась под Keil MDK-ARM и под TrueSTUDIO. В TrueSTUDIO 5.0 для нормально сборки надо настройках включить hardware floating point (для компилятора и линковщика). После того как проект собирается, его надо зачистить собрать снова. Во время сборки будут видны все команды и их параметры в одном из окошке.

Параметры сборки и линковки можно использовать в shell скрипте для сборки (например как в cubeblink/Projects/TrueSTUDIO/cubeblink Configuration/Debug/build.sh) или сконвертировать этот шел скрипт в makefile или как я добавить в *.qbs файл: cubeblink.qbs

В вашем случае скорее всего будет работать с этим qbs файлом после замены STM32F407xx на STM32F429xx

Светодиод будет на другой ножке:

в вашем .qbs заменил дефайн на 429, а также подсунул свой startup_stm32f429xx.s, отладчик все работает но "-T"+path+"/Projects/TrueSTUDIO/cubeblink\ Configuration/STM32F407VG_FLASH.ld", такого мне cubeMX не положил, поэтому оставил Ваш.

почему-то GPIOG, GPIO_PIN_13 НЕ мигает(

скрипт линковщика лежит в Projects/TrueSTUDIO/название проекта Configuration STM32F429ZI_FLASH.ld

Вообще, я обычно делаю проект для TrueSTUDIO или MDK-ARM, проверяю, что периферия работает и потом уже конвертирую в gcc проект. Портировать надо 100% работающий код.

Если там всё хорошо: Вторая идея: поставить бряк на начало мейна и начать дебажить, обычно или это сразу наталкивает на правильные мысли, или видна какая-нибудь глупая ошибка (моргание написано в другом main.c).

так вот в том то и дело, cubeMX в Projects/TrueSTUDIO ничего не положил, пусто там

мэин смотрел, бегает цикл while, все норм

вообщем на другом компьютере с виндой cubeMX нормально генерирует проекты, подсунул STM32F429ZI_FLASH.ld

но увы, не мигает диод.

в эклипсе есть проект, который успешно работает, только там на таймере завязано моргание

Может у вас найдется еще время мне немного помочь? Заранее спасибо!

Пытаюсь провернуть тоже самое с stm32f103c8, т.е просто собрать проект в креаторе. Хочу сделать через qbs, но никак не подберу нужные флаги и файл startup(их несколько). Дело в том что cubeMx пока не отдает полноценные проекты для f103, обещают скоро сделать правда. И в STM32F10x_StdPeriph_Lib_V3.5.0 нет .ld скриптов линковщика. поставил под виндой Em::Blocks и стянул оттуда пустой проект для f103, там есть скрипт .ld для заливки. Но все никак не удается запустить с файлом startup_stm32f10x_md.s. ни с версией из проекта емблокс, ни из STM32F10x_StdPeriph_Lib_V3.5.0

перепробовал кучу флагов, минимальное кол-во ошибок выдает при таком варианте

и с файлом startup из emblocks получаю при сборке

и с файлом startup из STM32F10x_StdPeriph_Lib_V3.5.0 получаю при сборке

в папке ldscripts скрипты из проекта на эклипсе, с ними вроде собралось без ошибок но ничего на плату не заливается уже незнаю что и делать, охото на маке работать(

Вы правы, это помогло, но я тут разобрался наконец. Нашел в STM32F10x_StdPeriph_Driver флэш скрипт(только поправил в нем размер flash с 128 на 64кб) и заработало со стартап файлом оттуда же без нужны в определении _exit

Вот проект, мож кому пригодиться. Я не уверен во всех флагах компилятора и линковщика, но пока вроде работает) cubeblink_f103.zip

mbed, он просто, для примера взят. Другой пример в обсуждении написан на C и использует новый hal от ST. CubeMX HAL

Т.е. это статья про настройку IDE для C++ или для C. Можно без библиотеки от ST запуститься, но у меня таких проектов нет. Я люблю начинать с работающего примера для периферии, а usb или ethernet на голых регистрах — это много потерянного времени.

Вы сильно ошибаетесь. И касательно конструкторов и деструкторов.

Деструктор опционален. Это специальный метод, который (если он присутствует) будет вызван до уничтожения объекта (на самом деле будет вызвана цепочка деструкторов в случае наследования). Этот метод нужен программисту, для того, что-бы он мог освободить ресурсы, которые захватил или выделил объект. Ели я, например, в конструкторе явно выделил буфер в куче – я должен в деструкторе эту память явно освободить. Соответственно, ели объект не выделяет никаких ресурсов (а в случае МК – динамическое выделение памяти практически не используется), то деструктор такому объекту не нужен.

Бегло посмотрел статью по ссылке. В первом случае – баг в компиляторе, во втором – бросили исключение из конструктора, в третьем особенности диспетчера памяти Solaris.

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

Если говорить о применении к МК – почему вы так боитесь утечек памяти, с учетом того, что динамическое выделение памяти на МК веешь ну очень экзотическая…?

1. мне как раз надо динамически выделять… это сильно упростит программирование. но я обхожусь без выделения. 2. объекты в одном экземпляре не имеют смысла тк в количестве кода нет выигрыша. 3.несколько копий объекта в малым количеством оперативки также смысла не имеет.

4. на небольших проектах и на проектах с малыми ресурсами (коими являются микроконтроллеры) использование ооп неоправдано…

если проект большой то использование ооп упростит и ускорит процесс программирования. но это уже не наш случай…

если можно обойтись без объектов буду писать без них. комп всегда под рукой и его перегрузить умеют все… а вот ехать за триста верст перегружать батарейный прибор это уже в копеечку влетит еще и заказчик по шее даст… так что лучше 100% без риска. и сто процентно отлажено и проверено…

я не против ооп я против его применения в микроконтролерах.

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

При желании вполне можно добиться того, что код на классах в С++ будет не менее оптимален, чем на С (а то и более — по некоторым наблюдениям, GCC несколько лучше компилирует в режиме С++, даже если скормить ему чисто сишный код) — если это нужно (да, оптимальность кода — далеко не единственная цель, которая может ставиться перед программой).

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

Никто не заставляет вас писать на С++. Я так понял, что переубедить вас не получится, да и не в этом цель.

Я просто хочу развенчать миф о том, что ООП/С++ это что-то сверхсложное, обязательно связанно с жутким перерасходом ресурсов и т. д. Единственное условие и «секрет успеха» – нужно действительно хорошо владеть этим инструментом (но это касается и любого другого инструмента).

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

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

Одну текущую задачу сначала показали «плюсовику», спросив, сколько займёт её решение. Он сказал: «Здесь нужно писать могучий движок. Короче говоря, это проект на полгода». Его коллега-«сишник» поинтересовался: «А зачем?» Ведь поставленная задача укладывается в сотню строк кода! Ответ был ошеломляющим: «Ну и что, мы так и будем по сотне строк кода писать для решения частных задач, каждый раз, как они возникают? Нетушки, задачи надо решать раз и навсегда!».

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

Это всё про C++98 с большой долей java программирования.

очень рекомендую посмотреть: www.stroustrup.com/programming.html или предыдущее издание (есть перевод на русский язык, для тех кто жадничает есть epub второго английского издания). На C++ можно писать ясные, короткие и простые программы, каждый раз используя только то подмножество языка, которое необходимо. В рамках темы, рекомендую главу 25 где описываются проблемы и типовые решения c++ во встраиваемых системах.

Например, на C я использую односвязный список для хранения «свободных» узлов дерева. Само дерево требует указателя на функцию сравнения и постоянных кастов из struct avl* и обратно. При вставке и поиске есть оверхед на вызов функции по указателю (потому как компилятор не понимает, что функцию из двух сравнений тут можно инлайнить).

Мне надо два таких дерева, одно для таймеров, второе для счётчика входящих сигналов на 20-50 элементов (количество и значения меняются динамически). В идеале можно было использовать микроконтроллерные таймеры и прерывания, но контроллеров с таким количеством таймеров я не знаю, а создание цепочек таймеров так же влечёт к спискам/деревьям и чревато гонкой между обработкой прерывания и созданием нового.

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

Другой пример, уже из разряда работы с периферией: net_tcp_server из stm32plus против кода сгенерированного в STM32CubeMX + tcp_echo_server из старых примеров под STM32*Eval.

Если кому-то интересно могу сделать статейку по запуску ethernet на stm32f4discovery + Discover More :) оно же STM32F4-BB. Там не будет C++, зато распишу подводные камни, как генерировать, как преобразовывать проекты на CubeMX в make+gcc