Comments 67
Большое вам спасибо за проделанную работу!
Можно будет попробовать нормальную IDE вместо Keil. Скажите, а просмотр регистров и памяти доступен?
Хотя из нормальных IDE недавно нашел ARM'овский DS-5 Development Studio (на базе эклипса), правда ограничения в бесплатной версии.
А ARM Compiler можно прикрутить? Он, пишут, более оптимизированный код генерирует.
раньше юзал эклипс, но настраивается тоже муторно, + жрет память дико — потому привозврате к stm32 решил не разворачивать его, а попробовать qt designer, и в принципе не жалею.
Да я в CubeMX не использую, так что на проблему меньше, видимо. HAL как-то не нравится особо. Под те контроллеры, что использую, есть SPL и она как-то больше по душе.
Если уж на то пошло, то я не заметил, чем HAL так уж прямо хуже SPL, оба так себе, мда. А про драйвер USB вообще слов нет. В последних версиях куба появилась альтернатива HAL — нечто под названием LL(low level). Я эту штуку еще не трогал, но вроде она не такая тяжеловесная как HAL.
Положа руку на сердце, я не могу сказать что в его нонешнем виде CLion идеален для эмбедов, многого не хватает, в частности просмотра памяти. Но я знаю, что команда заинтересована в развитии этого направления, и работа по написанию недостающего идет. Можно порыться у них багтрекере, поставить плюсики на самые важные фичи, это может ускорить дело. У меня в планах есть реализация поддержки SVD файлов, тогда и регистры будут.
Про ARM Compiler не знаю. Пока что в качестве системы сборки поддерживается только Cmake, который, в свою очередь, не знает ничего про arm compiler. Думаю, что теоретически можно прикрутить, но уйдет много крови.
ЗЫ. Простите, баловство. Нужно отличать красивый редактор от IDE.
Я тоже хочу и даже планирую. И это не баловство.А сентенция насчет редактора мне непонятна. С моей точки зрения силайон куда в большей степени IDE, чем кейл или иар.
Чисто с точки зрения написания кода: да. С точки зрения всего остального: спорно. Для написания десктопного приложения нужно как минимум в чём-то делать формы (меня не вдохновляет их руками прописывать). Для работы с МК нужен удобный инструмент для просмотров регистров и памяти отлаживаемой железки.
Сама компания не стремиться развивать это направление, я пробовал выйти на представителей 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 по сути.
По поводу намерений компании — у меня ровно обратное впечатление, я общаюсь с ребятами, с их стороны явно есть очень существенный интерес. Ну а к HR ломиться в такой ситуации точно бесполезно.
По поводу OpenOCD — в чем разница между «серьезно» и «несерьезно»? У меня openocd вполне работает. Чем сеггер так невыносимо прекрасен, я так и не понял, а вот глюки сеггеровского gdb сервера я видел своими глазами. Причем в openocd можно и самому покопаться, а segger закрыт. Если Вы обратите внимание, мой первый блог-пост был именно про сеггер, но мне неудобно пользоваться отдельно дебаггером, отдельно ide, да и лицензионные ограничения опять же. Я занимаюсь embedded ради хобби, и покупать сеггеровскую лицензию за сотни долларов мне просто дороговато.
Да, кейл и иар — ужас, к эклипсу и его производным у меня идиосинкразия, а средами от JB я пользуюсь этак уже лет 15, и мне они нравятся. У меня в планах есть поддержка SVD файлов, после чего работа с периферией в отладчике будет подобна кейловской или сеггеровской, и я точно знаю, что прямо сейчас в в разработке у команды силайона несколько важных фичей, важных для embedded. Так что все только начинается.
Основная фишка сиггера — это профессиональное оборудование, которое поддерживает пожалуй почти все контроллеры. Один программатор для разных девайсов.
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". Должно быть полезно.
Embedded является одним из приоритетных направлений, но пока решаем базовые общие задачи (типа remote GDB, remote dev, до hex view вот руки наконец дошли) и ищем людей на embedded задачи. У нас вот на дебаггере, например, до сих пор один человек. Этого явно мало, ведь отладка на платах потребует существенных вложений наших ресурсов.
А вот с поддержкой, консультированием, отладкой на платах я бы мог помочь, ибо на руках есть и разные программаторы, и платы отладочные. Из (если мы говорим о armX, cmX) eсть stm, nxp, at91, nrf и другие. Можно протестировать. Время есть свободное. Территориально я в СПБ нахожусь.
Или даже коммерческая IDE для Rust с запчастями от CLion (типа того же дебаггера и вот этих вот ваших специфичных фич для embedded).
В IntelliJ IDEA Community можно просто открыть директорию с Rust-проектом и всё работает автоматически.
CLion открывать отказывается, его нужно тщательно уговаривать (кажется, import from sources работает). И даже после уговоров всё равно разные «хвосты» вылазят, типа ошибок unknown module: JAVA_MODULE, невозможности просто сделать compile, и автоматически сгенерированный CMakeLists.txt (который не нужен).
Вот сейчас у меня все файлы в CLion серенькие. Я так думаю, потому что он считает, что они не принадлежат проекту.
Ну и на здоровье. Куб на джаве написан, его экзешник для винды — явовский архив. Так что должен много где работать.
Просто под мак нет ничего дельного…
Да, под маком все работает. Я только что получил донат от счастливого маковода.
Я примерно так же делал по началу. Но с плагином все мегабыстро стало.
Эх, если бы в CLion, помимо диалога, компилятор можно было бы через тулчейн-файл задать, и чтобы для анализа кода именно этот компилятор использовался, да выбор из набора типовых тулчейн-файлов…
Через тулчайн переимпорт проекта у меня _может_ случаться довольно часто, если я экспериментирую с конфигурацией железок.
Нет, ну я понимаю, удобно выбрать тулчейн, разные компиляторы — разный результат (особенно по размеру bin файла). Редко но бывает на одном что-то работает, на другом нет. Но для анализа кода? Это как? Исходники компилятора подтягивал чтобы красноты не было?
Эх, если бы в CLion, помимо диалога, компилятор можно было бы через тулчейн-файл задать, и чтобы для анализа кода именно этот компилятор использовался
Вы же про это? Я может не поняла до конца, но так и должно работать. Давайте тикет в трекере, если это не так.
Это работает и сейчас, и через -D, и если указать в CMakeLists.txt до объявления проекта. Но хотелось бы, чтобы в диалоге toolchains можно было указать не только пути к компиляторам, а собственно такой файл. И чтобы CLion учитывал, что за компилятор: например, при отключении предупреждений. Сейчас вставляются прагмы clang, и в проектах под gcc приходится добавлять --warn-no-unknown-pragmas.
хотелось бы, чтобы в диалоге toolchains можно было указать не только пути к компиляторам, а собственно такой файл
В смысле UI какой-то иметь? Не очень понятно
Задать toolchain для cmake'а можно разными путями, все работают. И при сборке будет использовано именно то, что напрямую задано cmake. Но в диалоге toolchain тоже ведь что-то введено.
Зачем вообще существует диалог toolchain, зачем указывать компиляторы и т.д.? На что это влияет? Задает toolchain по умолчанию? Вроде это задается для каждого проекта… И почему возможна ситуация, когда проект собирается одним компилятором, в настройках проекта CLion указан другой, а анализ кода производится… хм…
JetBrains CLion для микроконтроллеров