Pull to refresh

Comments 45

mbed - не имеет ограничений и бесплатна.

для тех же STM и "кубик" то бесплатен со средой.

хотя в целом, что такого дает Qt, без чего трудно будет в микроконтроллере? Code Lite тоже open source, тоже можно подцепить внешний компилятор. Только более легкая по сравнению с тем Qt, особенно если последний используется только как редактор кода.

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

Вы не правы. Уже очень давно есть mbed cli. Год назад уже тосно была mbed ide на основе электрона. Плюс можно использовать все библиотеки через PlatformIO. ЕМНИП, кажется начали деприкейтить Web ide

Это вполне сбе десктопная IDE.

Если не затруднит, киньте ссылку где можно найти рабочий релиз локальной GUI mbed ide на основе электрона. Электрон понятно по удобству не Qt, но все равно любопытно попробовать.

К сожалению, сайт mbed заблокирован для России, не мог туда попасть. Но при этом обновления для IDE проходят.

Давно уже есть оффлайн версия IDE

Спасибо за статью, но
Возвращаемся в Kits и донастраиваем наш комплект. Выбираем Device type и Device – Bar Metal Device. Применяем.

QtCreator не очень дружит с Makefiles. 


Ушел много лет назад от креатора на vscode так как очень неудобно реализован процесс переносимости. В vscode достаточно плагинов cortex-debug и settings-sync для полноценной работы с cmake makefile проектами STM32 на другой машине. Все настройки для отладки и прошивки как есть хранятся в директории проекта.
В креаторе же надо было ручками заводить таргеты или копировать файлы из системной директории, я так понял в этом плане не поменялось ничего?
Ну хоть поддержка svd появилась, это хорошо!

Наверное для тех кто и так кодит декстоп проекты в креаторе это имеет смысл, ну и у кого не очень новый пк, ибо vscode иногда очень аппетитный к ресурсам.

Столько возни ради блинка светодиода.. На avr и ассемблере программа блинк занимала несколько десятков байт.

Блинк светодиода - это всего лишь пример. Вместо блинка тут может быть любой другой код, как asm, так и C и С++.

Может быть Вы еще запилите подобный мануал для подключения Qt DesignStudio к STM32 ?

А зачем, если есть официальное решение от qt? https://www.qt.io/product/develop-software-microcontrollers-mcu

на youtube можно даже найти ролики, где показывают производительность системы.

те же st предлагают touch gfx, который и дизайнер, и код на с++, и заточек по stm32 более чем. и зачем тогда дизайнер?

Design Studio как раз интересное решение от Qt для GUI. И в нём есть свои плюшки. Тачдизайнер есть, но не одним софтом то жить. У них есть довольно симпатичные решения.

а объем кода какой будет на выходе? Для большого ПК или микрокомпьютера на линуксе вполне себе удобное решение, куда он видимо и заточен.

Но вот для МК (что-то типовое: до 100 МГц, 1 - 2 МБ ПЗУ, 256 - 512 кБ ОЗУ) с учетом что память нужно будет по другие полезные задачи, точно применимо будет?

Я бы даже немного сузил рамки интереса - 128-512 КБ ПЗУ и 64-192 КБ ОЗУ.

Скачай IAR for ARM с торрента и прекрати ненужные извращения. Удивительно стремление людей усложнять себе жизнь.Твой метод-для изощрённых извращенцев.

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

И цель данной статьи была именно в настройке QtCreator - IDE, к которой привык и постоянно пользуюсь.

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

Для программирования МК хорошо подходит сборочная система Qbs. Хотя, на крайний случай, можно извратиться и с CMake.

Еще в QtC есть поддержка кейловского отладчика, т.е можно использовать KEIL и для сборки и для отладки в самом QtC.

Я хотел в QtC добавить и поддержку отладчика CSpy из IAREW, но это желание как то пропало после их реакции на известные события.

Кроме того, GDB отладка в QtC, требует наличия питона v2.x, а также условия чтобы сам GDB, был собран с поддержкой питона, что не во всех ARM тулчейнах сделано. Это минус у QtC, я считаю, что нельзя без питона.

Там был еще казус, в том, что они хотели дропнуть питон 2x и заменить на 3x. Я им говорил, что тогда половина bare-metal тулчейнов сразу отвалится. Те не поверили, дропнули, но у них провалился их плагин McuSupport и они откатили взад это как было. Смех и грех в общем.

А сейчас тоже, вот, присматриаюсь к VSCode, т.к. там завезли плагин отладки для IAR, для отладчика CSpy. Т.е. можно взять любимую систему сборки Qbs, или CMake и все делать из VSCode.

GDB, плагин для VSCode, был уже сто лет как. Возможно для полного комплекта подумаю, а не добавить ли туда плагин и для отладки KEIL овским отладчиком. ))

В общем, для меня VSCode, выглядит более заманчиво.

У меня IAR компиляторы добавлены в path и по умолчанию обнаруживаются в QtCreator. Думаю, если кейловские добавить в path, то их наверно тоже можно будет использовать. Но я не проверял :)

Не, не нужно ничего в PATH добавлять, т.к. в QtC реализовано обнаружение IAR/KEIL по ключам в реестре.

Интересно, чем автора не устраивает CubeIDE? Среда построена на эклипс, тот же GCC в основе. Бесплатно качаешь и используешь, ни каких лицензионных ограничений. И в добавок ко всему CubeIDE поддерживается производителем МК. Я могу понять желание работать с периферией на CMSIS, но это тоже можно в кубе делать.

Ладно бы для Arduino такое сделать, там реально среда неудобная в работе.

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

В каком плане "медленная"? Он вроде уже в нескольких потоках компилирует.

Графическая настройка тактирования и прочие фичи - это функции CubeMX. Его не обязательно использовать совместно с IDE. Можно отдельно скачать и использовать для генерации проектов под другие IDE. Ну, и по сути, CubeMX в CubeIDE встроен как плагин. Он даже обновляется отдельно. (Капитан очевидность в деле...)

В каком плане "медленная"?

запуск самой среды, переключение между отладка/написание кода (забыл как в экплисе это называется), по сравнению с Segger Embedded Studio тормозит.

 Он вроде уже в нескольких потоках компилирует.

Сам этап компиляции может и быстро происходит, не сравнивал настолько детально.

Графическая настройка тактирования и прочие фичи - это функции CubeMX

Это нравится. Cube IDE нет.

Опять же повторюсь, на мой вкус этот фломастер не вкусный). Я не говорю что оно плохое, я говорю что оно не всем нравится. Поэтому я смотрю на альтернативы Cube IDE, тем более что она только под ST, что не есть удобно при работе с другими МК.

Так можно щаморочиться, и заставить cubeide шить другие контроллеры)))

Я раньше на работе вынужден был использовать кейл. После этого куб как манна небесная!

для чего заморачиваться, если есть универсальная лошадка в виде J-Link(железо + софт)? причем на любой вкус, хочешь полноценно через GUI, хочешь через консоль. я для нашего производства bat файл делал, на входе путь до хранилища с файлами и код изделения, и все)

Я раньше на работе вынужден был использовать кейл. После этого куб как манна небесная!

Iar (на тот момент хороший компилятор - ужасный редактор кода), Keil (прикручивал запуск скриптов до/после компиляции, было удобно, но дорогой зараза), AC6 (тот же эклипс, стшники сначала его предлагали), Attolic пробовал до того, как он кубиком стал. сейчас вот Segger Embedded Studio и Visaul Studio (не код!) для nrf5340. В последней нравится редактор, но процесс сборки не быстрый. в SES есть как плюсы (для нордиков бесплатно), так и минусы (автодополнение работает плохо).

Так что однозначно лучшей среды нет, везде свои плюс\минусы. Но ИМХО по теме статьи, Qt для МК в таком виде слишком уж избыточно. Особенно если использовать только редактор кода.

Iar (на тот момент хороший компилятор - ужасный редактор кода)

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

по отзывам у него лучший компилятор. но смущает несколько стоимость лицензии)

Меня тоже смущает, поэтому я свое некоторое смущение перевел в свой некоторый стыд :) Но у меня и официально купленного софта много, вы не подумайте :)

Хотя я уже давно не работаю с AVR и Arduino, я планирую написать аналогичные статьи и для них, поскольку осталось настроенное окружение. Только нужно разобраться как делать on-chip debug для AVR.

В статье речь идет о GUI-IDE дающего возможность работать не только из CLI. Mbed CLI — это название инструмента командной строки. Бек-энд описываемого в статье решения, понятно может работать и без GUI, прямо из CLI(Make-файлы к слову можно делать не только написанием/правкой в ручную, но и при желании еще и в GUI-утилите Cube MX). А потому, как ни крути Mbed CLI дает куда больше ограничений.

Если говорить про Cube-IDE(речь именно о Cube-IDE, а не Cube-МХ, который может выдавать Make-файлы для STM-32), Кейл, и т.п. IDE, то их обхожу стороной, по простой очевидной причине - с одной стороны их, например в отличии от упоминаемого выше Arduino-IDE, нельзя рекомендовать даже начинающим, чтоб снизить порог вхождения в программирование МК на С/С++, а с другой стороны, когда вы выполнили начальное вхождение в тему, регулярное сидение на таких "Мега-IDE"(точно так как и дальнейшее сидение после начального вхождения в Arduino-IDE) сводит Ваш дальнейший профессиональный рост в работе с МК, лишь к навыкам работы в конкретной IDE, а не общего понимания специфики процесса программирования МК как класса железяк.

регулярное сидение на таких "Мега-IDE"(точно так как и дальнейшее сидение после начального вхождения в Arduino-IDE) сводит Ваш дальнейший профессиональный рост в работе с МК, лишь к навыкам работы в конкретной IDE, а не общего понимания специфики процесса программирования МК как класса железяк.

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

Вопрос тут вовсе не 'CLI или GUI', а в том, что даже для программ уровня банального блинка "Мега-IDE" вместо нескольких строк на С/С++ по присвоению значений регистрам МК(которые с точки зрения синтаксиса языка служебные перемененные, имена которых указанные в даташите на МК) и чтения, того что там есть, пихают туда под килобайт и более разного кода, просто потому что они устроены по принципу мутного стекла напрочь не способствующего росту понимания про создание прошивок МК без разных эксклюзивных "мега-костылей", заменяющих и прячущих от программиста работу с системными перемененными МК.

Так это вопросы к фреймворку, а не к IDE. Вы как в блокноте можете подключить библиотеки на килобайт для простого мигания светодиодом, так и в IDE уложить в 300-400 байт на регистрах вывод измеренного на входе АЦП значения на семисегментные индикаторы.

Строго говоря, так и есть. Но сугубо теоретически, если говорить об идеализированной IDE в сферическом ваккуме. Тут же статья о конкретике. А как, правило, "фирменные" IDE для МК созданы, с прибитыми к ним библиотеками даже для ного-дрыга в блинке, так сказать, по "Ява-философии", где добродетель, максимальной переносимости кода с хрустом подминает под себя все прочие добродетели. Что мягко скажем оптимально далеко не всегда, тем более в мире МК, где вы в итоге пишите прошивку под голое железо, где нет даже cin и cout, а есть имена регистров периферии к которым в итоге и напрямую и обращается ваша скомпилированная программа для МК.

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

На Ардуине не работал, Куб использую только для "конструирования" начальной инициализации периферии, да и то с большой оглядкой. Ардуина - это вообще отдельный разговор. Но тот же IAR, да и Keil вроде тоже, добавят от себя лишь минимальный стартап-код. И насчет "пусть лежит на всякий случай" - линкеры этим уже давно не занимаются даже с минимальным уровнем оптимизации. Если лежит - значит оно где-то используется.

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

а потом они придумал HAL с ещё большой структурой

Именно так и есть!

Про Куб - если Вы результат конструирования начальной инициализации конкретного STM-32 с нужными оптимизациями выведите из него в виде Make-файла, то при наличии в компе компилятора ARM и утилиты st-flash, дописав в конец Make-файла код приводимый ниже(FLASHSIZE=64k поправьте по объему флэша конкретного STM-32), то "make", "make flashwrite", и "make flashread" обеспечат сборку прошивку и вашего Src/main.c, к которому никто без вашего ведома ничего не инклюдил. Очистка флеша - "make erase"

FLASHSIZE=64k

flashwrite:
st-flash --reset --format ihex write {BUILD_DIR}/{TARGET}.hex

flashread:
mkdir -p {BUILD_DIR}
	st-flash --format ihex read ${BUILD_DIR}/{TARGET}.hex 0x08000000 ${FLASHSIZE}

erase:
st-flash --reset erase

Sign up to leave a comment.

Articles