Комментарии 25
Я правильно понимаю, что это интерфейс для GDB с небольшим количеством удобств? Если так, то почему он стоит 64 евро и нет ли бесплатных решений?
1. А оно работает с Express студией или только с полноценной?
2. Вообще то не вижу вообще никаких проблем настроить себе буквально тоже самое и без всяких плагинов. Т.е. использование gcc (и не только для кросскомпиляции под arm, но и например вообще с MinGW) в VS вполне настраиваемо. Собственно там вообще единственная проблема в интеграции с отладчиком, а всё остальное делается за пару минут.
3. Если вы хотите полноценное автодополнение, подсветку и рефакторинг C++ в студии, то обязательно ставьте VisualAssist — только он даёт что-то более менее приемлемое. Хотя на мой взгляд аналогичные возможности в Netbeans и Eclipse всё равно сильнее.
2. Вообще то не вижу вообще никаких проблем настроить себе буквально тоже самое и без всяких плагинов. Т.е. использование gcc (и не только для кросскомпиляции под arm, но и например вообще с MinGW) в VS вполне настраиваемо. Собственно там вообще единственная проблема в интеграции с отладчиком, а всё остальное делается за пару минут.
3. Если вы хотите полноценное автодополнение, подсветку и рефакторинг C++ в студии, то обязательно ставьте VisualAssist — только он даёт что-то более менее приемлемое. Хотя на мой взгляд аналогичные возможности в Netbeans и Eclipse всё равно сильнее.
Если не затруднит, не могли бы Вы написать статейку «для чайников» по настройке VS для работы с STM32?
Мы уже давно ушли с VS (причём при этом продолжили использовать их компилятор и вот только недавно ушли и с него), т.к. её возможности (даже вместе с VA) по работе с кодом уступают конкурентам (Eclipse и Netbeans). Причём это речь даже не про микроконтроллёры, а про большие десктопные приложения.
Однако я могу без проблем описать как настроить VS для работы скажем с MinGW (gcc для windows приложений).
Что касается VS и stm32, то вот прямо с такой парой я дел не имел, так что с ходу не скажу. Но очевидно, что единственное отличие от варианта выше, будет в настройке процесса отладки. Для варианта выше можно взять просто обычный конвертер в формат pdb (типа cv2pdb) и использовать прямо отладчик из VS. Для embedded программирования это конечно не пойдёт, так там обычно просто выставляется интерфейс удалённого gdb. Соответственно тогда надо или какой-то другой откладчик (а тогда какой смысл в VS вообще?) или же ставить некого посредника между ними (типа решения в данной статье или например WinGDB).
Однако я могу без проблем описать как настроить VS для работы скажем с MinGW (gcc для windows приложений).
Что касается VS и stm32, то вот прямо с такой парой я дел не имел, так что с ходу не скажу. Но очевидно, что единственное отличие от варианта выше, будет в настройке процесса отладки. Для варианта выше можно взять просто обычный конвертер в формат pdb (типа cv2pdb) и использовать прямо отладчик из VS. Для embedded программирования это конечно не пойдёт, так там обычно просто выставляется интерфейс удалённого gdb. Соответственно тогда надо или какой-то другой откладчик (а тогда какой смысл в VS вообще?) или же ставить некого посредника между ними (типа решения в данной статье или например WinGDB).
А можно поподробней о возможностях (первая часть поста)? Не холивара ради, а исключительно в познавательных целях.
Мы пробовали очень много различных инструментов (и не только IDE, т.к. по сути от IDE нам нужен только редактор — остальное мы реализуем отдельными, более эффективными инструментами) для работы с кодом на C++. По итогам вышло, что полноценно парсить C++ код (т.е. со всеми шаблонами, макросами и прочими прелестями) сейчас умеют всего 3 инструмента и наверное не особо удивительно, что это оказались главные «мостро-ide»: Netbeans, Eclipse и VisualStudio+VisualAssist.
Насколько я знаю, ещё Kdevelop имеет полноценный парсер, но это только под Linux'ом. Плюс Jetbrains обещали этой осенью выпустить полноценную C++ IDE и возможно (судя по показанным отрывкам), что она станет лучше C++ IDE. Однако пока её нет, так что выбор сводится к одному из 3-ёх вышеуказанных монстриков.
Если же выбирать из этих трёх вариантов, то тут уже начинают играть роль всякие мелочи. Типа количества сущностей для подсветки синтаксиса, нюансов в форматирование кода, возможностей подсказки/навигации, рефакторинга. Самый богатый набор всего этого у Eclipse'a. Самый бедный у VS (даже с VA, а без него вообще мрак). Но у Eclipsa нам не понравились некоторые архитектурные нюансы самого приложения, не связанные с C++, плюс общая перегруженность интерфейса и настроек. Поэтому мы предпочли Netbeans — у него набор функций практически такой же как у Eclipse, но при этом более простая архитектура и удобный интерфейс. Это так, если вкратце. )
Насколько я знаю, ещё Kdevelop имеет полноценный парсер, но это только под Linux'ом. Плюс Jetbrains обещали этой осенью выпустить полноценную C++ IDE и возможно (судя по показанным отрывкам), что она станет лучше C++ IDE. Однако пока её нет, так что выбор сводится к одному из 3-ёх вышеуказанных монстриков.
Если же выбирать из этих трёх вариантов, то тут уже начинают играть роль всякие мелочи. Типа количества сущностей для подсветки синтаксиса, нюансов в форматирование кода, возможностей подсказки/навигации, рефакторинга. Самый богатый набор всего этого у Eclipse'a. Самый бедный у VS (даже с VA, а без него вообще мрак). Но у Eclipsa нам не понравились некоторые архитектурные нюансы самого приложения, не связанные с C++, плюс общая перегруженность интерфейса и настроек. Поэтому мы предпочли Netbeans — у него набор функций практически такой же как у Eclipse, но при этом более простая архитектура и удобный интерфейс. Это так, если вкратце. )
Ясно, спасибо. будем глядеть в сторону Эклипса…
1. только с полноценной
2. Отладчик, реализация функций построения проекта, структуры языка — не так уж все и просто. Если задаться целью «о, я заюзаю в качестве компилятора gcc и буду крут» — то да, вопросов нет. А если в качестве цели телодвижений будет «построить рабочую среду», то тут уже начинает выясняться, что тыкнуть две кнопки и редиректнуть компилятор — это далеко не все
3. Спасибо, обязательно посмотрю. Но пока что надо базово понять — оно нам надо или «CooCox и не мучиться»
2. Отладчик, реализация функций построения проекта, структуры языка — не так уж все и просто. Если задаться целью «о, я заюзаю в качестве компилятора gcc и буду крут» — то да, вопросов нет. А если в качестве цели телодвижений будет «построить рабочую среду», то тут уже начинает выясняться, что тыкнуть две кнопки и редиректнуть компилятор — это далеко не все
3. Спасибо, обязательно посмотрю. Но пока что надо базово понять — оно нам надо или «CooCox и не мучиться»
Да, надо много чего настроить, чтобы получить полноценную среду, но всё кроме отладчика делается тривиально. Причём опять же проблема только с отладчиком для ситуации с кросскомпиляцией и удалённой отладкой (т.е. как раз случай stm32), т.к. там железо выдаёт именно gdb интерфейс.
Насчёт сравнения с CooCox… Вообще то Eclipse и Netbeans даже посильнее чем VS по работе с кодом на C++. A CoIDE основан на Eclipse, но при этом каком-то обрезанном. При этом имеет сильную поддержку именно работы с микроконтроллёрами. В общем по сумме параметров не вижу особого смысла в VS.
Насчёт сравнения с CooCox… Вообще то Eclipse и Netbeans даже посильнее чем VS по работе с кодом на C++. A CoIDE основан на Eclipse, но при этом каком-то обрезанном. При этом имеет сильную поддержку именно работы с микроконтроллёрами. В общем по сумме параметров не вижу особого смысла в VS.
CooCox не поддерживает плюса
Куда он денется то? ))) Компилятор (gcc) умеет, редактор (Eclipse) умеет… ) А CoIDE — это по сути набор скриптов вокруг Eclipse, так что без проблем его заставить. Основная ценность там скорее в наборе информации о конкретных MK и удобном её представление. Кстати, как раз поэтому если не требуется подобное удобство, то действительно проще взять одну из обычных IDE и всё.
А чем оно лучше, чем eclipse+gcc? И вообще, какие есть еще решения? Можно ли к примеру приделать это дело к qbs и соответственно к QtCreator, ведь по сути в нем нужно лишь обеспечить поддержку нужного тулчейна (что можно написать в qbs) да приделать деплоймент на устройство. Или все сложнее?
Keil это не только IDE там еще и отладочных средств дофига напихано. Средствами GDB можно сделать «осциллограф» из переменной, например?
Keil убог, уж извините. Если рассматривать данную IDE в основном в качестве блокнота, в котором ты пишешь исходник, или, к примеру, в качестве курса молодого бойца «смотри, сосунок, вот так твои деды программировали» — тогда да. Но в современном мире скорость разработки встраиваемого ПО так же начинает играть немаловажную роль. Да, не в такой степени, как прикладного, но при этом тенденция на лицо. А эти средства не помогают в основной деятельности — создании кода, а наоборот — делают работу аскетичной и унылой, как говно мамонта.
Понимаю, что нахватаюсь минусов, но Keil. IAR — унылы и убоги. Да, решают задачу. Да, предоставляют инструменты. Но оставляют после себя огромное пожелание — пусть дети разработчиков этого некрофилического непотребства работают в нем по 12 часов до конца жизни.
Понимаю, что нахватаюсь минусов, но Keil. IAR — унылы и убоги. Да, решают задачу. Да, предоставляют инструменты. Но оставляют после себя огромное пожелание — пусть дети разработчиков этого некрофилического непотребства работают в нем по 12 часов до конца жизни.
В эмбедде 80% времени занимает реалтайм отладка, остальное это собственно написание. Поэтому совершенно не принципиально в чем писать код. Подсветка кода есть и ладненько. Зато возможность на лету эмулировать периферию, прогонять отладчиком мгновенно, логи переменных вести и смотреть их в динамике это ценно и без этого никуда. Собственно на этом и специализируется Keil за это его и любят.
Напишите и отладьте один проект под мк и вы забудете про автодополнения и подсветку синтаксиса. Это не более чем фантики в embedded разработке. Реальные проблемы там совсем в другом…
еврики, триалка, деплоит, бряки — всё это можно было бы простить, если б хотя бы были показаны окошки отладчика.
А без них все эти фантики и рядом не лежат с кейлом
А без них все эти фантики и рядом не лежат с кейлом
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
STM32+Visual Studio