JetBrains CLion для микроконтроллеров

Автор оригинала: elmot
  • Перевод
  • Tutorial

Предыстория



CLion — это среда для разработки на С/С++, близкий родственник IntelliJ IDEA и, соответственно, Android Studio.


Я представляю вниманию сообщества перевод моего блог поста, в котором по шагам описано, как использовать эту IDE для написания прошивок микроконтроллеров.


Примерно полтора года назад я написал блог-пост по английски, в котором рассказал, как можно использовать JetBrains CLion для программирования микроконтроллеров.


Если кратко, в тот раз я использовал одну из плат серии STM32-Discovery. Набортный программатор был перешит в совместимый с SEGGER JLink. Также был использован генератор кода STM32CubeMX, тулчейн GCC ARM и отладчик SEGGER Ozone. При помощи всего этого удалось поморгать светодиодиком :).


Такой набор инструментов в целом работал, но требовал перешивки программатора, запуска внешнего отладчика (зачем он нам, если есть замечательный CLion?), кроме того, SEGGER накладывает довольно жесткие лицензионные ограничения на такие перепрошитые программаторы.


Естественно, все эти проблемы меня не радовали, и я пытался найти решение получше. К счастью, прогресс не стоит на месте, и за прошедшее время и CLion, и CubeMX были существенно улучшены, и самое главное, CLion теперь поддерживает Remote GDB. Теперь стало реально использовать OpenOCD (Open On-Chip-Debugger) как ПО для заливки и отладки прошивок микроконтроллеров. Таким образом можно избавиться от ограничений лицензии SEGGER в пользу инструментов с открытым исходным кодом. Более не требуются никакие перепрошивки программаторов, демо-платы можно использовать прямо так, даже для прошивки целевых устройств (см. документацию на платы ST Nucleo или Discovery).


Мне удавалось запустить это все на ванильном CLion, но настройка проектов была настолько сложной, что я в конце концов пришел к мысли написать свой собственный плагин, который позволит увязать друг с другом все инструменты сразу. И вот, я довел плагин до бета-версии, опубликовал в репозитории JetBrains, и готов показать, как это все это функционирует. Для примера мы сделаем небольшой демо проект (сюрприз! Мы будем мигать светодиодами!), используя одну из самых популярных плат от ST Microelectronics – STM32F4-Discovery. Тот же самый пример, с небольшими изменениями, может быть запущен на любой плате из серий STM32 Nucleo, Discovery или EVAL, поскольку светодиоды есть на каждой из них.


Инструментарий


CLion


Прежде всего, нам нужна, собственно, IDE. CLion доступен для загрузки на сайте JetBrains. Просто запустите инсталлятор и следуйте инструкциям. Вам понадобится лицензия, но месячного триала должно хватить на первое время. Инструкция по установке тут.


Плагин


Откройте настройки CLion, вкладку Plugins, нажмите Browse Repositories… и найдите плагин по ключевому слову openocd. Далее Install и рестарт CLion.


Установка плагинаТеперь в CLion появился еще один Run Configuration, два дополнительных пункта в меню Tools еще одна вкладка в настройках.


Тулчейн


Тулчейн (toolchain) – это кросс-платформенный набор инструментов для сборки программ и прошивок. Кросс-платформенный – это значит, что компиляция происходит на PC или Mac, а результат сборки будет работать только на целевом устройстве. В нашем случае это ARM-совместимый МК.


Существует несколько разных тулчейнов, таких как свободные и поддерживаемые CLion’ом Clang или GCC, а так же несколько коммерческих (Keil, IAR, Raisonance, etc). Я использую GCC, скачанный из официального источника – https://developer.arm.com/open-source/gnu-toolchain/gnu-rm. Обратите внимание, после установки тулчейн должен включен в system path. Проверить это можно, запустив arm-none-eabi-gcc из командной строки.


OpenOCD


OpenOCD – это отладчик, поддерживающий аппаратную отладку различных МК с помощью одного из множества поддерживаемых программаторов. Также он может прошивать FPGA и flash-память. Таким образом, потенциально можно работать с огромным количеством разных чипов, не ограничиваясь продукцией ST.


Из всех возможностей OpenOCD плагин использует три:


  • поддержка прошивальщика ST-Link/V2


  • Поддержку МК с ядром ARM Cortex M


  • Поддержку протокола Remote GDB

OpenOCD официально распространяется в виде исходников, но существуют также полуофициальные сборки под все популярные платформы. Более подробно смотрите тут: http://openocd.org/getting-openocd/. Под Windows еще нужен драйвер для ST-LINK/V2. Драйвер обычно идет в сборке OpenOCD для Windows, но можно его скачать и напрямую, с сайта ST, вместе с весьма удобной утилитой для прошивки МК, вот отсюда: http://www.st.com/en/development-tools/stsw-link004.html.


STM32CubeMX


STM32CubeMX – это бесплатный генератор кода для любых МК STM32. В нем можно настроить конфигурацию выводов, периферийных устройств, тактирование ЦПУ и так далее. Все это происходит в весьма удобном визуальном редакторе. После этого Cube создает костяк исходного кода, то есть все необходимые .c и .h файлы, а также файлы проекта для одной из поддерживаемых IDE (в число которых CLion, увы, не входит). Cube состоит из собственно редактора-генератора и подгружаемых т.н. "Firmware Packages", по одному на каждое семейство МК. Сам генератор доступен для загрузки здесь.


Приступим


Одна из самых популярных плат для STмовских МК – STM32F4-Discovery. Ее и возьмем для нашего примера. На борту довольно мощный (хотя и не топовый) МК – STM32F407, прошиватель, совместимый с ST-LINK/V2, и 4 управляемых светодиода. Там еще микрофон, звуковой выход, акселерометр, USB, но в этой статье мы не будем углубляться в них – займемся только светодиодами. Если у вас уже есть какая-нибудь другая плата из серий STM32 Discovery, Eval или Nucleo, то это не беда, вы можете сделать все тоже самое на любой из них, т.к. там есть как минимум один светодиод.


Настройка платы


После установки всех инструментов давайте, наконец, напишем "улучшенную мигалку" для нашей STM32F4-Discovery. Перво-наперво, запускаем CubeMX. При старте он загружает список доступных МК и плат из сети, и после этого можно выбрать любой из МК. Естественно, мы больше заинтересованы в платах. Переходим в “Board Selector”, находим и дважды кликаем STM32F4DISCOVERY.


Выбор платы


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


Редактор


Поскольку мы начали не с "голого" МК, а с платы, то кое-что уже сделано для нас. В частности, настроены нужные нам GPIO для светодиодов, им даже присвоены имена LD3...LD6. Нам только требуется донастроить сам проект и сгенерировать код. Нужно выбрать папку проектов, имя собственно проекта и задать SW4STM32 в качестве Toolchain/IDE.


Настройки STM32CubeMX


Теперь нужно закрыть настройки и нажать Generate Code, т.е. кнопку с шестеренкой. Когда генерация кода закончена, просто закройте финальный диалог (т.е. не надо трогать кнопку "Open Project").


Наконец мы можем открыть полученный год с помощью CLion. Выберите File -> Import из главного меню или Import Project from Sources из Welcome screen. В процессе импорта CLIon может показывать диалоги подтверждения или показывать ошибки – просто игнорируйте это. Когда проект будет, наконец, импортирован, следует выбрать в меню Tools->Update CMake project with STM32CubeMX project.
ОбновлениеВ этот момент плагин перепишет CMakeLists.txt полностью, и, таким образом, подключит тулчейн и все необходимые скрипты. Теперь CLion сможет скомпилировать и собрать проект. Кроме того, плагин настраивает новую Run Configuration для заливки и отладки скомпилированного проекта.


Настройка параметров плагина.


Снова откройте настройки CLion, на этот раз вкладку OpenOCD Support в группе Build, Execution, Deployment.


Настройки плагина Там необходимо указать папку, где находится OpenOCD и файл конфигурации для платы. Плагин пытается найти OpenOCD в system path сам, но иногда нужно явно прописать точное местонахождение. В большинстве случаев настройки портов и путь к GDB вам менять не надо, однако пользователям Mac все-таки нужен другой gdb. Например, можно взять arm-none-eabi-gdb из тулчейна.


Самое последнее, что нужно сделать – выбрать файл конфигурации платы (Board Config File) с помощью соответствующего диалога. Эти файлы находятся в подпапке boards инсталляции OpenOCD. Для данного проекта наилучшим выбором является, очевидно, stm32f4discovery.cfg.


А теперь добавим кода


Вот теперь мы все необходимые настройки сделаны, можно писать код. Открываем main.c, находим бесконечный цикл while и добавляем туда несколько строк, см. строки 106-111:


Исходник


Эти строки зажигают случайную комбинацию светодиодов каждые 300 мсек.


Также можно добавить несколько директив #pragma (строки 100, 101 и 113) чтобы избавиться от предупреждений CLion – бесконечные циклы не используются в "нормальных" программах на C и, поэтому, они не нравятся нашей IDE.


Ключ на старт!


Настал момент поставить breakpoint где-нибудь внутри тела main() и запустить это все! CLion соберет проект, загрузит в нашу плату, запустит отладчик и сбросит МК. Теперь можно пользоваться breakpoints и watches для отладки.


Лучше один раз увидеть, чем три раза прочесть:



Что дальше?


Если уважаемому читателю удалось проделать все вышеописанное, то простенький пример прошивки работает. Но как писать код далее? Окей, вот несколько советов в форме вопрос-ответ.


Q: Какие платы поддерживаются?
A: Более-менее любые демо платы STMicroelectronics серий STM32 Discovery, Nucleo или EVAL должны работать.


Q: Что делать, если мне надо поменять аппаратную конфигурацию МК?
A: Запустите STM32CubeMX снова и откройте ваш проект, сделайте необходимые изменения и перегрерируйте код. Плагин в IDE спросит, не надо ли обновить проект. Просто ответьте "Yes".


Q: Как я могу защитить написанный мной код от перезаписи в момент генерации?
A: Всегда пишите свой код между псевдокомментариями
/* USER CODE BEGIN ??? */ и /* USER CODE END ??? */.


Cube не трогает эти фрагменты при генерации кода. Не забывайте переносить автоматически добавляемые директивы #include в такие места. Альтернативный подход для больших кусков кода – отдельные файлы .c/.h.


Q: Мне нужно добавить внешнюю библиотеку, подключить FPU, сделать еще какие-то изменения в CMakeLists.txt. Но как?
A: CMakeLists.txt автоматически перезаписывается плагином из шаблона, напрямую там лучше ничего не менять. Сам шаблон автоматически записывается среди файлов проекта, следует сделать изменения там, после чего обновить проект, используя пункт меню Tools->Update CMake project with STM32CubeMX.


Q: Я хочу использовать CLion для моих разработок на базе ARM, но не на STM32. Могу я использовать этот плагин?
A: Скорее всего, да. Надо установить все те же инструменты (кроме STM32CubeMX), а затем написать свой собственный CMakeLists.txt (вот шаблон), скрипт для линкера и файл конфигурации платы. Когда все готово, выберите Tools -> CMake -> Reset Cache and Reload Project и создайте свою Run Configuration типа OpenOCD Download & Run. Один из пользователей плагина все это проделал для Atmel SAM E70.


Q: Я хочу использовать CLion и плагин для моих разработок, но не для ARM. Это возможно?
A: Ну, если ваш МК поддерживается GCC, прошиватель совместим с OpenOCD, то как минимум можно попробовать. Возьмите подходящий тулчейн и см. предыдущий ответ.


Q: Я не могу подобрать подходящий файл конфигурации платы. Я могу использовать несколько отдельных файлов конфигурации?
A: Можно написать свой файл конфигурации платы, скомбинировав их. Положите его в свой проект, а за образец возьмите один из стандартных.


Q: А мне нравится! Могу я как-нибудь поддержать проект или поучаствовать в нем?
A: Конечно!


Ссылки


Поделиться публикацией

Комментарии 67

    0

    Большое вам спасибо за проделанную работу!
    Можно будет попробовать нормальную IDE вместо Keil. Скажите, а просмотр регистров и памяти доступен?


    Хотя из нормальных IDE недавно нашел ARM'овский DS-5 Development Studio (на базе эклипса), правда ограничения в бесплатной версии.


    А ARM Compiler можно прикрутить? Он, пишут, более оптимизированный код генерирует.

      0
      я юзаю Qt Designer — вполне себе адекватное IDE под STM32. да, немного потратить время на создание QBS файла, да кубик приходится запускать отдельно, да, порой открывает файлы проекта с «типа брекпоинтами» в них не останавливая выполнение кода на самой железке, чаще всего сразу после запуска (достаточно просто кликнуть «run» чтобы IDE одумалось) — но в целом работать вполне можно.

      раньше юзал эклипс, но настраивается тоже муторно, + жрет память дико — потому привозврате к stm32 решил не разворачивать его, а попробовать qt designer, и в принципе не жалею.
        0

        Да я в CubeMX не использую, так что на проблему меньше, видимо. HAL как-то не нравится особо. Под те контроллеры, что использую, есть SPL и она как-то больше по душе.

          0

          Если уж на то пошло, то я не заметил, чем HAL так уж прямо хуже SPL, оба так себе, мда. А про драйвер USB вообще слов нет. В последних версиях куба появилась альтернатива HAL — нечто под названием LL(low level). Я эту штуку еще не трогал, но вроде она не такая тяжеловесная как HAL.

            0

            LL это что то типа SPL внутри HAL. Ну я так понял.

              0

              Не совсем. Это альтернатива. Причем конфликтующая в ряде случаев. Поэтому я ее и не трогал.

          0
          Qt Designer? Может быть Qt Creator?
            0
            упс, таки да, Creator.
            0

            .

          +3
          Пожалуйста!
          Положа руку на сердце, я не могу сказать что в его нонешнем виде CLion идеален для эмбедов, многого не хватает, в частности просмотра памяти. Но я знаю, что команда заинтересована в развитии этого направления, и работа по написанию недостающего идет. Можно порыться у них багтрекере, поставить плюсики на самые важные фичи, это может ускорить дело. У меня в планах есть реализация поддержки SVD файлов, тогда и регистры будут.

          Про ARM Compiler не знаю. Пока что в качестве системы сборки поддерживается только Cmake, который, в свою очередь, не знает ничего про arm compiler. Думаю, что теоретически можно прикрутить, но уйдет много крови.
            0
            del
              0
              Ну вот сходу нашлось что-то такое про ARM & CMake. Мне кажется, через CMake должно работать.
                0

                Нет, это про gcc и clang опять.

              +1
              Я хочу монитор периферии как в Keil
              ЗЫ. Простите, баловство. Нужно отличать красивый редактор от IDE.
                +1

                Я тоже хочу и даже планирую. И это не баловство.А сентенция насчет редактора мне непонятна. С моей точки зрения силайон куда в большей степени IDE, чем кейл или иар.

                  0
                  Ну… как вам сказать. Для эмбеда в данный момент всё же Keil, IAR и даже Eclipse в большей степени IDE, чем CLion.
                    0
                    Чем Eclipse хуже Keil/IAR как IDE для эмбеда?
                      +1
                      Ничем, Eclipse я сам использую для STM32. И мне всё нравится, ибо работать в редакторе IAR — такая боль :( Написал «даже» по причине того, что IAR и Keil это изначально эмбед, а Eclipse — чуть-чуть настроить надо))
                        0
                        А по моему Eclipse с его тормозами такая боль.
                        Чтобы не быть голлословным, пробовал я писать как то в Eclipse для CC1310. От нажатия на кнопку загрузить, до самой загрузки и точки останова на функии main проходит 20. Тоже самое в Iar 10 секунд.
                          0
                          Эм, тут всё зависит от железа и настроек. Если настройки Eclipse оставлять стандартные, то да. Я, например, выделил побольше оперативки. У меня на STM32 в среднем (зависит от размера прошивки, поэтому и в среднем) от нажатия кнопки Debug до брекпоинта в начале main — порядка 5-7 секунд(без пересборки проекта, разумеется).
                            0
                            Может быть. Но то что у Эклипса явно медленнее интерфейс, ни какими настройками уже не изменишь.
                    0

                    Чисто с точки зрения написания кода: да. С точки зрения всего остального: спорно. Для написания десктопного приложения нужно как минимум в чём-то делать формы (меня не вдохновляет их руками прописывать). Для работы с МК нужен удобный инструмент для просмотров регистров и памяти отлаживаемой железки.

                  +2
                  Увы, JetBrains и Clion все еще слабый ниструмен для программирования МК. Этот инструмент не изменился за последние год, для программистов МК.
                  Сама компания не стремиться развивать это направление, я пробовал выйти на представителей JetBrains, заинтересовать руководство, с большим желанием разработать хороший инструмент, написал несколько писем, на разные доступные e-mail, постучал в HR стену Katia Alisova, и даже нашел ее телефон позвонил, пообщался, ну и заполнил стандартную анкету JB. Ну как бы реакция нулевая. Я сделал вывод что компании эта ниша не интересна, и пока не надо использовать CLion.
                  Мне бесплатно 50 ключей на IDEA оказалось проще получить.

                  Всем мои беды на текущий момент решил VisualGDB + VS2017, чем я сейчас и пользуюсь, всякие кейлы и кукоксы забыл как страшный сон. Стоит недорого а поддерживает большой ряд разных мк. А VS среда мощная, и поиск, и помощь, все работает как надо.

                  По поводу OpenOCD, ребята, ну вы серьезно, он не годится больше не для чего кроме как на макетке погонять, либо просто перепрошить. Флагманом в отладке является Segger JLINK. Работают эти программаторы по разному, у меня есть и последний ST-Link и Segger, и я использую только Segger, тк по моим ощущениям OpenOCD менее стабильно работает.
                  Кейл это мамонт, IAR вообще не представляю как люди работают, два инструмента старые как 1С бухгалтерия. Eclipse это геморой. NetBeans — хорошо работает, более приятна, и пикушки программирует (MPLAB X на них базируется), да и заточить можно под другие мк. AVR-ки вообще крутые, Visual Studio по сути.
                    +1
                    Да, в силайоне есть еще многое, что можно допилить для эмбедов. И за последний год он как раз изменился. Появился Remote GDB как минимум.
                    По поводу намерений компании — у меня ровно обратное впечатление, я общаюсь с ребятами, с их стороны явно есть очень существенный интерес. Ну а к HR ломиться в такой ситуации точно бесполезно.
                    По поводу OpenOCD — в чем разница между «серьезно» и «несерьезно»? У меня openocd вполне работает. Чем сеггер так невыносимо прекрасен, я так и не понял, а вот глюки сеггеровского gdb сервера я видел своими глазами. Причем в openocd можно и самому покопаться, а segger закрыт. Если Вы обратите внимание, мой первый блог-пост был именно про сеггер, но мне неудобно пользоваться отдельно дебаггером, отдельно ide, да и лицензионные ограничения опять же. Я занимаюсь embedded ради хобби, и покупать сеггеровскую лицензию за сотни долларов мне просто дороговато.
                    Да, кейл и иар — ужас, к эклипсу и его производным у меня идиосинкразия, а средами от JB я пользуюсь этак уже лет 15, и мне они нравятся. У меня в планах есть поддержка SVD файлов, после чего работа с периферией в отладчике будет подобна кейловской или сеггеровской, и я точно знаю, что прямо сейчас в в разработке у команды силайона несколько важных фичей, важных для embedded. Так что все только начинается.
                      +1
                      Подсистема OpenOCD не плоха для интегрирования и изучения.
                      Основная фишка сиггера — это профессиональное оборудование, которое поддерживает пожалуй почти все контроллеры. Один программатор для разных девайсов.
                      OpenOCD — тоже нехило чего поддерживает, и оборудование можно сделать самому за даром,
                      Но для STM8/32 купи ST-LINK/V2. Разница в цене — в 10 раз минимум. Глючит ли Segger gdb — конечно да.
                      Я здесь не буду обсуждать насколько хороша openocd или segger gdb, но мне комфортнее последним пользоваться. Как мне кажется она менее тормозная, и более отзывчивая.

                      Что касательно железа: пример, я недавно делал девайс, там на борту пуш-пул преобразователь, генерируемый PWM с контроллера. У сиггера при завершении отладки, тыкаешь когда стоп (выход из отладки), делается ресет, либо работа ПО продолжается, у ST-LINK программа стопиться, колом, порой получается так что транзистор остается открытым, пропуская дикие токи через себя и греясь.
                      Все это и формирует общее впечатление.
                        0

                        Самый дешевый причем легальный stlink/v2 — это любая плата дискавери со сброшенными джамперами. От 8 зеленых. Правда без эл. развязки и залоченная только на stm32. Аналогично для stlink/v1 + stm8. Патч для последнего сейчас на ревью в репозитории openocd. С другой стороны, увы, но stm8 не поддерживается нормальными компиляторами, так что пока мимо все равно. У меня в планах поддержать открытый прошивальщик BlackMagic, тогда можно будет за копейки работать с очень многими чипами. Ваш случай с зависанием на выходе наводит на мысль сделать настройку типа "disconnect script". Должно быть полезно.

                          0

                          Iar + st-link, при нажатии кнопки стоп программа продолжает работать.

                          +1
                          Плюсы инфраструктуры Segger (+ J-Link): нативная поддержка большинством IDE, стабильность, скорость работы, полезные фичи (RTT, SystemView). Плюсы OpenOCD (+ любой отладчик): цена, открытость, универсальность.
                            0

                            О, точно, RTT — вещь, и действительно только сеггер.

                          0
                          Хм. Ну вот со мной можно тут на Хабре на эту тему пообщаться. Мы вообще уже больше года ищем человека, который займется именно поддержкой специфичных фич для embedded в CLion. Хотите?

                          Embedded является одним из приоритетных направлений, но пока решаем базовые общие задачи (типа remote GDB, remote dev, до hex view вот руки наконец дошли) и ищем людей на embedded задачи. У нас вот на дебаггере, например, до сих пор один человек. Этого явно мало, ведь отладка на платах потребует существенных вложений наших ресурсов.
                            0
                            Крутое предложение, но я сейчас нахожусь в своих проектах по разработке электроники и ПО, да и заказчики исправно платят, есть обязательства, поэтому на ближайшие пол года/год я точно этим заниматься буду.

                            А вот с поддержкой, консультированием, отладкой на платах я бы мог помочь, ибо на руках есть и разные программаторы, и платы отладочные. Из (если мы говорим о armX, cmX) eсть stm, nxp, at91, nrf и другие. Можно протестировать. Время есть свободное. Территориально я в СПБ нахожусь.
                              0
                              Спасибо за предложение. Мы пока ищем ресурсы, которые будут этим full-time у нас заниматься. Но как они найдутся, обратимся, если появятся вопросы!
                                0
                                Здравствуйте. Я закончил очередной проект, новыми железками заниматься пока не хочется, а желание заняться разработкой инструментов embedded только усиливается. Хотел спросить, как и куда лучше отправить резюме?
                                  0
                                  Присылайте мне, например, на anastasia.kazakova at jetbrains.com
                                    0
                                    Отправил вам с почты truebest at yandex.ru
                                      0
                                      Спасибо, я все получила.
                              +1
                              Было бы классно, если бы CLion ещё и с Rust плагином хорошо дружил (а не как сейчас, с разными приседаниями).

                              Или даже коммерческая IDE для Rust с запчастями от CLion (типа того же дебаггера и вот этих вот ваших специфичных фич для embedded).
                                0
                                А что значит «хорошо»? Сейчас Rust плагин в CLion — единственный вариант IDE для Rust с отладчиком (в IntelliJ IDEA Community плагин идет без отладчика). Вероятно, даже Cargo рано или поздно появится для случая плагина в CLion.
                                  0
                                  А попробуй взять, да открыть проект на Rust (с Cargo.toml) в CLion + Rust plugin.

                                  В IntelliJ IDEA Community можно просто открыть директорию с Rust-проектом и всё работает автоматически.

                                  CLion открывать отказывается, его нужно тщательно уговаривать (кажется, import from sources работает). И даже после уговоров всё равно разные «хвосты» вылазят, типа ошибок unknown module: JAVA_MODULE, невозможности просто сделать compile, и автоматически сгенерированный CMakeLists.txt (который не нужен).

                                  Вот сейчас у меня все файлы в CLion серенькие. Я так думаю, потому что он считает, что они не принадлежат проекту.
                                    0
                                    Ну так это как раз потому, что требуется CMake (пока что). А IntelliJ IDEA Community умеет Cargo проекты открывать. Поэтому в CLion пока надо полноценный CMake проект делать и все файлы в него включать. Но надеюсь, Cargo и в CLion появится в скором времени.
                                      0
                                      Так я про то и написал:

                                      >Было бы классно, если бы CLion ещё и с Rust плагином хорошо дружил (а не как сейчас, с разными приседаниями).

                                      ;)
                                        0
                                        Спасибо :) Первое впечатление — стало как надо!
                              +2
                              Иронично, но благодаря вашей статье я вдруг наконец-то понял, как правильно писать под STM32 без IDE :) Просто не знал что scaffolding проекта нужно делать через STM32CubeMX ровно как и то, что эта программа превосходно работает под Linux. А без scaffolding сами понимаете как это трудно. Большинство же туториалов для начинающих написаны в стиле «качаем InstallIDE.exe, и жмем в кнопочки так-то и так-то». В любом случае, спасибо большое за пост!
                                +1

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

                                  +1
                                  Я так понимаю что СLion и OpenOCD должна работать под macOS?
                                  Просто под мак нет ничего дельного…
                                    +1

                                    Да, под маком все работает. Я только что получил донат от счастливого маковода.

                                      0
                                      Да, там все должно работать, только GDB дебагер надо брать не бандленный. Потому что мак пока единственная платформа, где мы в CLion GDB бандлим не multiarch. (пересоберем в 2018.1, думаю)
                                        0
                                        Насколько я понимаю, в тулчейне идет правильный gdb.
                                      0
                                      Достаточно успешно «приспосабливаю» проекты для CLion с помощью github.com/ObKo/stm32-cmake. Просто копирую папку cmake в корень проекта, создаю из шаблона CMakeLists.txt. В некоторых случаях приходилось допиливать напильником по месту (например, в легаси проекте с SPL). Отлаживать, правда, не пробовал, но это не главное: проекты достаточно объемные и писались задолго до меня. Так что без CLion'а разобраться трудновато было бы. Конечно, хотелось бы оставаться в рамках одной среды разработки, но, с моей точки зрения, это не проблема, особенно учитывая ограниченность отладки микроконтроллеров в целом, по крайней мере без дополнительных средств трассировки и т.д.
                                        0

                                        Я примерно так же делал по началу. Но с плагином все мегабыстро стало.

                                          0
                                          Я не смотрел глубоко, но у Вас там не используется toolchain файл, как я понимаю, просто «форсится» компилятор и отключаются все проверки? Мне кажется, это менее гибко и менее надежно, чем в stm32-cmake. Хотя должно быть быстрее. Сколько раз в час вы импортируете новые проекты?
                                          Эх, если бы в CLion, помимо диалога, компилятор можно было бы через тулчейн-файл задать, и чтобы для анализа кода именно этот компилятор использовался, да выбор из набора типовых тулчейн-файлов…
                                            0
                                            Зачем нужна такая гибкость? Сколько раз в час вы меняете компилятор у проекта?
                                            Через тулчайн переимпорт проекта у меня _может_ случаться довольно часто, если я экспериментирую с конфигурацией железок.
                                              0
                                              Зачем вообще это нужно?
                                              Нет, ну я понимаю, удобно выбрать тулчейн, разные компиляторы — разный результат (особенно по размеру bin файла). Редко но бывает на одном что-то работает, на другом нет. Но для анализа кода? Это как? Исходники компилятора подтягивал чтобы красноты не было?
                                              image
                                                0
                                                А если проектов несколько? А если синтаксический анализатор не подхватывает все опции компиляции? И красит красным чисто собираемый проект? Все это шум, мешающий разгребать чужой код(
                                                  0
                                                  в CLion, насколько я понимаю, свой парсер С. Замена компилятора не изменит ничего.
                                                0
                                                Эх, если бы в CLion, помимо диалога, компилятор можно было бы через тулчейн-файл задать, и чтобы для анализа кода именно этот компилятор использовался

                                                Вы же про это? Я может не поняла до конца, но так и должно работать. Давайте тикет в трекере, если это не так.
                                                  0
                                                  Не совсем.
                                                  Это работает и сейчас, и через -D, и если указать в CMakeLists.txt до объявления проекта. Но хотелось бы, чтобы в диалоге toolchains можно было указать не только пути к компиляторам, а собственно такой файл. И чтобы CLion учитывал, что за компилятор: например, при отключении предупреждений. Сейчас вставляются прагмы clang, и в проектах под gcc приходится добавлять --warn-no-unknown-pragmas.
                                                    0
                                                    Про отключение предупреждений — это бага.
                                                      0
                                                      хотелось бы, чтобы в диалоге toolchains можно было указать не только пути к компиляторам, а собственно такой файл

                                                      В смысле UI какой-то иметь? Не очень понятно
                                                        0
                                                        Нет, UI и сейчас есть. Иметь возможность вместо этого UI выбрать toolchain-файл, чтобы из него сразу все подхватывалось. Уж если в основе CMake — надо иметь возможность все делать cmake way: правильно подключать весь инструментарий, набор кастомных таргетов и т.д. По-моему так! (С)
                                                          0
                                                          Погодите. Так а что мешает в настройках указать этот toolchain файл через -D? Что-то я торможу видимо.
                                                            0
                                                            Это не отменит необходимость задать компилятор в диалоге, а просто «перезапишет» его.
                                                            Задать toolchain для cmake'а можно разными путями, все работают. И при сборке будет использовано именно то, что напрямую задано cmake. Но в диалоге toolchain тоже ведь что-то введено.
                                                            Зачем вообще существует диалог toolchain, зачем указывать компиляторы и т.д.? На что это влияет? Задает toolchain по умолчанию? Вроде это задается для каждого проекта… И почему возможна ситуация, когда проект собирается одним компилятором, в настройках проекта CLion указан другой, а анализ кода производится… хм…
                                                              0
                                                              Toolchain файл через -D приоритетнее настроек в диалоге. Но многим пользователям удобнее именно в IDE настраивать. Возможно какой-то экспорт/импорт настроек между двух источников имел бы смысл.
                                                                0
                                                                Через -D — это прямое указание cmake в обход всего CLion'а, последний тут вообще остается простой запускалкой, можно и во встроенном терминале все сделать). Мне кажется, что должно быть или через поля диалога, или через toolchain-файл, как альтернативы. И иметь возможность параметры диалога расширить всем тем, что доступно в toolchain-файле. Все-таки CLion — инструмент для профессионалов. Кстати, до его выхода я cmake не пользовался практически. CLion заставил начать разбираться). Так что спасибо за инструмент!
                                              +1
                                              Спасибо, я так понимаю первый шаг в направлении микроконтроллеров сделан. Если со временем его доведут до нормального состояния, то можно будет использовать в университете для обучения, а то сейчас приходится использовать Ломанные версии IAR 8.20, что не совсем правильно.
                                                0
                                                Лично я собираюсь использовать то, что есть в моем небольшом курсе по MCU в Åbo Akademi. Посмотрим как пойдет. IAR имхо вообще ад с чертями, лучше уж Atollic Studio или SW4STM32.
                                                  0
                                                  IAR 8.20 уже боле менее :) По крайней мере, отладичк на уровне, да и редактор подтянули.

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

                                              Самое читаемое