Comments 67
Большое вам спасибо за проделанную работу!
Можно будет попробовать нормальную IDE вместо Keil. Скажите, а просмотр регистров и памяти доступен?
Хотя из нормальных IDE недавно нашел ARM'овский DS-5 Development Studio (на базе эклипса), правда ограничения в бесплатной версии.
А ARM Compiler можно прикрутить? Он, пишут, более оптимизированный код генерирует.
я юзаю Qt Designer — вполне себе адекватное IDE под STM32. да, немного потратить время на создание QBS файла, да кубик приходится запускать отдельно, да, порой открывает файлы проекта с «типа брекпоинтами» в них не останавливая выполнение кода на самой железке, чаще всего сразу после запуска (достаточно просто кликнуть «run» чтобы IDE одумалось) — но в целом работать вполне можно.
раньше юзал эклипс, но настраивается тоже муторно, + жрет память дико — потому привозврате к stm32 решил не разворачивать его, а попробовать qt designer, и в принципе не жалею.
раньше юзал эклипс, но настраивается тоже муторно, + жрет память дико — потому привозврате к stm32 решил не разворачивать его, а попробовать qt designer, и в принципе не жалею.
Да я в CubeMX не использую, так что на проблему меньше, видимо. HAL как-то не нравится особо. Под те контроллеры, что использую, есть SPL и она как-то больше по душе.
Qt Designer? Может быть Qt Creator?
.
Пожалуйста!
Положа руку на сердце, я не могу сказать что в его нонешнем виде CLion идеален для эмбедов, многого не хватает, в частности просмотра памяти. Но я знаю, что команда заинтересована в развитии этого направления, и работа по написанию недостающего идет. Можно порыться у них багтрекере, поставить плюсики на самые важные фичи, это может ускорить дело. У меня в планах есть реализация поддержки SVD файлов, тогда и регистры будут.
Про ARM Compiler не знаю. Пока что в качестве системы сборки поддерживается только Cmake, который, в свою очередь, не знает ничего про arm compiler. Думаю, что теоретически можно прикрутить, но уйдет много крови.
Положа руку на сердце, я не могу сказать что в его нонешнем виде CLion идеален для эмбедов, многого не хватает, в частности просмотра памяти. Но я знаю, что команда заинтересована в развитии этого направления, и работа по написанию недостающего идет. Можно порыться у них багтрекере, поставить плюсики на самые важные фичи, это может ускорить дело. У меня в планах есть реализация поддержки SVD файлов, тогда и регистры будут.
Про ARM Compiler не знаю. Пока что в качестве системы сборки поддерживается только Cmake, который, в свою очередь, не знает ничего про arm compiler. Думаю, что теоретически можно прикрутить, но уйдет много крови.
del
Ну вот сходу нашлось что-то такое про ARM & CMake. Мне кажется, через CMake должно работать.
Я хочу монитор периферии как в Keil
ЗЫ. Простите, баловство. Нужно отличать красивый редактор от IDE.
ЗЫ. Простите, баловство. Нужно отличать красивый редактор от IDE.
Я тоже хочу и даже планирую. И это не баловство.А сентенция насчет редактора мне непонятна. С моей точки зрения силайон куда в большей степени IDE, чем кейл или иар.
Ну… как вам сказать. Для эмбеда в данный момент всё же Keil, IAR и даже Eclipse в большей степени IDE, чем CLion.
Чем Eclipse хуже Keil/IAR как IDE для эмбеда?
Ничем, Eclipse я сам использую для STM32. И мне всё нравится, ибо работать в редакторе IAR — такая боль :( Написал «даже» по причине того, что IAR и Keil это изначально эмбед, а Eclipse — чуть-чуть настроить надо))
UFO just landed and posted this here
Эм, тут всё зависит от железа и настроек. Если настройки Eclipse оставлять стандартные, то да. Я, например, выделил побольше оперативки. У меня на STM32 в среднем (зависит от размера прошивки, поэтому и в среднем) от нажатия кнопки Debug до брекпоинта в начале main — порядка 5-7 секунд(без пересборки проекта, разумеется).
Чисто с точки зрения написания кода: да. С точки зрения всего остального: спорно. Для написания десктопного приложения нужно как минимум в чём-то делать формы (меня не вдохновляет их руками прописывать). Для работы с МК нужен удобный инструмент для просмотров регистров и памяти отлаживаемой железки.
Увы, 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 по сути.
Сама компания не стремиться развивать это направление, я пробовал выйти на представителей 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 по сути.
Да, в силайоне есть еще многое, что можно допилить для эмбедов. И за последний год он как раз изменился. Появился Remote GDB как минимум.
По поводу намерений компании — у меня ровно обратное впечатление, я общаюсь с ребятами, с их стороны явно есть очень существенный интерес. Ну а к HR ломиться в такой ситуации точно бесполезно.
По поводу OpenOCD — в чем разница между «серьезно» и «несерьезно»? У меня openocd вполне работает. Чем сеггер так невыносимо прекрасен, я так и не понял, а вот глюки сеггеровского gdb сервера я видел своими глазами. Причем в openocd можно и самому покопаться, а segger закрыт. Если Вы обратите внимание, мой первый блог-пост был именно про сеггер, но мне неудобно пользоваться отдельно дебаггером, отдельно ide, да и лицензионные ограничения опять же. Я занимаюсь embedded ради хобби, и покупать сеггеровскую лицензию за сотни долларов мне просто дороговато.
Да, кейл и иар — ужас, к эклипсу и его производным у меня идиосинкразия, а средами от JB я пользуюсь этак уже лет 15, и мне они нравятся. У меня в планах есть поддержка SVD файлов, после чего работа с периферией в отладчике будет подобна кейловской или сеггеровской, и я точно знаю, что прямо сейчас в в разработке у команды силайона несколько важных фичей, важных для embedded. Так что все только начинается.
По поводу намерений компании — у меня ровно обратное впечатление, я общаюсь с ребятами, с их стороны явно есть очень существенный интерес. Ну а к HR ломиться в такой ситуации точно бесполезно.
По поводу OpenOCD — в чем разница между «серьезно» и «несерьезно»? У меня openocd вполне работает. Чем сеггер так невыносимо прекрасен, я так и не понял, а вот глюки сеггеровского gdb сервера я видел своими глазами. Причем в openocd можно и самому покопаться, а segger закрыт. Если Вы обратите внимание, мой первый блог-пост был именно про сеггер, но мне неудобно пользоваться отдельно дебаггером, отдельно ide, да и лицензионные ограничения опять же. Я занимаюсь embedded ради хобби, и покупать сеггеровскую лицензию за сотни долларов мне просто дороговато.
Да, кейл и иар — ужас, к эклипсу и его производным у меня идиосинкразия, а средами от JB я пользуюсь этак уже лет 15, и мне они нравятся. У меня в планах есть поддержка SVD файлов, после чего работа с периферией в отладчике будет подобна кейловской или сеггеровской, и я точно знаю, что прямо сейчас в в разработке у команды силайона несколько важных фичей, важных для embedded. Так что все только начинается.
Подсистема OpenOCD не плоха для интегрирования и изучения.
Основная фишка сиггера — это профессиональное оборудование, которое поддерживает пожалуй почти все контроллеры. Один программатор для разных девайсов.
OpenOCD — тоже нехило чего поддерживает, и оборудование можно сделать самому за даром,
Но для STM8/32 купи ST-LINK/V2. Разница в цене — в 10 раз минимум. Глючит ли Segger gdb — конечно да.
Я здесь не буду обсуждать насколько хороша openocd или segger gdb, но мне комфортнее последним пользоваться. Как мне кажется она менее тормозная, и более отзывчивая.
Что касательно железа: пример, я недавно делал девайс, там на борту пуш-пул преобразователь, генерируемый PWM с контроллера. У сиггера при завершении отладки, тыкаешь когда стоп (выход из отладки), делается ресет, либо работа ПО продолжается, у ST-LINK программа стопиться, колом, порой получается так что транзистор остается открытым, пропуская дикие токи через себя и греясь.
Все это и формирует общее впечатление.
Основная фишка сиггера — это профессиональное оборудование, которое поддерживает пожалуй почти все контроллеры. Один программатор для разных девайсов.
OpenOCD — тоже нехило чего поддерживает, и оборудование можно сделать самому за даром,
Но для STM8/32 купи ST-LINK/V2. Разница в цене — в 10 раз минимум. Глючит ли Segger gdb — конечно да.
Я здесь не буду обсуждать насколько хороша openocd или segger gdb, но мне комфортнее последним пользоваться. Как мне кажется она менее тормозная, и более отзывчивая.
Что касательно железа: пример, я недавно делал девайс, там на борту пуш-пул преобразователь, генерируемый PWM с контроллера. У сиггера при завершении отладки, тыкаешь когда стоп (выход из отладки), делается ресет, либо работа ПО продолжается, у ST-LINK программа стопиться, колом, порой получается так что транзистор остается открытым, пропуская дикие токи через себя и греясь.
Все это и формирует общее впечатление.
Самый дешевый причем легальный stlink/v2 — это любая плата дискавери со сброшенными джамперами. От 8 зеленых. Правда без эл. развязки и залоченная только на stm32. Аналогично для stlink/v1 + stm8. Патч для последнего сейчас на ревью в репозитории openocd. С другой стороны, увы, но stm8 не поддерживается нормальными компиляторами, так что пока мимо все равно. У меня в планах поддержать открытый прошивальщик BlackMagic, тогда можно будет за копейки работать с очень многими чипами. Ваш случай с зависанием на выходе наводит на мысль сделать настройку типа "disconnect script". Должно быть полезно.
UFO just landed and posted this here
Плюсы инфраструктуры Segger (+ J-Link): нативная поддержка большинством IDE, стабильность, скорость работы, полезные фичи (RTT, SystemView). Плюсы OpenOCD (+ любой отладчик): цена, открытость, универсальность.
Хм. Ну вот со мной можно тут на Хабре на эту тему пообщаться. Мы вообще уже больше года ищем человека, который займется именно поддержкой специфичных фич для embedded в CLion. Хотите?
Embedded является одним из приоритетных направлений, но пока решаем базовые общие задачи (типа remote GDB, remote dev, до hex view вот руки наконец дошли) и ищем людей на embedded задачи. У нас вот на дебаггере, например, до сих пор один человек. Этого явно мало, ведь отладка на платах потребует существенных вложений наших ресурсов.
Embedded является одним из приоритетных направлений, но пока решаем базовые общие задачи (типа remote GDB, remote dev, до hex view вот руки наконец дошли) и ищем людей на embedded задачи. У нас вот на дебаггере, например, до сих пор один человек. Этого явно мало, ведь отладка на платах потребует существенных вложений наших ресурсов.
Крутое предложение, но я сейчас нахожусь в своих проектах по разработке электроники и ПО, да и заказчики исправно платят, есть обязательства, поэтому на ближайшие пол года/год я точно этим заниматься буду.
А вот с поддержкой, консультированием, отладкой на платах я бы мог помочь, ибо на руках есть и разные программаторы, и платы отладочные. Из (если мы говорим о armX, cmX) eсть stm, nxp, at91, nrf и другие. Можно протестировать. Время есть свободное. Территориально я в СПБ нахожусь.
А вот с поддержкой, консультированием, отладкой на платах я бы мог помочь, ибо на руках есть и разные программаторы, и платы отладочные. Из (если мы говорим о armX, cmX) eсть stm, nxp, at91, nrf и другие. Можно протестировать. Время есть свободное. Территориально я в СПБ нахожусь.
Спасибо за предложение. Мы пока ищем ресурсы, которые будут этим full-time у нас заниматься. Но как они найдутся, обратимся, если появятся вопросы!
Было бы классно, если бы CLion ещё и с Rust плагином хорошо дружил (а не как сейчас, с разными приседаниями).
Или даже коммерческая IDE для Rust с запчастями от CLion (типа того же дебаггера и вот этих вот ваших специфичных фич для embedded).
Или даже коммерческая IDE для Rust с запчастями от CLion (типа того же дебаггера и вот этих вот ваших специфичных фич для embedded).
А что значит «хорошо»? Сейчас Rust плагин в CLion — единственный вариант IDE для Rust с отладчиком (в IntelliJ IDEA Community плагин идет без отладчика). Вероятно, даже Cargo рано или поздно появится для случая плагина в CLion.
А попробуй взять, да открыть проект на Rust (с Cargo.toml) в CLion + Rust plugin.
В IntelliJ IDEA Community можно просто открыть директорию с Rust-проектом и всё работает автоматически.
CLion открывать отказывается, его нужно тщательно уговаривать (кажется, import from sources работает). И даже после уговоров всё равно разные «хвосты» вылазят, типа ошибок unknown module: JAVA_MODULE, невозможности просто сделать compile, и автоматически сгенерированный CMakeLists.txt (который не нужен).
Вот сейчас у меня все файлы в CLion серенькие. Я так думаю, потому что он считает, что они не принадлежат проекту.
В IntelliJ IDEA Community можно просто открыть директорию с Rust-проектом и всё работает автоматически.
CLion открывать отказывается, его нужно тщательно уговаривать (кажется, import from sources работает). И даже после уговоров всё равно разные «хвосты» вылазят, типа ошибок unknown module: JAVA_MODULE, невозможности просто сделать compile, и автоматически сгенерированный CMakeLists.txt (который не нужен).
Вот сейчас у меня все файлы в CLion серенькие. Я так думаю, потому что он считает, что они не принадлежат проекту.
Иронично, но благодаря вашей статье я вдруг наконец-то понял, как правильно писать под STM32 без IDE :) Просто не знал что scaffolding проекта нужно делать через STM32CubeMX ровно как и то, что эта программа превосходно работает под Linux. А без scaffolding сами понимаете как это трудно. Большинство же туториалов для начинающих написаны в стиле «качаем InstallIDE.exe, и жмем в кнопочки так-то и так-то». В любом случае, спасибо большое за пост!
Ну и на здоровье. Куб на джаве написан, его экзешник для винды — явовский архив. Так что должен много где работать.
Я так понимаю что СLion и OpenOCD должна работать под macOS?
Просто под мак нет ничего дельного…
Просто под мак нет ничего дельного…
Достаточно успешно «приспосабливаю» проекты для CLion с помощью github.com/ObKo/stm32-cmake. Просто копирую папку cmake в корень проекта, создаю из шаблона CMakeLists.txt. В некоторых случаях приходилось допиливать напильником по месту (например, в легаси проекте с SPL). Отлаживать, правда, не пробовал, но это не главное: проекты достаточно объемные и писались задолго до меня. Так что без CLion'а разобраться трудновато было бы. Конечно, хотелось бы оставаться в рамках одной среды разработки, но, с моей точки зрения, это не проблема, особенно учитывая ограниченность отладки микроконтроллеров в целом, по крайней мере без дополнительных средств трассировки и т.д.
Я примерно так же делал по началу. Но с плагином все мегабыстро стало.
Я не смотрел глубоко, но у Вас там не используется toolchain файл, как я понимаю, просто «форсится» компилятор и отключаются все проверки? Мне кажется, это менее гибко и менее надежно, чем в stm32-cmake. Хотя должно быть быстрее. Сколько раз в час вы импортируете новые проекты?
Эх, если бы в CLion, помимо диалога, компилятор можно было бы через тулчейн-файл задать, и чтобы для анализа кода именно этот компилятор использовался, да выбор из набора типовых тулчейн-файлов…
Эх, если бы в CLion, помимо диалога, компилятор можно было бы через тулчейн-файл задать, и чтобы для анализа кода именно этот компилятор использовался, да выбор из набора типовых тулчейн-файлов…
Зачем нужна такая гибкость? Сколько раз в час вы меняете компилятор у проекта?
Через тулчайн переимпорт проекта у меня _может_ случаться довольно часто, если я экспериментирую с конфигурацией железок.
Через тулчайн переимпорт проекта у меня _может_ случаться довольно часто, если я экспериментирую с конфигурацией железок.
Зачем вообще это нужно?
Нет, ну я понимаю, удобно выбрать тулчейн, разные компиляторы — разный результат (особенно по размеру bin файла). Редко но бывает на одном что-то работает, на другом нет. Но для анализа кода? Это как? Исходники компилятора подтягивал чтобы красноты не было?
Нет, ну я понимаю, удобно выбрать тулчейн, разные компиляторы — разный результат (особенно по размеру bin файла). Редко но бывает на одном что-то работает, на другом нет. Но для анализа кода? Это как? Исходники компилятора подтягивал чтобы красноты не было?
Эх, если бы в CLion, помимо диалога, компилятор можно было бы через тулчейн-файл задать, и чтобы для анализа кода именно этот компилятор использовался
Вы же про это? Я может не поняла до конца, но так и должно работать. Давайте тикет в трекере, если это не так.
Не совсем.
Это работает и сейчас, и через -D, и если указать в CMakeLists.txt до объявления проекта. Но хотелось бы, чтобы в диалоге toolchains можно было указать не только пути к компиляторам, а собственно такой файл. И чтобы CLion учитывал, что за компилятор: например, при отключении предупреждений. Сейчас вставляются прагмы clang, и в проектах под gcc приходится добавлять --warn-no-unknown-pragmas.
Это работает и сейчас, и через -D, и если указать в CMakeLists.txt до объявления проекта. Но хотелось бы, чтобы в диалоге toolchains можно было указать не только пути к компиляторам, а собственно такой файл. И чтобы CLion учитывал, что за компилятор: например, при отключении предупреждений. Сейчас вставляются прагмы clang, и в проектах под gcc приходится добавлять --warn-no-unknown-pragmas.
Про отключение предупреждений — это бага.
хотелось бы, чтобы в диалоге toolchains можно было указать не только пути к компиляторам, а собственно такой файл
В смысле UI какой-то иметь? Не очень понятно
Нет, UI и сейчас есть. Иметь возможность вместо этого UI выбрать toolchain-файл, чтобы из него сразу все подхватывалось. Уж если в основе CMake — надо иметь возможность все делать cmake way: правильно подключать весь инструментарий, набор кастомных таргетов и т.д. По-моему так! (С)
Погодите. Так а что мешает в настройках указать этот toolchain файл через -D? Что-то я торможу видимо.
Это не отменит необходимость задать компилятор в диалоге, а просто «перезапишет» его.
Задать toolchain для cmake'а можно разными путями, все работают. И при сборке будет использовано именно то, что напрямую задано cmake. Но в диалоге toolchain тоже ведь что-то введено.
Зачем вообще существует диалог toolchain, зачем указывать компиляторы и т.д.? На что это влияет? Задает toolchain по умолчанию? Вроде это задается для каждого проекта… И почему возможна ситуация, когда проект собирается одним компилятором, в настройках проекта CLion указан другой, а анализ кода производится… хм…
Задать toolchain для cmake'а можно разными путями, все работают. И при сборке будет использовано именно то, что напрямую задано cmake. Но в диалоге toolchain тоже ведь что-то введено.
Зачем вообще существует диалог toolchain, зачем указывать компиляторы и т.д.? На что это влияет? Задает toolchain по умолчанию? Вроде это задается для каждого проекта… И почему возможна ситуация, когда проект собирается одним компилятором, в настройках проекта CLion указан другой, а анализ кода производится… хм…
Toolchain файл через -D приоритетнее настроек в диалоге. Но многим пользователям удобнее именно в IDE настраивать. Возможно какой-то экспорт/импорт настроек между двух источников имел бы смысл.
Через -D — это прямое указание cmake в обход всего CLion'а, последний тут вообще остается простой запускалкой, можно и во встроенном терминале все сделать). Мне кажется, что должно быть или через поля диалога, или через toolchain-файл, как альтернативы. И иметь возможность параметры диалога расширить всем тем, что доступно в toolchain-файле. Все-таки CLion — инструмент для профессионалов. Кстати, до его выхода я cmake не пользовался практически. CLion заставил начать разбираться). Так что спасибо за инструмент!
Спасибо, я так понимаю первый шаг в направлении микроконтроллеров сделан. Если со временем его доведут до нормального состояния, то можно будет использовать в университете для обучения, а то сейчас приходится использовать Ломанные версии IAR 8.20, что не совсем правильно.
Sign up to leave a comment.
JetBrains CLion для микроконтроллеров