
Комментарии 45
mbed - не имеет ограничений и бесплатна.
для тех же STM и "кубик" то бесплатен со средой.
хотя в целом, что такого дает Qt, без чего трудно будет в микроконтроллере? Code Lite тоже open source, тоже можно подцепить внешний компилятор. Только более легкая по сравнению с тем Qt, особенно если последний используется только как редактор кода.
Mbed это онлайн IDE, с бекэндом на не подконтрольном Вам сервере, что по определению накладывает понятные и существенные ограничения при использовании Mbed в разработках.
Спасибо за статью, ноВозвращаемся в Kits и донастраиваем наш комплект. Выбираем Device type и Device – Bar Metal Device. Применяем. QtCreator не очень дружит с Makefiles.
Ушел много лет назад от креатора на vscode так как очень неудобно реализован процесс переносимости. В vscode достаточно плагинов cortex-debug и settings-sync для полноценной работы с cmake makefile проектами STM32 на другой машине. Все настройки для отладки и прошивки как есть хранятся в директории проекта.
В креаторе же надо было ручками заводить таргеты или копировать файлы из системной директории, я так понял в этом плане не поменялось ничего?
Ну хоть поддержка svd появилась, это хорошо!
Наверное для тех кто и так кодит декстоп проекты в креаторе это имеет смысл, ну и у кого не очень новый пк, ибо vscode иногда очень аппетитный к ресурсам.
Столько возни ради блинка светодиода.. На avr и ассемблере программа блинк занимала несколько десятков байт.
Может быть Вы еще запилите подобный мануал для подключения 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 кБ ОЗУ) с учетом что память нужно будет по другие полезные задачи, точно применимо будет?
Скачай IAR for ARM с торрента и прекрати ненужные извращения. Удивительно стремление людей усложнять себе жизнь.Твой метод-для изощрённых извращенцев.
Все бы вроде хорошо, но использование мейкфайлов это конечно, дичь.
Для программирования МК хорошо подходит сборочная система 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, выглядит более заманчиво.
Интересно, чем автора не устраивает 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 для МК в таком виде слишком уж избыточно. Особенно если использовать только редактор кода.
Хотя я уже давно не работаю с 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 {TARGET}.hex
flashread:
mkdir -p {TARGET}.hex 0x08000000 ${FLASHSIZE}
erase:
st-flash --reset erase
Настраиваем QtCreator для полноценного программирования и отладки микроконтроллеров STM32