Комментарии 31
Плохо искал или нет в природе?
Но потом я попробовал Rust и переписал всё на него. Рекомендую попробовать.
Есть плагин для IntellJ, но он довольно сыроват. В частности, вывод типов работает не идеально, из-за чего местами затруднительно использовать сгенерированную под контроллер библиотеку (генерируется много весьма специфичных типов, под конкретную периферию).
Для студентов вроде на год бесплатная лицензия.
А мне и Keil и SES и IAR и Ride7 и Visual Studio/Code.
Ну а когда совсем делать нечего можно и Eclipsом/CCS/SimplicityStudio/Kinets время убить (и производными от него).
Для супер профи еще ArduinoIde есть.
Рюшки в той же VS необыкновенные, но gcc и рядом не лежал с armcc.
Про отладчик я и говорить не буду. Ozon конечно не плох, но еще поработать надо.
Но каждый вибирает сам — спорить бессмысленно.
Попробовал хваленый Keil — конечно получше блокнота
А вот щас, обидно было (с)
Я уже попробовал CLion для STM32 и у меня ровно обратные притензии:
— У меня вот (как и у 80% людей) ST-Link, че мне делать то с вашим Segger Debuger. Ответ — не дебажить.
— В отличии от Clion, Keil обладает хорошими сис. мониторами, которые позволяют контролировать процесс инициализации/пуска, эвенты/обработчики — что может Clion?
— В Keil есть отличный эмулятор, который позволяет не парится с дев бордой, или юзать функции МК которых нет на твоей борде (какой нить USB или FSMC и т.п.)
— Я использую продукты JetBrains, в частности PyCharm и меня задолбало, что за 4 часа работы IDE выжирает 2Гб ОЗУ (400 начальный это минимум), при всей своей «ненависти» к Keil его потребление неделями остается 40-50Мб, что позволяет мне его использовать ГДЕ угодно и КОГДА угодно.
— Keil имеет собственный репозиторий либ, которые добавляются простой галочкой в настройках.
Не срача ради, но все таки: Вам шашечки (подсветка, цветастость то да се) или таки ехать? (писать/дебагать под МК)
ЗЫ. Взял цв. тему с PyCharm, перегнал в Keil, получил 2 в 1, и Вам того советую. Кстати так и не понял что Вы называете «пакетами»?
А вот если с кучей «бизнес-кода», оставшегося от свинтивших с проекта «железячников» разбираться, то тут уже CLion, Eclipse и т.д. Инструменты для работы с кодом в Keil'е вызывают недоумение.
А по-поводу потребления памяти — то это как Запорожец сравнивать с многоцелевыми истребителем. И по этому показателю, и по работе с кодом, кстати, Keil далеко позади и Atom'а, и VSCode, и Sublime'а, и Emax с Vim'ом…
Мне кажется, что если ограничится работой с железом
А с чем Вы простите работаете, не с железом?
Мне кажется, не надо «редакторы» (atom/sublime), сравнивать с полноценной средой разработки для встраиваемых систем c присущим ей функционалом, ибо то что вы перечисляете есть ничто иное как фишки редактора, не более.
А я сравнил две IDE, и утверждал, что профита от Clion, кроме редактора — никакого.
Кажется мы стали забыть что такое IDE…
Я думаю, что Ryppka имел в виду работу с кодом в плане intellisense, навигацию, семантический анализ, рефакторинг и тому подобное. Иметь всё это — большое подспорье в разработке.
intellisense
Поэтому я и спросил. Вы пишите просто С/С++ оперируя чистым кодом, или вам часто приходится таки работать с железкой?
С железкой, не в плане, «накодогенераторить» а потом сидеть принтами дебагать, че из этого вышло.
В целом для чистого С, мне достаточно что Keil подстветит мне структуры, остальное вырабатывается по ходу работы, но все равно, я считаю что иметь для программирования встраиваемых систем монитор периферии, это огроменный плюс, который перекрывает «квадратность» редактора кода.
Эксперименты с IDE для embedd, я перестал делать после попытки завязаться с CooCooX, понял что проще попытатсья раскрыть потенциал знакомого инструмента, чем сидеть страдать в поисках.
Более того, мне компилятор кейл, как то более по душе, учитывая что он является официальным АРМ компиллером, а 30кб триального кода, на данный момент хватает за глаза.
В целом, я не хотел преподнести свои слова как агрессию, просто автор статьи, как новичек, непонятно за что боролся, настраивая Clion для редактирования кода, в ущерб скажем так «прозрачности» программирования и понимания. Я сам на первых парах лихорадочно трейсил даже функции в библиотеках (stl), сравнивая значения в регистрах с тем что нужно было мне, искал различные нюансы в написании кода, активно использовал эмулятор (например для исследования работы аналогового компаратора, и разных режимов ADC).
Приходится. Хм, может быть, я не совсем понимаю, что вы имеете в виду под мониторами периферии? Потому что Ozone вполне себе показывает состояние периферии, и не приходится разменивать "квадратность" на качество работы с железом. У автора есть удобные неинвазивные логи (через RTT), есть осциллограф (J-Scope), есть инструмент для профилирования в динамике (SystemView), так что я не думаю, что он что-то потерял в плане удобства работы с железом. Может быть, я просто что-то не знаю о кейле (признаюсь, давно было, да и Linux везде) и там есть что-то гораздо удобнее.
Я бы не хотел спорить о том, что лучше, тем более всё сильно завязано на персональное удобство и особенности проектов. Кому-то достаточно триальных ограничений — для меня 30 Кб практически делает компилятор бесполезным, у меня довольно увесистые проекты. Я активно использую C++14 (не спешите кривиться, C++ вполне годен для embedded — если знать подводные камни, много платить не приходится) и не знаю, что у armcc с поддержкой, а кто-то работает с чистым C и для него это не фактор. Кому-то нужна только подсветка кода, а мне некомфортно без маленьких радостей жизни — посмотреть сигнатуру функции под курсором и комментарий к ней, вывести список методов после. или -> (и да, с fuzzy search) и тому подобного. Кому-то хочется подключать библиотеки кликом мыши, а я, признаюсь, немного control freak, мне нужно, чтобы проект был самодостаточной вещью в себе, без управления с помощью GUI-магии (поэтому связка CMake / CLion мне импонирует — обычная система сборки одновременно служит форматом проекта IDE). Так много фломастеров, и так много вкусов. :)
Keil заточен под контроллеры и имеет все необходимое на борту — с этим я даже не спорю, но как IDE очень не понравилась, в каких-то моментах тривиальные вещи в нем становятся не тривиальными, но это мой опыт и мое мнение.
Думаю в Clion получится прикрутить все необходимое, либо дописать плагины, дело времени.
Не вступая в полемику и не делая рекламы (хотя я использую CLion и, для встраиваемого, инструменты от Segger), вроде бы у сеггера есть утилита, которая из ST-Link делает J-Link OB. Но я не пробовал, она просто там в загрузках висит.
Использовал CoIDE. Для труЪ профессионала, конечно, не то, но довольно приятно. Подключение либ из коробки. Нормальный дебаг Ну и все редакторские плюшки Eclipse. Пока эта IDE мне больше всего нравится.
Сейчас использую Keil, так сложилось. Удобнее IAR блокнота, но замечания есть. Иногда не работает автодополнение и навигация по коду. А так же при отладке часто не показывает значения переменных. И в проекте нельзя делать вложенные… гм… назовем их "папки".
P.S.
У меня вот (как и у 80% людей) ST-Link, че мне делать то с вашим Segger Debuger. Ответ — не дебажить.
Я настоятельно призываю не пользоваться нелицензионным ПО и железом, но в ознакомительных целях перепрошивка ST-Link в Segger J-Link
Делал так для RTL-8710, потому что на копеечный радимодуль деньги есть, а на Segger — нет
CLion вполне умеет в удалённый дебаг через gdb->OpenOCD->TS-Link. Отлично работает. Шью тоже через OpenOCD.
Всяких контроллероспецифичных мониторингов иногда не хватает, но они лично мне не очень-то и нужны.
А т.к. я 80% времени сижу в IDEA то перескакивать между разными IDE неохота. Начинаю сбиваться.
*.specs не генерирует, а скорее линкует с соответствующей реализацией libc / libgolss вашего тулчейна.
Например lib/thumb/v7-ar/fpv3/hard/nano.specs:
...
*nano_libc:
-lc_nano
*nano_libgloss:
%{specs=rdimon.specs:-lrdimon_nano} %{specs=nosys.specs:-lnosys}
...
*link:
%(nano_link) %:replace-outfile(-lc -lc_nano) ...
...с, в зависимости от реализации, застабленными вызовами типа такого: https://github.com/32bitmicro/newlib-nano-1.0/blob/c010b5911834ed9a412bd0a865abdf3eed00a4ee/libgloss/arm/syscalls.c#L585
Пока для Baremetal ничего удобнее Qt Creator не нашёл:
- Разные профили и билд директории для отстройки дебажного, релизного и прочего кода. В том числе с разными параметрами билда, очень удобно, когда может быть несколько конфигураций.
- Удобное редактирование параметров CMake для проектов
- Декларативный тулчейн для CMake теперь можно прописать непосредственно в настройках Kit. Или просто указать свой файл, прописав туда:
CMAKE_TOOLCHAIN_FILE=...path_to_toolchain_file... - Поддержка удалённой отладки. В том числе средствами спарки GDB + OpenOCD и/или ST LINK Utility. Загрузка кода через JTAG прямо из IDE.
В общем, всякий раз, когда я беру CLion для напопробовать, на меня находит печаль.
Отмечу, что я использую для CMake проектов скорректированный плагин, который отображает в дереве проекта все файлы, а не только те, которые прописаны в CMakeLists.txt (по аналогии, как это делает CLion).
Недостаток, по сравнению с CLion у QtC ровно один (по мне): нет автоматической возможности добавить файл в CMakeLists.txt к нужному таргету при добавлении его в проект. Нужно вручную открывать и добавлять.
В общем, если интересно: гляньте мои публикации тут.
Да через профиль:
А вообще: http://doc.qt.io/qtcreator/creator-developing-baremetal.html или тут же: https://habrahabr.ru/post/222877/ (правда автор использует qbs). Ну и куча ссылок в гугле по связке "Qt Creator Baremetal".
Прошу прощения за некропостинг, но спешу заметить, что разрабатывать embedded на Qbs — полное издевательство. Ребята из Qt каждый релиз Qt Creator что-то меняют под капотом этой системы сборки и мне приходится бодаться с недодокументацией на Qbs, чтобы понять, что блин надо поменять в настройках проекта, чтобы эта штука опять начала собирать проект.
После третьего к ряду обновления Qt Creator, изрядно задолбавшись, выкинул настройки проекта на мороз и портировал проект на Eclipse (Code Composer Studio).
Qt Creator хорош, но хорош для разработки на пингвинах.
Как-то поздновато на статью набрёл. Сейчас занимаюсь точно такими же экспериментами. Так что "лирику" читал — как про меня написано :)
Могу поделиться ещё и своими находками в плане флагов:
SET(CMAKE_C_FLAGS_DEBUG "-Og -g" CACHE INTERNAL "c compiler flags debug")
SET(CMAKE_CXX_FLAGS_DEBUG "-Og -g" CACHE INTERNAL "cxx compiler flags debug")
SET(CMAKE_ASM_FLAGS_DEBUG "-g" CACHE INTERNAL "asm compiler flags debug")
SET(CMAKE_EXE_LINKER_FLAGS_DEBUG "" CACHE INTERNAL "linker flags debug")
SET(CMAKE_C_FLAGS_RELEASE "-Os -g -flto -ffat-lto-objects" CACHE INTERNAL "c compiler flags release")
SET(CMAKE_CXX_FLAGS_RELEASE "-Os -g -flto -ffat-lto-objects" CACHE INTERNAL "cxx compiler flags release")
SET(CMAKE_ASM_FLAGS_RELEASE "-g" CACHE INTERNAL "asm compiler flags release")
SET(CMAKE_EXE_LINKER_FLAGS_RELEASE "-Wl,-flto" CACHE INTERNAL "linker flags release")Получается две конфигурации. Для debug и для release. В версии release активирована максимальная оптимизация по размеру, плюс full link time optimization (flto). Это такая хитрая функция современного GCC, когда в объектные файлы пишется не только готовый машинный код, но и специальный байткод синтаксического разбора (на сколько я понял). Задаётся это флагами -flto -ffat-lto-objects. В проектах на большом брате можно обойтись и без -ffat-lto-objects. Но на STM32 не получается.
Далее в дело вступает линкер, который при заданной опции -Wl,-flto вычитывает из объектных файлов уже не машинный код, а подготовленный на предыдущем шаге байткод. И проводит агрессивную оптимизацию уже в рамках всего исполняемого файла (прошивки). Что приводит к тому, что прошивка существенно сокращается в объёме и при этом становится намного производительнее.
На "помигать светодиодом" получается около 3.5 Кб вместо 18 Кб.
К слову опцию CMAKE_TOOLCHAIN_FILE можно задать и в корневом CMakeLists.txt перед директивой project. Чтобы не требовать указывать это вручную в настройках IDE.
habrahabr.ru/post/345670
Настройка IDE Clion и Cmake для работы с STM32 и C++