Как стать автором
Обновить

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

НЛО прилетело и опубликовало эту надпись здесь
Вообще имхо выглядит несколько костыльно. Необходимость ставить левый (MSVC/MinGW) компилятор, плюс завязывать проектный CMakeLists.txt на то, что нравится CLion.
У меня один из проектов делается на CMake, тулчейн указывается в отдельном cmake файле. Так вот, в такой конфигурации CLion вскидывает лапки со словами «я не знаю такого тулчейна» и отказывается дальше индексировать проект.
Приходится тупо `File->New CMake project from sources`, и делать это снова и снова при добавлении нового файла в проект.

А вот работать в ней действительно удобно. Индекс у них лучший (если не глючит и нормально отрабатывает на весь проект)
Строго говоря, «левый» компилятор не нужен. Нужно GNU окружение и gdb.
Так и чего, зачем GNU окружение, к примеру, мне, компилирующему исключительно в Tasking/Diab (или, как в статье — IAR)?
Diab не поддерживается. Gnu окружение для make/cmake. Увы, пока так, но мы работаем над улучшением.
AFAIK, Qt Creator должен работать с IAR «из коробки» в связке в Qbs.
Отличная статья, спасибо!
Пара вопросов:
1) Почему вы студентам не предлагаете Кейл? Я не похоливарить сейчас хочу на тему «Великой Тройки», а конкретно про студентов. Сертифицированность компилятора для них вряд ли имеет значение, а в части удобства работы с МК у него конкурентов нет ИМХО (с IAR-ом все понятно, а Atollic True Studio и аналоги мало того что тормозные, так еще и в gdb приходится макаться). Ну и он бесплатный до 32кБ, ИХМО достаточно. Ну и вероятность поработать с ним в отрасли весьма высокая.
2) Поясните убогим — файл startup.cpp откуда берется? Понятно, что его можно и самому при наличии знаний написать (оглядываясь на готовые примеры), но вот конкретно тут он откуда?
3) И еще вопрос от убогих — не очень понял из поста, где и как вы переопределили _write, очевидно ITM_SendChar должен быть в основе всего, а как дальше настраивается вывод вот туда вниз?

Спасибо, рад что полезная статья.


1) Почему вы студентам не предлагаете Кейл?

Исторически так сложилось, что мы всегда на работали на IAR, в связи с тем, что это хороший, надежный проверенный временем компилятор, имеющий сертификат безопасности. Еще работали с GreenHill, по той же причине, но потом остановились на одном IAR. Поэтому просто проще было давать студентам IAR, который я знаю и использую, тем более, что 32 кБайтной бесплатной версии им за глаза хватает.
Но мое мнение в приницпе без разницы какой компилятор можно и с GCC тоже самое сделать. Если не использовать расширения неподдерживаемые стандартом, а сейчас мы так и стараемся делать, то точно без разницы. Код можно запускать хоть на каком компиляторе, там все отличия в основном в этом startup, где используются как раз трюки компиляторов, типа инициализации стека или __weak директивы. Весь остальной код к компилятору не привязан вообще.


За границей, по моему ощущению, IAR довольно популярный, у нас не очень потому что платный, но в Европах и Америках очень распространен, особенно в разработке для промышленных применений, автомобильной, медицинской, — там где надежность нужна.


2) Поясните убогим — файл startup.cpp откуда берется? Понятно, что его можно и самому при наличии знаний написать (оглядываясь на готовые примеры), но вот конкретно тут он откуда?

Файл startup.cpp, самописный (за основу взят Сишный из IAR примеров) Но можно использовать startup сишний или ассемблеровский, который есть в CMSIS для IAR или Cube — не важно какой, главное стек проинициализировать, таблицу векторов, инициализацию глобальных и статических переменных, fpu ну и main() вызвать. Просто раз уж все на С++, то и стартап тоже :), хотя там используется соглашение об вызовах сишное, но зато компилятор С++ его компилирует, а не Сишный.


3) И еще вопрос от убогих — не очень понял из поста, где и как вы переопределили _write, очевидно ITM_SendChar должен быть в основе всего, а как дальше настраивается вывод вот туда вниз?

функция __write() определяется в библиотеке dlib, без ключей компилятора она не подключается и соответственно нет и её имплементации. Когда добавляешь ключ к строке компилятора --dlib_config=normal, ну или full — появляется и её имплементация. См строчку
set (CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} --dlib_config=normal --no_inline")


PS. Да добавлю с помощью semihosting вы перенаправляете вывод в отладочный интерфейс, вначале в настройках линкера, чтобы он подключил нужную реализацию


set(CMAKE_CXX_LINK_FLAGS "--semihosting --config ${LINKER_SCRIPT}")


а затем еще и OpenOCD, чтобы он активировал эту функцию у отладчика:


monitor arm semihosting enable

Исторически так сложилось, что мы всегда на работали на IAR


Этой практики вероятно и следовало придерживаться, просто если вы решили взять что-то более красивое, то кажется Кейла было бы достаточно, и это все еще было бы отраслевое решение. Но это сугубо ИМХО.

функция __write() определяется в библиотеке dlib, без ключей компилятора она не подключается и соответственно нет и её имплементации


Ну ок, а внутри нее-то какая реализация?
Ну ок, а внутри нее-то какая реализация?

Реализация от IAR из dlib в зависимости от ключей, линкер может подрубить нужную.
Вы в принципе и сами можете её переопределить, если хотите. Но я не стал :)


PS. Да добавлю с помощью semihosting вы перенаправляете вывод в отладочный интерфейс, вначале в настройках линкера, чтобы он подключил нужную реализацию
set(CMAKE_CXX_LINK_FLAGS "--semihosting --config ${LINKER_SCRIPT}")
а затем еще и OpenOCD, чтобы он активировал эту функцию у отладчика:
monitor arm semihosting enable
Вот, я это и спрашивал — что там под капотом, оказалось семихостинг. Да, в этом случае вывод сам по себе идет в консоль отладчика. В этом смысле с выводом через ITM больше тонкостей, он как-то в ATS у меня вообще отказался работать, приходилось отладочную консоль в Link Utility запускать.
НЛО прилетело и опубликовало эту надпись здесь
Не рекламы ради, но в QtCreator это все делается быстрее и проще. ;)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации