Да, бываю у них неприятные баги, сам как-то раз откатывался на предыдущую версию, пока не исправили. А по нехватке памяти на 1к строчек кода, звучит реально странно, думаю может тоже баг какой-то был? Вот буквально вчера открывал большой проект, который раньше выжирал более 70! Гиг оперативки и закрывался. Вот так хреново в этом проекте исходники организованы. Но на последнем CLion даже открылось, и даже не подвисло!, а предложило прервать парсинг, т.к. долго думало. Но в итоге даже подсветка синтаксиса заработала :)
А, простите, не сразу понял о чем речь. Да, согласен, поддержки трейсинга и всяких Arm MTB/ETB там пока нет, но вроде пишут, что уже запланирована реализация. С другой стороны, для нормальной поддержки всего этого нужен какой нибудь Lauterbach Trace32 с Trace Extensions который стоит как самолет. Ну или хотя бы Segger J-Trace Pro который стоит как крыло от самолета. Иначе вся эта поддержка будет в лучшем случае через SWO или даже через тот же PC sampling, который все равно пусть и на чуть чуть, но приостанавливает выполнение кода. А если юзать Trace Buffer, то для полноценного тресинга это все надо на очень высокой скорости из микроконтроллера забирать, а могут это только довольно дорогие железки, про которые я выше писал.
А вообще, я тут писал в поддержку CLion скорее потому, что для меня, по удобству написания кода, он имхо превосходит Visual Studio, но при этом кросплатформенный и проекты можно делать в одной IDE под Windows, MacOS и Linux. А тут написали, что для Embedded он не подходит, вот и поделился опытом такого использования)
Поддержка OpenOCD в CLion уже давно из коробки. По сути это просто GDB сервер. Я например пользуюсь отладчиком Segger JLink, у них своя реализация GDB Server, подключается элементарно. Короче нет в CLion никакой проблемы с отладкой прямо на железе.
Да, с памятью есть проблема, но вызвана она как раз тем, что CLion, это не редактор кода, а полноценная IDE, но в последних билдах стало сильно лучше. Ну и к слову сказать, я проблем с нехваткой памяти CLion не ловил даже на довольно крупных проектах. Обычно проблемы возникают при халатном отношении к включению заголовочных файлов в одну единицу трансляции. Есть такой стиль программирования, когда в один С или С++ файл включено по сути пол проекта, а то и весь и никакой инкапсуляции на уровне хидеров.)) К слову, когда компилятор такие файлы собирает, он он жрет не намного меньше памяти, чем тот же CLion, только компилятору можно эту память тут же освободить, а IDE вынуждена все это синтаксическое дерево по каждой! единице трансляции держать в памяти. Ну и написан CLion на Java, еще плюсом память видимо юзается на структуры явовского GC.
Странно такое слышать про CLion, из моего более чем 15 летнего опыта, могу сказать, что CLion, наверное лучшая IDE, в том числе и для Embedded разработки, нихочу никого обидеть, но возможно проблема в не очень хорошем знании этого инструмента? Я использую CLion в Embedded разработке уже лет 10, а тогда там поддержкой Embedded и не пахло. Но это не стало препятствием к полноценной отладке прямо в CLion через Remote GDB Server. Что говорить про последние версии CLion, в которых уже есть более или менее нормальная поддержка Embedded разработки из коробки. А вот что реально можно назвать убожеством, так это почти все среды разработки от производителей микроконтроллеров. В лучшем случае это будет немного допиленный кривыми руками говно Eclipse. Недалеко ушел и тот же IAR или какой-нибудь Keil, это вообще какие то виндовые блокноты которые по недоразумению назвали IDE. А Visual Studio Code в принципе не плох, но это имхо все равно не полноценная IDE, а все таки скорее редактор кода на стероидах, т.е. разные весовые категории с CLion. Правда сказать, последний раз я изучал рынок IDE больше года назад, возможно там что-то изменилось, но что-то я сомневаюсь.
А по нехватке памяти на 1к строчек кода, звучит реально странно, думаю может тоже баг какой-то был? Вот буквально вчера открывал большой проект, который раньше выжирал более 70! Гиг оперативки и закрывался. Вот так хреново в этом проекте исходники организованы. Но на последнем CLion даже открылось, и даже не подвисло!, а предложило прервать парсинг, т.к. долго думало. Но в итоге даже подсветка синтаксиса заработала :)
С другой стороны, для нормальной поддержки всего этого нужен какой нибудь Lauterbach Trace32 с Trace Extensions который стоит как самолет. Ну или хотя бы Segger J-Trace Pro который стоит как крыло от самолета. Иначе вся эта поддержка будет в лучшем случае через SWO или даже через тот же PC sampling, который все равно пусть и на чуть чуть, но приостанавливает выполнение кода. А если юзать Trace Buffer, то для полноценного тресинга это все надо на очень высокой скорости из микроконтроллера забирать, а могут это только довольно дорогие железки, про которые я выше писал.
А вообще, я тут писал в поддержку CLion скорее потому, что для меня, по удобству написания кода, он имхо превосходит Visual Studio, но при этом кросплатформенный и проекты можно делать в одной IDE под Windows, MacOS и Linux. А тут написали, что для Embedded он не подходит, вот и поделился опытом такого использования)
К слову, когда компилятор такие файлы собирает, он он жрет не намного меньше памяти, чем тот же CLion, только компилятору можно эту память тут же освободить, а IDE вынуждена все это синтаксическое дерево по каждой! единице трансляции держать в памяти. Ну и написан CLion на Java, еще плюсом память видимо юзается на структуры явовского GC.
Я использую CLion в Embedded разработке уже лет 10, а тогда там поддержкой Embedded и не пахло. Но это не стало препятствием к полноценной отладке прямо в CLion через Remote GDB Server. Что говорить про последние версии CLion, в которых уже есть более или менее нормальная поддержка Embedded разработки из коробки.
А вот что реально можно назвать убожеством, так это почти все среды разработки от производителей микроконтроллеров. В лучшем случае это будет немного допиленный кривыми руками говно Eclipse. Недалеко ушел и тот же IAR или какой-нибудь Keil, это вообще какие то виндовые блокноты которые по недоразумению назвали IDE.
А Visual Studio Code в принципе не плох, но это имхо все равно не полноценная IDE, а все таки скорее редактор кода на стероидах, т.е. разные весовые категории с CLion.
Правда сказать, последний раз я изучал рынок IDE больше года назад, возможно там что-то изменилось, но что-то я сомневаюсь.