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

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

Qt Creator имеет гибкую систему плагинов. Для этого проекта мы будем использовать плагины BareMetal и QbsProjectManager.

Включение плагинов QtCreator
Находим меню About Plugins
Включаем плагин Qbs
Включаем плагин BareMetal

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

Настройка плагина BareMetal
Открываем настройки
Переходим в раздел Devices на левой вкладке
Добавляем новое голое железо
Добавляем stlinkv2 как baremetal устройство в QtCreator
К этому моменту у нас настроено удалённое подключение к серверу gdb. Сервером gdb может быть st-util или OpenOCD под windows, linux и OS X.

Настройка компилятора
Preferences/Build&Run/Compilers/Add/GCC/Путь к arm-none-eabi-g++
Я использую свежую сборку gcc 4.8 GNU Tools for ARM Embedded Processors

Настройка дебагера
Preferences/Build&Run/Debuggers/Add/Путь к arm-elf-gdb

В моём тулчейне в gdb отсутствовала поддержка python, поэтому потребовалась пересборка
mkdir build-gdb
cd build-gdb
../gdb-7.6/configure --target=arm-elf --prefix=/Users/ihanick/Devel/gdb-arm
make all install


Добавляем кит
Добавляем кит, надо выбрать все предыдущие элементы
Preferences/Build&Run/Kites/Add надо выбрать наш новый девайс, компилятор и дебагер

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

Или тут

git clone https://git.gitorious.org/mbed-for-baremetal-qtcreator/mbed-for-baremetal-qtcreator.git


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

import qbs 1.0

Product {
    type: "application"
    Depends { name:"cpp" }
    property string mbed: "mbed-src/"
    property string rtos: "mbed-rtos/"
    property string vendor: "STM"
    property string model: "STM32F4DISCOVERY"
    property string toolchain: "GCC_ARM"
    property string cortex: "M4"
    cpp.defines: ["TOOLCHAIN_GCC_CW=1"]
    cpp.positionIndependentCode: false
    cpp.debugInformation: true
    cpp.commonCompilerFlags: [
        "-mthumb","-mcpu=cortex-m4",
        "-mfloat-abi=hard","-mfpu=fpv4-sp-d16",
        "-fdata-sections","-ffunction-sections",
        "-fno-inline","-std=c99","-flto"]
    cpp.linkerFlags:[
        "-flto","-mthumb","-mcpu=cortex-m4",
        "-mfloat-abi=hard","-mfpu=fpv4-sp-d16",
        "--specs=nano.specs","-Wl,--start-group",
        "-Wl,--gc-sections",
        "-T",
        path+"/"+mbed+"targets/cmsis/TARGET_"+vendor
            +"/TARGET_"+model+"/TOOLCHAIN_"
            +toolchain+"/STM32F407.ld",
        "-lnosys","-lgcc","-lc"]
    cpp.includePaths: [
    	mbed+"api",
    	mbed+"hal",
      mbed+"targets/cmsis/",
      mbed+"targets/cmsis/TARGET_"+vendor+"/TARGET_"+model+"/",
      mbed+"targets/hal/TARGET_"+vendor+"/TARGET_"+model+"/",
      mbed+"devices/lis302/"
    ]
    files: [
    	mbed+"api/*.h",
    	mbed+"common/*",
    	mbed+"hal/*.h",
    	mbed+"targets/cmsis/*.h",
    	mbed+"targets/cmsis/core_cm4_simd.h",
    	mbed+"targets/cmsis/TARGET_"+vendor+"/TARGET_"+model+"/*",
    	mbed+"targets/cmsis/TARGET_"
           +vendor+"/TARGET_"+model+"/TOOLCHAIN_"+toolchain+"/*",
    	mbed+"targets/cmsis/target/*.h",
    	mbed+"targets/hal/TARGET_"+vendor+"/TARGET_"+model+"/*",
      mbed+"devices/lis302/*",
      "main.cpp"
    ]
    Properties {
        condition: qbs.buildVariant === "debug"
        cpp.defines: outer.concat(["DEBUG=1"])
    }
    Group {
        qbs.install: true
        fileTagsFilter: "application"
    }
}


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

Тестовый код
#include "mbed.h"
#include "LIS302.h"

/* LIS302DL
 * SPI1_MOSI PA_7
 * SPI1_SCK  PA_5
 * SPI1_CS   PE_3
 * SPI1_MISO PA_6
 * MEMS_INT1 PE_0
 * MEMS_INT2 PE_1 */

DigitalOut myled(LED1);
SPI _spi(PA_7,PA_6,PA_5);
DigitalOut _cs(PE_3);

int main() {
   int val=0;
   // 8 bit data, high steady state clock
   _spi.format(8,1);
   // 1 Mhz
   _spi.frequency(1000000);
   //chip select active low
   _cs = 0;
   // Enable the device, and all three channels
   _spi.write(0x47);
   //end transfer
   _cs = 1;
   wait(0.1);
   _cs = 0;
   // Send the command to read the WHOAMI register
   _spi.write(0x8F);
   // send a dummy byte to receive the contents of the WHOAMI register
   val = _spi.write(0x00);

	while(1) {
		myled = 1;
		wait(0.2);
		myled = 0;
		wait(0.2);
	}
}


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


UPDATE

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

  1. Поставить драйвера для stlink через zadig
  2. Поставить OpenOCD
  3. Поставить GCC тулкит
  4. Распаковать GDB с поддержкой arm и python тот же архив прикреплён к этой статье
  5. Настроить QtCreator как описано в статье порт для gdb указывать 3333
  6. Запустить openocd
    openocd-0.8.0.exe -f ..\scripts\board\stm32f4discovery.cfg
  • +13
  • 04 мая 2014, 10:55
  • ihanick
  • 1
Файлы в топике: qtcreator-gdb-7.7-mingw32_nt-6.1-i686.zip

Комментарии (152)

RSS свернуть / развернуть
Люто плюсую! Еще сам не понял до конца что тут произошло=)) А с какой оси все это делали? и можно ли под линуксом так сделать?
0
это 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
+1
И таким вот образом можно под любой камешек сделать? хоть PIC хоть MSP? пардон за нубство=))
0
Сборка и редактирования кода будет работать и с другими gcc платформами.
Отладка, только если jtag/bdm поддерживают remote gdb.
Из не-gcc ещё будет работать clang. Коммерческие компиляторы я не могу проверить, скорее всего не будут работать из-за другого формата вывода ошибок компиляции. Т.е. что-то может и будет работать но полной поддержки разработки не получить.
0
А без пятых Qt будет работать? Очень не хочу 2 версии Qt в системе держать.
0
Я использую Qt с официального сайта проекта. Средства для каждой платформы разработки находятся рядом в отдельных местах, мне важна воспроизводимость компиляции, поэтому пакетные менеджеры + автоматические обновления не самый удобный вариант.
Если вы делаете похожим способом, то не важно какое Qt стоит в системе, сборка от qt-project будет всегда содержать все необходимые библиотеки где-то внутри /home/user/Devel
0
Нет, мне важна воспроизводимость компиляции у пользователей, поэтому такой вариант не подойдёт :)
0
так, как минимум arm-none-eabi-gcc будет всегда самосборный или установленный в хомяк, всё равно в том или ином виде такая же ситуация. У пользователей как раз будут те же файлы с точностью до байта в отличии от дистрибутивных пакетов.
0
ihanick Напишите, пожалуйста, подробнее про мотивацию — зачем это надо. Понятно, что у вас в голове все разложилось по полочкам, вы понимаете зачем это надо.
Я сейчас пишу под десктоп на Qt, но иногда требуется что-то пописать для STM32, поэтому то, что вы пишите очень интересно.
Насколько я понял, вы предложили альтернативный набор инструментов для разработки ПО под STM32.
Хорошая IDE (Qt Creator) — чем лучше чем Keil, Eclipse? (C IAR все понятно, там блокнот)
«Взрослый» отладчик — лучше чем ...?
0
Автор работает в макоси => кайло в топку.
Эклипс тормозит и ждать по 2 секунды выпадения мень автодополнений расстраивает.
Взрослый отладчик — лучше, чем блокнот и vim+gcc.
Как по мне, если возникают вопросы про мотивацию — топик предназначен не вам.
0
Я работаю в linux (ubuntu,fedora,centos) иногда в os x и windows, в основном использую vim + gcc (makefile или cmake) + gdb. Но последние несколько месяцев QtCreator подкупает меня быстротой работы и хорошей поддержкой vim режима, причём от версии к версии они улучшают как поддержку C и C++ так и поддержку Vim.
0
вы предложили альтернативный набор инструментов для разработки
Это вольный перевод доклада с FOSDEM. Не все владеют английским и следят за новинками в сфере компиляторов и ide.
Хорошая IDE (Qt Creator) — чем лучше чем Keil, Eclipse?

Для меня:
— быстрый
— простые горячие клавиши
— хорошая эмуляция vim
— я пишу один код который работает (в тестах и симуляциях) на компьютере и контроллере
— файлы проекта не привязаны к ide => я могу мигрировать на другой контроллер с другой архитектурой
— я не готов на хобби тратить несколько тычяч долларов на IDE получая в нагрузку редко используемый (в сравнении с gcc) компилятор, несовместимый с gcc.
0
А есть возможность сравнить с code::blocks? Я к нему достаточно сильно привык, однако creator все очень нахваливают.
0
code::blocks в сравнении со свежими QtCreator
— сложный (много меню, тулбаров)
— медленный (залипает на несколько секунд)
— нулевая поддержка макросов в С
— нестабильный (аварийное завершение на полу-пустом файле)
— не нашёл поддержки редактирования как в Vim
— не работает со сборочной системой напрямую, нужны файлы проектов
+ есть довольно много расширений
+ есть шаблоны проекта для AVR
+ есть поддержка языков отличных от C/C++
+ Если я правильно понял, то есть поддежка wxWidgets

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

Sublime это просто текстовый редактор, но очень гибкий. Есть опыт подключения к нему компилятора? Я бы хотел использовать его для программирования, чтобы нажал кнопку и скомпилировал. А еще круто отладчик прикрутить.
0
Даже во втором есть проекты, в третьем ещё лучше. Через сборочные системы можно настроить работу с make/cmake. Дебагер
0
А как у его с автодополнением, подсказками, поиском определения и прочей кодонавигацией?
0
— с автодополнением
может, с clang на отлично, с ctags как везде
— с поиском определения
может (ctrl+r вроде)
— есть плагины, чтобы тултипы показывать с документацией на функцию

www.henriquebarroso.com/my-top-10sublime-2-plugins/
0
очень интересно, спасибо. не работает ссылка на код проекта.
0
Прошу прощения, поправил ссылку. Оказывается gitorious в отличии от github имеет разные url для репозитория git и html страницы с описанием
0
А можно для ленивых приложить уже собранный GDB с питоном под винду?
0
  • avatar
  • Vga
  • 04 мая 2014, 18:40
постараюсь сделать полную сборку для разработки после длинных выходных.
0
И еще, где слить mbed? С полпинка не нашел.
0
Официальный
Ещё есть свежак

Ну или прямо из этого поста код использовать
0
Круто, давно хотел прикрутить discovery к mbed. Я так понимаю к online никак а вот оффланй версии, вы как раз и продемонстрировали. Ну меня мучает один вопрос, где можно глянуть pinmap discovery к mbed, судя по вашему примеру spi.
0
Планировать какие пины как использовать удобно в STM32CubeMX (искать на сайте st.com).
Подключенную переферию (как из примера) можно посмотреть в схеме платы, ноги все названы как в документации на чип, только через подчёркивание (PA_0).

Полный список: mbed-for-baremetal-qtcreator/mbed-src/targets/hal/TARGET_STM/TARGET_STM32F4DISCOVERY/PinNames.h
0
ноги все названы как в документации на чип
вот это самое главное, спс.
0
GDB с питоном под винду
Прикрепил к статье, добавил ссылок на остальные компоненты.
Проверил на Windows 7 — работает.
0
Большое спасибо автору за эту тему! В своё время ещё на версии креатора кажется 1.2.х пытался использовать его как IDE для МК, и даже что-то получалось. Недавно попробовал это на последних версиях креатора — никак: требует правильный qmake и т.п.
Думал я один такой извращенец, потому забил))
Теперь попробую по вашему рецепту! Ещё раз спасибо!
Остальным же напоминаю что скоро обновится openocd до версии 0.8.0, пока же можно тестировать релизкандидаты, в т.ч. для отечественных 1986ВЕ =)
0
А шо с лицензией?
0
Для mbed Apache 2.0: распространять 2 файла и использовать код без ограничений (только переименовывать mbed во что-то ещё — нельзя).
Под QtCreator LGPL — код написанный в нём можно выпускать использовать под любой удобной лицензией. Если нужна сборка, например для своих контроллеров, то все фишки можно сделать в виде отдельного плагина.
На StdPeriph cmsis (своя лицензия от ST) тоже позволяет писать как коммерческий так и open source код
0
А сам Qt не принадлежит разве нокии?
и за его коммерческое использование не надо разве платить?
0
Qt принадлежит Digia.

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

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

Эти нюансы важны только если у вас есть коммерческое графическое приложение с использованием Qt под Linux/Windows/OS X/iOS/Android.
0
А как настроить запуск gdb, загрузку прошивки и отладку без использования Qbs?
С тем же Bare Metal, но без Debug -> Start Debugging -> Attach to Remote Debug Server?
0
Debug/Start Debugging/Attach to remote GDB server
подключение к удалённому gdb серверу в QtCreator

Можно использовать cmake вместо Qbs. Или по-старинке генерировать список файлов для проекта Qt
0
надо только ещё добавить
monitor reset halt
load полный_путь_к_elf
monitor reset halt
в файл (Server start script).

Как я понимаю это делает ненужным baremetal
0
Не выходит почему-то…

Qt Creator 3.0.1, Qt 5.2.1.
GDB 7.7 собран с поддержкой Python:
(gdb) python print "test"
test
(gdb) quit


При Attach to Remote Debug Server нет никакой реакции на содержимое Server Start Script. Вывод OpenOCD такой:
accepting 'gdb' connection from 3333
acknowledgment received, but no packet pending
dropped 'gdb' connection


Если вручную выполнить в этом gdb
monitor reset halt
load полный_путь_к_elf
monitor reset halt

вывод будет такой:
accepting 'gdb' connection from 3333
acknowledgment received, but no packet pending
JTAG tap: stm32.cpu tap/device found: 0x3ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x3)
JTAG tap: stm32.bs tap/device found: 0x06414041 (mfg: 0x020, part: 0x6414, ver: 0x0)
target state: halted
target halted due to debug-request, current mode: Thread 
xPSR: 0x01000000 pc: 0x0802594c msp: 0x20010000
JTAG tap: stm32.cpu tap/device found: 0x3ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x3)
JTAG tap: stm32.bs tap/device found: 0x06414041 (mfg: 0x020, part: 0x6414, ver: 0x0)
target state: halted
target halted due to debug-request, current mode: Thread 
xPSR: 0x01000000 pc: 0x0802594c msp: 0x20010000
dropped 'gdb' connection


Был такой баг «gdb startup script» field is not used when attaching to a remote gdb server, но здесь python включен и ошибок таких не выдаёт.
0
можно через командную строку (поле Command Line arguments)
-ex 'monitor reset halt' -ex 'load полный_путь_к.elf' -ex 'monitor reset halt'
0
Спасибо, но увы, не помогает.
Ни -ex, ни -iex, ни -x, ни -ix. Иногда в логе openocd заметно, будто «monitor reset halt» всё-таки выполняется, но очень редко.
0
Рылся в исходниках, так и не понял, как на stm32 заработает этот код:

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

Кстати, у кого-нибудь есть Makefile для mbed? Что-то у меня qbs не завёлся ((
0
USBTX, USBRX — должны быть ножки на которых у контролера выведен USART.
Например, для моей платы — STM32F4Discovery, это USART2 (ноги PA_2(tx) и PA_3(rx))

Тем более, на Нуклео нативный УСБ вообще наружу не выведен, как я понял.
mbed поддерживает 4 платы Discovery и 4 плат nucleo.
Посмотрите определения дефайнов USBTX, USBRX для вашего таргета в mbed, сверьтесь со схемой.

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

Кстати, у кого-нибудь есть Makefile для mbed? Что-то у меня qbs не завёлся ((
Для моей платы: gist.github.com/oampo/7096700
0
Понятно. Я, если честно, думал, что в такой нотации в качестве последовательного порта незаметно подставляется USBSerial.
0
Только у меня падает 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).
0
а какие версии? 32 или 64 битный qt?
Например «Qt 5.3.1 for Windows 32-bit (MinGW 4.8.2, OpenGL, 735 MB)»?
если mingw я могу посмотреть почему падает, если MSVS — не могу.
0
Да, MinGW 32-bit.
0
Та же фигня, падает при попытке отладки.
Все загружает нормально, пытаешься точку останова поставить, или на кнопки стоп/пауза нажать, креатор падает.
Версия -> Qt 5.3.1 for Windows 32-bit (MinGW 4.8.2, OpenGL, 735 M)
qt creator ver
0
Это ж опенсорс, дебаггер в зубы и отлаживай)
Официальный багтрекер тыкал?
0
потестировал на XP, там работает как часы.
stm32f4 discovery QtCreator, windows xp
0
аналогично для windows 7 64bit

STM32F4Discovery mbed QtCreator, windows 7

Попробуйте:
— использовать короткие пути для проекта
— на 64битной win надо использовать 64битный openocd
— родные драйвера к stlink не должны быть установлены, только драйвера поставленные через Zadig для stlink
— в архиве несколько gdb, нужный: qtcreator-gdb-7.7-mingw32_nt-6.1-i686\gdb-arm-none-eabi.exe
— gcc я брал с лаунчпада, exe поставил по дефолтным путям
0
Сделал все как сказали,
— Пути короче некуда
— Скачал отсюда последний 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/
monitor reset halt
monitor sleep 100
monitor wait_halt 2
monitor flash write_image erase c:/testmbed-build/qtc_mbedcpp-debug/testmbed.elf
monitor sleep 100
monitor verify_image c:/testmbed-build/qtc_mbedcpp-debug/testmbed.elf
monitor sleep 100
monitor reset halt
thbreak main

В общем что то вероятно у меня еще не так. Уже и Path весь почистил, и не знаю что еще ковырять.
0
у меня:
— С Zadig'ом WinUSB (дефолт)
— openocd OpenOCD 0.8.0 c того же сайта
— openocd запускаю из корня его директории
bin-x64/openocd-x64.exe -f полный/путь/к/scripts/boards/stm32f4discovery.cfg
— команды монитора только те что на скриншотах, команда load сама загружает elf, слипы не добавлял.
0
В итоге, таки, разобрался!
А дело то было всего в одной галке!
Qt Creator -> Инструменты -> Параметры -> Отладчик -> GDB, расширенные -> Использовать асинхронный режим для работы с программой.
Нужно поставить эту галку, и креатор не будет вылетать при отладке! =)
0
Вот, спасибо. Сам бы еще ковырялся долго. Жаль, что «Срок голосования за комментарий истёк»
Автор, отметь этот момент в статье. Те кто будут идти этим путём поблагодарят.
0
я могу добавить, всё что сейчас есть в коментах полезного.
Проблема: статья старая и снова всплывёт как новая в ленте
0
Полагаю немало тех, кто прочитал, но с первого раза не получилось, и забили. Может теперь получится.
Комментов очень много, хорошо бы выжать квинтэссенцию. На память себе и «грядущим поколениям» :)
0
статья старая и снова всплывёт как новая в ленте
При изменении заголовка статьи, она всплывёт в RSS-ленте вместе со всеми комментариями. А если измените сам текст, то не должна.
0
Никто не заметил, но в «Добавляем кит» у вас неверный скриншот )

А как создавать новый проект? Он даже не показывает добавленный кит в «C project» и так далее.
0
  • avatar
  • vk2
  • 12 июля 2014, 14:12
> А как создавать новый проект?
New Project => Non-Qt Project => Plain C Project (Qbs Build)
Создали пустой проект.
Открываем Вкладку Projects из левой колонки
Add kit => ваш кит (у меня stm32)
Если кита ещё нет, тогда надо идти в Manage Kits и делать его.

Выбор кита при создании проекта происходит если выбрать просто C project, т.к. qmake. Я не знаю, можно ли qmake использовать для кросплатформенной сборки. Даже если можно, этот пост не имеет к qmake никакого отношения.
0
Я считаю использование QBS нерациональным, поскольку:
1) оно поддерживается только Qt Creator
2) использует Java Script
3) это очередная система сборки без видимых плюсов
0
никак не могу собрать gdb с питоном под osx
не могли бы вы поделиться бинарниками(было бы супер) или более подробной инструкцией по компилированию
0
у меня сейчас только 10.10 под рукой и там всё сложно с питонами: qt-creator работает с систеный, при сборке gdb скриптами из исходников qt-creator используется ещё один питон. Всё усугубляется тем что в ратнайме получается дикая смесь из .so файлов в питоновский модулях.

я попробовал запустить gdb собранный для системного питона, он работает как gdb, но чтобы заработало в креаторе надо разобратья какие библиотеки питона и откуда должны подгружаться.
0
так и понял что на 10.10 все сложней. Придется делать из под винды. Надеюсь у Вас получиться и мы увидем это в новой статье)
0
qt-creator-opensource-src-3.2.2.tar.gz

Внутри 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
0
если brew уже установлен и туда установлен питон, то перед сборкой надо убрать brew окружение из путей:
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
0
./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, поможет?
0
В архив файлы питоновские из дистрибутива gdb не попадали:
qtcreator-gdb-7.8-darwin-x86_64.tar.gz

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

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


echo $PATH
/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/opt/X11/bin:/usr/local/go/bin
~/devel/qtcreator-gdb-7.8-darwin-x86_64$ ./gdb-arm-none-eabi.sh 
GNU gdb (GDB) 7.8
Copyright (C) 2014 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "--host=x86_64-apple-darwin14.0.0 --target=arm-none-eabi".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word".
(gdb) python print("Hello")
Hello
(gdb) python import gdb
(gdb) python gdb.execute('file /Users/ihanick/src/build-mbed-GCC_ARM_kit-Debug/qtc_GCC_ARM_kit-debug/mbed.qtc_GCC_ARM_kit/mbed'
)
(gdb) python o = gdb.execute('disassemble exit', to_string=True)
(gdb) python print o
Dump of assembler code for function exit:
   0x0800c4f4 <+0>:     push    {r3, lr}
   0x0800c4f6 <+2>:     ldr     r3, [pc, #28]   ; (0x800c514 <exit+32>)
   0x0800c4f8 <+4>:     mov     r4, r0
   ...
0
да кажется работает, огромное спасибо Вам!!!

у меня плата дискавери с 429 камнем, я так понял у mbed нет для нее поддержки. буду искать способ прикрутить проект из cubeFx
0
Вдруг поможет, чтобы не с нуля делать:
Это пример для 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

Светодиод будет на другой ножке:
HAL_GPIO_WritePin(GPIOG, GPIO_PIN_13, GPIO_PIN_SET);
      HAL_Delay(50);
      HAL_GPIO_WritePin(GPIOG, GPIO_PIN_13, GPIO_PIN_RESET);
      HAL_Delay(50);
0
в вашем .qbs заменил дефайн на 429, а также подсунул свой startup_stm32f429xx.s, отладчик все работает
но "-T"+path+"/Projects/TrueSTUDIO/cubeblink\ Configuration/STM32F407VG_FLASH.ld", такого мне cubeMX не положил, поэтому оставил Ваш.

почему-то GPIOG, GPIO_PIN_13 НЕ мигает(
0
скрипт линковщика лежит в Projects/TrueSTUDIO/название проекта Configuration
STM32F429ZI_FLASH.ld

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

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

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

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

в эклипсе есть проект, который успешно работает, только там на таймере завязано моргание
0
короче спать надо идти уже просто) в файле gpio.с банк G не описан был, вот и не мигало)
Спасибо Вам большое за помощь, так не хотелось изучать стм32 из под винды или эклипса.
0
мож кому пригодиться, почистил, убрал лишнее проект для disco_f429
0
Может у вас найдется еще время мне немного помочь? Заранее спасибо!

Пытаюсь провернуть тоже самое с 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

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

Product {
    type: "application"
    Depends { name:"cpp" }
    property string haldrv: "Drivers/SPL/"
    cpp.defines: ["STM32F103C8=1", "STM32F10X_MD=1", "USE_STDPERIPH_DRIVER=1", "USE_FULL_ASSERT=1"]
    cpp.positionIndependentCode: false
    cpp.debugInformation: true

    cpp.commonCompilerFlags: [
        "-mthumb",
        "-mcpu=cortex-m3",
        "-mfloat-abi=soft",
        "-fno-strict-aliasing",
        "-std=gnu99",
        "-O2",
    ]
    cpp.linkerFlags:[
        "-mthumb",
        "-mcpu=cortex-m3",
        "-mfloat-abi=soft",
        "-fno-strict-aliasing",
        "-Wl,--start-group",
        "-lc",
        "-lm",
        "-Wl,--end-group",
        "-static",
        "-Wl,-cref,-u,Reset_Handler",
        "-Wl,-Map="+path+"/cubieblink.map",
        "-Wl,--gc-sections",
        "-Wl,--defsym=malloc_getpagesize_P=0x1000",
         path+"/Drivers/startup_stm32f10x_md.S"
    ]


    cpp.linkerScripts: [
        path+"/Drivers/stm32f103c8_flash.ld",
    ]

    cpp.includePaths: [
    "Drivers/CMSIS",
    "Drivers/SPL/Inc",
    "Inc"
    ]
    files: [
        "Drivers/system_stm32f10x.c",
        haldrv+"Inc/*.h",
        haldrv+"Src/*.c",
        "Inc/*.h",
        "Src/*.c"
    ]
    Properties {
        condition: qbs.buildVariant === "debug"
        cpp.defines: outer.concat(["DEBUG=1"])
    }
    Group {
        qbs.install: true
        fileTagsFilter: "application"
    }
}


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



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



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

Надо определить _exit в любом сишном файле:
void _exit(int status) { for(;;); }
0
Вы правы, это помогло, но я тут разобрался наконец. Нашел в STM32F10x_StdPeriph_Driver флэш скрипт(только поправил в нем размер flash с 128 на 64кб) и заработало со стартап файлом оттуда же без нужны в определении _exit

Вот проект, мож кому пригодиться. Я не уверен во всех флагах компилятора и линковщика, но пока вроде работает)
cubeblink_f103.zip
0
не понимаю чему радуетесь. писать под микроконтроллер под си++ можно но нежелательно. или асемблер или чистый си… или за стабильность работы вашего изделия на совести компилятора…
-1
mbed, он просто, для примера взят. Другой пример в обсуждении написан на C и использует новый hal от ST.
CubeMX HAL

Т.е. это статья про настройку IDE для C++ или для C.
Можно без библиотеки от ST запуститься, но у меня таких проектов нет. Я люблю начинать с работающего примера для периферии, а usb или ethernet на голых регистрах — это много потерянного времени.
0
писать под микроконтроллер под си++ можно но нежелательно. или асемблер или чистый си…
C чего вы это взяли?
или за стабильность работы вашего изделия на совести компилятора…
А если на Си писать, то компилятор стабильность гарантирует?
+2
Не порите чушь, ей больно.
0
Повторяешься
+1
Поговорка на то и поговорка, что бы повторяться. К тому же эта тема всплывает регулярно — прибегает очередной пионер с горящими глазами и начинает кричать, что во всем виноват ООП, Java отстой, а С++ не годится для embedded (я сознательно смешал их в кучу, в моем понимании это вещи одного пошиба и вызваны одними и теми же причинами).
0
я говорил нежелательно имея ввиду работы с объектами…
с ООП код читабельней..(но ООП я ни разу в ассемблере не видел).
а проверять пока времени нет.
я все-таки за ассемблер край си.
0
Обычный (без виртуальных методов) объект в С++ ничем не отличается от структура + набор функций для работы с ней в С. То есть абсолютно ничем.
+1
я понимаю про что вы… могу конечно ошибаться но у обектов должен быть конструктор и деструктор.
и на сколько понимаю для статических объектов он тоже вызывается.
дак вот на сколько хорошо деструктор прибирается за объектом и зависит будет утечка или нет…
я считаю что риск для микроконтроллеров неприемлем.
0
Не порите чушь, ей больно.
0
ок
0
Вы сильно ошибаетесь. И касательно конструкторов и деструкторов.

Деструктор опционален. Это специальный метод, который (если он присутствует) будет вызван до уничтожения объекта (на самом деле будет вызвана цепочка деструкторов в случае наследования).
Этот метод нужен программисту, для того, что-бы он мог освободить ресурсы, которые захватил или выделил объект. Ели я, например, в конструкторе явно выделил буфер в куче – я должен в деструкторе эту память явно освободить. Соответственно, ели объект не выделяет никаких ресурсов (а в случае МК – динамическое выделение памяти практически не используется), то деструктор такому объекту не нужен.
дак вот на сколько хорошо деструктор прибирается за объектом и зависит будет утечка или нет…
Что значит «на сколько хорошо деструктор прибирается» деструктор (если он есть) делает ровно то, что написал программист. В жизненном цикле объекта нет никакой магии и неопределенности – все четко детерминировано и все зависти только от автора кода.
+1
я с вами полностью согласен но бывают чудеса link
0
Бегло посмотрел статью по ссылке. В первом случае – баг в компиляторе, во втором – бросили исключение из конструктора, в третьем особенности диспетчера памяти Solaris.

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

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

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

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

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

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

При желании вполне можно добиться того, что код на классах в С++ будет не менее оптимален, чем на С (а то и более — по некоторым наблюдениям, GCC несколько лучше компилирует в режиме С++, даже если скормить ему чисто сишный код) — если это нужно (да, оптимальность кода — далеко не единственная цель, которая может ставиться перед программой).
+1
2. объекты в одном экземпляре не имеют смысла тк в количестве кода нет выигрыша.
Имеет. Инкапсуляция позволяет сделать код более структурированным, более удобным для использования и более безлопастным (в т. Ч. За счет возможности ограничения доступа к полям класса извне).
3.несколько копий объекта в малым количеством оперативки также смысла не имеет.
Что значит не имеет? Ели вам, например, нужно 3 объекта, которые реализуют FIFO буфер – вполне логично создать 3 экземпляра объекта.
4. на небольших проектах и на проектах с малыми ресурсами (коими являются микроконтроллеры) использование ооп неоправдано…

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

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

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

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

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

По моему глубокому личному убеждению, проблемы нужно решать по мере их возникновения. Писать программы на вырост с избыточным универсализмом нужно лишь очень хорошо предварительно подумав, ибо это из серии «Почему сегодня не делают корабли, летающие к звёздам?» Ответ прост: потому что корабль, построенный завтра, прибудет быстрее, а корабль, построенный послезавтра, еще быстрее. И их обоих обгонит корабль, построенный лет через пятьдесят, но когда он вернётся обратно, то обнаружит, что у человечества совсем другие проблемы».
Крис Касперски
+1
Это всё про 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
0
Это всё про C++98 с большой долей java программирования.
Насчет современного С++ не скажу, а к java это относится в куда меньшей степени.
0
Это скорее вопрос архитектурного подхода, от языка он не зависит. Скорее уж такое различие в подходах связано с различием задач, которые обычно решают на разных языках. С++-ник, вероятно, был из энтерпрайза — им действительно приходится закладываться на развитие в течение многих лет.

На мышление язык влияет, конечно, но ИМХО — не в этой области.
0
Это скорее вопрос архитектурного подхода, от языка он не зависит. Скорее уж такое различие в подходах связано с различием задач, которые обычно решают на разных языках. С++-ник, вероятно, был из энтерпрайза — им действительно приходится закладываться на развитие в течение многих лет.
«Закладки» в 80-90% случаев оказываются не использоваными. IMHO один из факторов приводящих к «тяге к универсальности» (помимо методики и языка программирования) является наличие средств автоматического рефакторинга в используемом инструментарии и навыков программистов в его использовании.
0
Язык, безусловно, накладывает отпечаток на подходы к дизайну. Но еще больший отпечаток накладывает используемая методика проектирования. Парадоксально, но факт: на java (которая позволяет относительно легко писать куда более «универсальные» решения, чем С++) с использованием agile методов пишутся «узкие» решения для конкретных задач, чем, как правило, на С++. Другими словами, тяга к универсальным решениям легко устраняется обучением и переходом к другим методам проектирования и дизайна.
0
Там опять же используется динамическая память для выделения места под объекты (что вполне типично для прикладных программ, но на МК этого обычно лучше избегать), плюс баги компилятора. Они и без классов прекрасно твою прошивку уронят — так, mikroPascal for 8051 v. 2.2 я так и не заставил генерить рабочий код.
Если не работать с динамической памятью (ака кучей) — течь она никуда не будет. А для работы с ООП в С++ куча совершенно не обязательна.
+1
я попробую ооп я обещал
0
(но ООП я ни разу в ассемблере не видел)
В ассемблере и функций нет, да и структурного программирования тоже.
Но как и функции, ООП на асме вполне можно делать ручками. В конце концов, именно в ассемблер транслятор и переводит код на объектно-ориентированном языке.
+1
Борладндовский TASM под DOS поддерживал написание программ в ОО стиле, вплоть до поддержки VMT. Ну и структурно на асме таки писать можно, хотя и требует определенной дисциплины.
0
В каком виде? Не в том, случаем, который ты же называл «закат солнца вручную»?
0
Сейчас я на вскидку деталей синтаксиса не помню, но помню, что там, как минимум поддерживалось объявление методов и, как я уже писал выше, VMT. Понятное дело, что, поскольку это асм, кишки торчали наружу даже больше, чем в С++.
0
Ну, это уже скорее макроассемблер. Это все же несколько другой язык.
0
Асм без макросов, IMHO, скорее исключение из правил, чем правило. Но тут немножко другое, поддержка на уровне компилятора. Впрочем, ты прав, это несколько другой язык. Примерно как классический паскаль vs турбо паскаль (и его потомки).
0
возьмем из этого источника
Обнаружение и локализация утечек памяти

возмем для примера хабр
Утечки памяти в программах на С/С++ — история нескольких багов

ну и википедия.
а когда пишешь на си то выделением памяти не пользоваться.
а при вызове функции и при возврате стек останется на старом месте.
также не советую пользоваться кучами…
и вообщем то это мое личное мнение
0
ну а почему я недолюбливаю с++ а точнее работа с классами. тк сложно отследить за компилятором как он выделяет и освобождает память под них. если быть крайне аккуратным то и тут проблем нет.
вообщем то и на ассемблере можно память терять и стек упустить или переполнить.
поэтому мой метод писать крайне аккуратно чтобы потом не отлавливать баги.
0
Как раз на ассемблере налажать проще всего.
Хотя надо отдать лолжное С и С++, в них это тоже очень просто.

Что до утечек — использовать динамическую память необязательно. Даже при работе с классами. Даже если эти классы не статические.
+3
а когда пишешь на си то выделением памяти не пользоваться.
Никто не заставляет использовать выделение памяти ни на Си, ни на Си++. Тем более в embedded. Не нужно — не используйте.
а при вызове функции и при возврате стек останется на старом месте.
А что на плюсах стек куда-то смещается? Или вы что-то другое имели в виду?
+2
я имею ввиду когда вы «рождаете» объект а потом его «убиваете» сложно уследить за компилятором (всмысле утечки памяти).
0
Что значит
сложно уследить за компилятором (всмысле утечки памяти).

За компиляторам следить не нужно, нужно следить за своим кодом (независомо от ЯП).

Но никто вас не заставляет использовать динамическое выделение, пишите на С++ без оного. Почему-то у многих стереотип: раз С++ то там сразу классы, динамическое выделение, виртуальные методы, исключения… Да никто не заставляет вас всем этим пользоваться на МК, вы можете выбирать то подмножество средств, которое вам необходимо в конкретном случае.
+1
ну и чем пользоваться вы посоветуете из средств с++ для микроконтроллеров… может я и вправду зря не пользуюсь
0
для МК надо использовать подмножество C++ в в большинстве ситуаций.

что можно вырезать чтобы получался жёсткий реалтайм:
— выделения памяти
— stl контейнеры
— исключения
— виртуальные функции

Что полезного:
— constexpr
— шаблоны (ограниченно, т.к. увеличивают размер бинарника)
— алгоритмы
— RAII

Из примеров библиотек: andybrown.me.uk/wk/2011/12/28/stm32plus-a-c-library-for-stm32-development/
автор демонстрирует бодрую работу с графикой на F4
+1
Для меня основной плюс С++ на МК это шаблоны (templates). Пространства имен и классы (классы, в подавляющем большинстве случаев, без виртуальных методов, часто полностью статические) позволяют структурировать код. Многие моменты из С++11 вполне актуальны для МК (от constexpr и вплоть до лямбд).

Чего я никогда не использовал – динамическое выделение памяти (хотя, возможно, и имеет смысл, но для очень специфических задач), RTTI и исключения. Все остальное вполне юзабельно, главное отдавать себе отчет – что ты делаешь и как это будет работать (будут ли накладные расходы и т. д.)
+1
ну и чем пользоваться вы посоветуете из средств с++ для микроконтроллеров…
Дык смотрим же на название топика — берем готовые ООП библиотеки mbed и просто решаем свои прикладные задачи, юзая готовые объекты и API, и даже возмомно и не заморачиваясь этим самым ООП (ООП для «дебилов» — структу́рное программи́рование с использованием уже готовых объектов из библиотеки). Кстати, в mbed (в отличии от Arduino) уже интегрирована поддержка RTOS со стандартным API для RTOS от ARM (описанным в CMSIS 3), т.е. что-то а-ля Keil RTX CMSIS-RTOS.
-1
+ уже весьма солидный список поддерживаемых mbed чипов от разных производителей.
-1
Вах, опять минус-минус! Вроде как опять некий ЙОбнутый помойный кiт вернул себя из самоизгнания и ссыт минусом под каждым моим постом без разбора — мстит видимо так :B
-1
я не против «библиотек»..(я говорил про объекты)
спасибо за шаблоны… присмотрюсь к ооп…
обычно если в чужих сырцах получаю объект… то выковыриваю от туда функции и переменные и использую стандартными методами.
да, согдасен, код получается менее читабельным..(да и писать сложнее)
вообщем то эта привычка была сформирована когда писал под MSP430F1122: 4 кБ + 256байт флэш-памяти (МКП*), 256 байт ОЗУ и… за стеком следить проще… данные какие на стек падают понятно… старался даже вложенными функциями не пользоваться…
железка работает исправно сутками… решение было верное…, для этого дебажил асемблер после компилятора иара который показал себя на высоте… опыта с ООП под микроконтроллеры не имею поэтому задал вопрос по методам с++ для embedded систем.
0
пока таких сложных задач не стояло… ртос посмотрел поигрался отложил… когда не смогу распаралелить процессы возьму ртос… а пока задача проста из прибора взял по одному протоколу компьютеру отдал по другому. все решается в цикле. если будет работа типа видеоплеера или тому подобных наверное ртос понадобится…
0
Кстати, в mbed (в отличии от Arduino) уже интегрирована поддержка RTOS со стандартным API для RTOS от ARM (описанным в CMSIS 3), т.е. что-то а-ля Keil RTX CMSIS-RTOS.
Собственно, судя по коду: именно Keil RTX CMSIS-RTOS 4.6 и прикручена.
-1
Эта дискуссия уже происходила неоднократно и всегда выяснялся один и тот же факт: те, кто считает, что «писать под микроконтроллер на С++ не желательно» просто не разбираются в предмете своей нелюбви.
0
на VC я пользуюсь объектами.
и вопрос ООП тут не стоит.
не великий специалист но я с вами не соглашусь и останусь при своем мнении.
а вам советую mbed. тем более скетчи от ардуино тут работают исправно.
0
а вам советую mbed.
Я как-нибудь без ваших советов обойдусь.
0
Возможно кто-то встретит такую проблему «Module cpp could not be loaded»
Ответ тут bugreports.qt-project.org/browse/QBS-709#comment-268006.
Modify a condition in the: qtcreator-3.2.82\share\qtcreator\qbs\share\qbs\modules\cpp\genericunix-gcc.qbs file, e.g. to:
UnixGCC {
    condition: qbs.targetOS.contains('windows') && qbs.toolchain.contains('gcc')
}
0
  • avatar
  • kyb
  • 12 декабря 2014, 16:27
Откомпилировалось.
— Вылетает во время отладки (иногда при изменении настроек). После вылета возникает ошибка
Cannot lock build graph file '.../qtc_STM32-release.bg': Already locked by 'qtcreator' (PID XXXX).
Помогает перезапуск через несколько минут, или смена Debug<->Release. UPD: Решение
— Необходим внешний запуск openOCD. Но это в принципе мелочи.
Win8x64 + LaunchPad GCC 4.9 2014q4 + QTCreator 3.3 + MinGW + openOCD 0.8.0
0
  • avatar
  • kyb
  • 13 декабря 2014, 19:33
Подскажите пожалуйста… столкнулся с такой проблемой:

Info: dropped 'gdb' connection
Info: accepting 'gdb' connection from 3333
Warn: acknowledgment received, but no packet pending
undefined debug reason 6 — target needs reset
Warn: The target is not in the halted nor running stated, stepi/continue ignored.

Отладка вроде запустилась но постоянна выдает:

$ openocd -f board/stm32f0discovery.cfg
Open On-Chip Debugger 0.7.0 (2013-10-22-08:31)
Licensed under GNU GPL v2
For bug reports, read
openocd.sourceforge.net/doc/doxygen/bugs.html
srst_only separate srst_nogate srst_open_drain connect_deassert_srst
Info: This adapter doesn't support configurable speed
Info: STLINK v2 JTAG v16 API v2 SWIM v0 VID 0x0483 PID 0x3748
Info: Target voltage: 2.909481
Info: stm32f0x.cpu: hardware has 4 breakpoints, 2 watchpoints
Info: accepting 'gdb' connection from 3333
Info: device id = 0x20006440
Info: flash size = 64kbytes
Warn: acknowledgment received, but no packet pending
undefined debug reason 6 — target needs reset
Warn: The target is not in the halted nor running stated, stepi/continue ignored.
Warn: The target is not in the halted nor running stated, stepi/continue ignored.
Warn: The target is not in the halted nor running stated, stepi/continue ignored.
Warn: The target is not in the halted nor running stated, stepi/continue ignored.
Warn: The target is not in the halted nor running stated, stepi/continue ignored.
Warn: The target is not in the halted nor running stated, stepi/continue ignored.
0
У меня к сожалению нет этой платы, но вы можете попробовать параметры запуска openocd из: www.fussylogic.co.uk/blog/?p=994
0
спасибо что откликнулись.
ошибка не ушла… Qt Creator не может нормально общаться с OpenOCD,
кто сталкивался с такой проблемой? Может у меня версия Qt Creator'а не та ?
Основан на Qt 5.4.0 (GCC 4.6.1, 64 бита)
Собран Dec 8 2014 в 15:21:39
Отпишитесь пожалуйста.
0
Автору спасибо за публикацию! В качестве ОС — Windows. QtCreator 3.4.2.
При сборке проекта в окошко выводится:
"...compiling timers.c
compiling stm32f4xx_tim.c
linking stm32_test_001
18:32:12: Прошло времени: 00:15."
Есть ли опция у линковщика и компилятора, чтобы выводился на экран размер бинарника, размеры секций?
В Кокосе по умолчанию выводится.
0
можно добавить в custom build steps arm-none-eabi-size
Показывает такое:
arm-none-eabi-size out.elf
   text	   data	    bss	    dec	    hex	filename
   5708	   1080	   1380	   8168	   1fe8	out.elf


Но сейчас для STM32 я бы советовал www.openstm32.org/System+Workbench+for+STM32
Эта штука на базе эклипса, отлично работает с CubeMX. Который между тем после небольшого допила очень даже ничего. Из последнего у меня наконец-то нормально заработал USB CDC (ком порт через usb).
0
Обновил QtCreator до версии 3.5.0. Вылезла ошибка
The process 'D:\Micro\arm_gcc\bin\gcc' could not be started: Не удалось запустить процесс: No such file or directory.
. Путь должен быть D:\Micro\arm_gcc\arm-none-eabi\bin\gcc. Я так понял, что ошибка в Qbs. Фиксов в интернете пока не нашёл. Никто не сталкивался с проблемой и решением?
0
Пока вылечил установкой QtCreator 3.4.2
0
у gcc две директории: одна без префиксов и компилятор вызывается как gcc, вторая (которая просто bin) arm-none-eabi-gcc, скорее всего при переустановке был или другая директория или другой файл компилятора (с префиксом)
0
Переустанавливался QtCreator. GCC нет.
0
Тоже столкнулся с этой проблемой. Попробуй добавить в 'CppApplication' такую строку 'cpp.executableSuffix: ".exe"'. Мне помогло. Пробовал на последнем снапшоте 3.5.1.
0
Есть один минус — результат работы линкера тоже будет с расширением '.exe'. Поставил еще один костыль — добавил переименование на '.elf' в скрипте, который размер выводит после сборки. Вообще такие баги не радуют, получается сделали зависимыми расширения исполняемых файлов где-то. Проявляется скорее всего только на кросскомпилере.
0
У тебя еще почему-то toolchainPrefix сломан. Должно быть как на скриншоте.
0
Кто знает Qt Creator, подскажите пожалуйста. В общем, задача такая. Есть проект IAR STM8 — соответсвенно исходники и файл проекта project.ewp.
Хочу написание кода и заливку в мк делать из Qt. Ну а к IAR возвращаться лишь в случае необходимости отладки.

Написал и положил в папке с проектом простенький QBS, где собрал исходники.
Project{
    Product {
        type: "application"

        Group {
            name: "Application"
            prefix: "*/"
            files: [
                "*.c",
                "*.cpp",
                "*.h",
                "*.s"
            ]
        }

        Group {
            name: "SPL"
            prefix: "lib/SPL/**/"
            files: [
                "*.c",
                "*.cpp",
                "*.h",
                "*.s"
            ]
        }
    }
}


Теперь непонятки:
1) Нужно чтобы по нажатию на «молоточек»(сборка) выполнялся код сборки IAR проекта:
C:\Program Files (x86)\IAR Systems\Embedded Workbench 7.0\common\bin\iarbuild.exe project.ewp Debug -log all


2) А по нажатию на «стрелочку»(отладка) выполнялась заливка прошивки в мк:
C:\Program Files (x86)\STMicroelectronics\st_toolset\stvp\stvp_cmdline -BoardName=ST-LINK -PORT=USB -ProgMode=SWIM -Device=STM8L15xK6 -verif -verbose -no_loop -FileProg=C:\dev\project\Debug\Exe\project.hex


Как лучше это организовать? Средствами QBS достижимо?
0
Это можно сделать в закладке Projects.
1-я строчка вписывается в разделе Build Settings.
2-a — Run Settings.
0
При наличии проекта в IAR и использовании iarbuild может быть не стоит заморачиваться с QBS? Тогда можно завести в QT creator обобщенный проект (Создать проект -> импорт существущего проекта). Вкладка Проекты в таком случае будет выглядть так:
Загрузку прошивки я прописал во внешних утилитах.
На QBS имеет смысл собирать проект используя только компилятор и линкер.
0
А из чего у тебя комплект ewstm8 состоит?
0
В комплекте прописан только компилер, в компилере как-то так:
Если что, шаблон парсера ошибок в текстовом виде: ([][{} \t#%$~A-Za-z0-9_:+/\.-\\]+)\(([0-9]+)\): (.*)$
0
Благодарю, получилось. А QBS я использую в данном случае больше из эстетических соображений — чтобы исходники по группам легко и непринужденно рассовываать)
0
Кстати, на шаблон ругается. Говорит что неприменим к сообщению об ошибке.
0
Шаблон можно применить только на реальной строке из лога иара.
0
Только зарегистрированные и авторизованные пользователи могут оставлять комментарии.