В сети есть множество примеров ( в том числе на этом сайте ) как начать использовать Eclipse совместно с инструментами GNU для программирования микроконтроллеров. Что же касается эффективной работы в Eclipse , то на эту тему материала гораздо меньше. А тот материал, который можно найти на просторах интернета, в основном касается версии Eclipse для разработки Java- программ.

Данная статья призвана исправить положение дел, поскольку новичкам в работе с Eclipse эта среда разработки часто кажется сложной и избыточной. Многие противники IDE Eclipse в качестве главного аргумента против использования этой современной интегрированной среды разработки называют ее слишком медленную работу, поскольку Eclipse полностью написана на Java и требует для работы виртуальную машину .

Ввиду того факта, что современные ПК имеют избыточную для большинства пользователей производительность, использование виртуальной машины не должно заметно влиять на скорость работы Eclipse.

Для начала рассмотрим как можно повысить скорость работы нашей среды разработки . При запуске Eclipse из командной строки можно передать параметры . Один из таких параметров может указать используемый средой разработки объем оперативной памяти.

Следующая командная строка запускает Eclipse с объемом используемого ОЗУ 2048 Мбайт.
В моем ноутбуке установлено 4 ГБ оперативной памяти, поэтому выделить половину для работы интегрированной среды разработки мне не жалко. Вам придется самостоятельно оценить объем памяти , который можно будет отдать Eclipse исходя из общего объема ОЗУ, установленного в ПК.

При запуске Eclipse появляется окно выбора используемого рабочего пространства. Программа будет быстрее запускаться, если указать в окне ‘Workspace Launcher’ или в командной строке рабочее пространство, используемое по-умолчанию.

Для автоматического запуска Eclipse с заданными параметрами можно воспользоваться командным файлом run_eclipse.bat.

Стиль работы в Eclipse может быть различным и зависит от личных предпочтений каждого отдельного программиста. Одни считают утомительным разрабатывать Makefile для каждого нового проекта или предпочитают отдать полный контроль над проектом интегрированной среде разработки. Другие наоборот предпочитают иметь полный контроль над процессом компиляции своих программ, используя собственные скрипты для сборки проекта.

Если вы относитесь к первой категории программистов, то в вашем распоряжении есть GNU ARM Eclipse Plug-in. В крайнем случае можно воспользоваться make — файлами из чужих проектов, внося незначительные изменения в каждом новом проекте.

GNU ARM Eclipse Plug-in предоставляет возможность создавать как приложения, так и статические библиотеки. Если ваш проект очень большой, то имеет смысл разбить его на несколько частей, оформив в виде статических библиотек.
Статическая библиотека представляет собой набор объектных файлов, сохраненных в одном файле, название которого всегда (для GCC) начинается с префикса lib и имеет расширение .a.

Хочу обратить ваше внимание на использование горячих клавиш при редактировании исходного текста программы в Eclipse.
Бывает необходимость разобраться в сторонней библиотеке или проекте. Функции и макросы приходится искать в разных файлах. На этот случай существует волшебная комбинация клавишь : нажав клавишу Ctrl , удерживаешь ее и одновременно кликаешь кнопкой мыши по интересующей функции или макросу. Eclipse автоматически переходит в файл, где определена данная функция или макрос.

Зная название элемента (функции, структуры, макроса и т.д) можно быстро его найти , нажав комбинацию клавиш Ctrl+Shift+T. Появится диалоговое окно, в котором необходимо ввести название искомого элемента.

Для быстрого поиска всех вхождений элемента (например нужно найти все места вызова функции) можно воспользоваться комбинацией клавиш Ctrl+Shift+G. Чтобы воспользоваться этой возможностью нужно выделить элемент и нажать указанную комбинацию клавиш.

Если необходимо развернуть окно с исходным текстом программы до максимального размера, то можно воспользоваться для этого комбинацией клавиш Ctrl+m. При необходимости закрыть все открытые в редакторе кода окна с исходными файлами поможет применение комбинации клавиш
Ctrl+Shift+F4.

Часто бывает ситуация, когда код оставляется незавершенным ввиду наличия более срочных задач. В таких случаях в незаконченных местах можно поставить такой комментарий :

Тогда можно будет быстро найти незавершенные участки кода в нижнем окне Eclipse на вкладке Tasks.

Если необходимо закомментировать часть кода (например при отладке) , то не обязательно это делать вручную. Можно выделить мышкой ту часть кода, которую нужно закомментировать, и нажать комбинацию клавиш Ctrl+/ . Чтобы раскомментировать код необходимо проделать аналогичные действия над закомментированным кодом.

В случае опечатки вы всегда можете отменить последние действия нажатием комбинации клавиш Ctrl + Z (Undo), или вернуть обратно отмененный код нажатием на Ctrl+Y (Redo).

Все доступные в текущем окружении комбинации клавиш можно просмотреть, нажав на комбинацию из клавиш Ctrl + Shift + L.

Для экономии времени на написание документации к вашему коду используйте инструмент Doxygen, который доступен в Eclipse в виде плагина. Предварительно необходимо установить программу Doxygen на свой компьютер.

Для документирования кода с помощью Doxygen необходим Doxyfile , в котором находятся все необходимые для автоматического генерирования документации настройки. Если его нет в вашем проекте, вам будет предложено генерировать этот файл автоматически.

Автоматически сгенерированный Doxyfile появится в директории вашего проекта. Кликнув на нем откроется форма для заполнения этого конфигурационного файла на двух вкладках Basic и Advanced.

Структуру документации можно задать внутри исходного кода, а точнее в комментариях к коду, придерживаясь определенного синтаксиса Doxygen. Если вы использовали библиотеку периферии для микроконтроллеров STM32, то видели в комментариях странные записи, которые предназначены для автоматического создания документации.

Для контроля версий разрабатываемого программного обеспечения вы можете воспользоваться одной из систем контроля версий. В базовой комплектации Eclipse установлен плагин для использования CVS , но ничто не запрещает вам самостоятельно установить плагин для своей любимой системы контроля версий ( например git или SVN).

Научится использовать систему контроля версий в Eclipse можно из обучающего видеоролика на сайте Atollic . Ролик демонстрирует использование SVN в Atollic True Studio. Как минимум 90 % информации будет справедливо и для Eclipse.

Еще хочу сказать несколько слов о возникающих в среде Eclipse ошибках. Наиболее распространенная из них сопровождается сообщениями «BLA-BLA-BLA could not be resolved». Это сообщение не имеет отношения к сборке проекта и означает лишь то, что Eclipse не может самостоятельно найти ту или иную функцию (структуру , макрос и т.д).
Для увеличения «зоркости» Eclipse нужно добавить пути поиска в меню Path and Symbols.

Для пользователей STM32 существует интересный Plug-in , позволяющий конфигурировать выводы микроконтроллера. Называется этот чудесный продукт MicroXplorer. Plug-in можно загрузить с сайта производителя STMicroelectronics и установить стандартным для установки Eclipse плагинов способом.

После установки этого плагина в главном меню Eclipse появится дополнительный пункт меню MicroXplorer.

MicroXplorer позволяет определить используемые выводы микроконтроллера для периферийных модулей. MicroXplorer не генерирует код автоматически (по крайней мере в версии, доступной на момент написания этой статьи).

Viewed 15390 times by 3763 viewers

Last modified: 26/10/2020

Author

Comments

Очень полезная статья 🙂 Спасибо!

Я бы дополнил инфу про очень полезную возможность при работе с makefile. Относится к вашему, цитирую: «Eclipse не может самостоятельно найти ту или иную функцию (структуру , макрос и т.д). Для увеличения «зоркости» Eclipse нужно добавить пути поиска в меню Path and Symbols.»
Можно в своём мейкфайле создать цель discovery (содержимое см. ниже). Зайти в Свойства проекта — C/C++ Build — Discovery Options.
* Поставить discovery profiles scope: configuration-wide;
* поставить все галки в окне, самая нижняя по вкусу;
* discovery profile: GCC per project scanner info profile;
* compiler invocation command: make
* compiler invocation arguments: specs_file=${plugin_state_location}/${specs_file} discovery
* нажать кнопку Clear discovered entries now: «Clear»;
В этом случае после запуска компиляции происходит автоматическое определение путей, библиотек и символов/определений проекта (ключ -D для компилятора, он же может прописываться ручками в «Paths and Symbols»), и не надо вручную дублировать дефайны из опций для компилятора с символами в закладке «Paths and Symbols».
Вот такая цель делается в makefile (кто с ними работает, в курсе что подправить):
#=======================================================
#discovery target for Eclipse parser
# если в CFLAGS есть правило для генерации файлов (.dep или .lst) — его надо
# вынести из CFLAGS в отдельный, скажем, DEPFLAGS и вставить в нужные места,
# где оно использовалось
#=======================================================
discovery_log = discovery.log
discovery:
-@$(RM) $(discovery_log)
@echo — discovery started… >> $(discovery_log)
@echo $(CC) $(INCLUDES) $(CFLAGS) -E -P -v -dD ‘$(specs_file)’ >> $(discovery_log)
$(CC) $(INCLUDES) $(CFLAGS) -E -P -v -dD ‘$(specs_file)’ >> $(discovery_log) 2>&1
$(CC) $(INCLUDES) $(CFLAGS) -E -P -v -dD ‘$(specs_file)’
@echo — discovery done! >> $(discovery_log)

После выполнения цели в файле discovery.log можно просмотреть пути вызываемых тулчейнов, подключаемых библиотек, и все найденные как в мейкфайле, так и встроенные в тулчейн определения. Также эта информация подхватывается Eclipse, отображая built-in символы и прочее, делая серыми неактивные ветки кода.

Где присваивается значение переменной specs_file ?

В Discovery options:
* compiler invocation arguments: specs_file=${plugin_state_location}/${specs_file} discovery
specs_file задаётся на основе переменных окружения Eclipse. Можно вместо этого внутри makefile напрямую указать значение переменной specs_file, но это не есть хорошо.
На самом деле в итоге берётся там файл почти нулевого размера, типа означает «настройки спеков по умолчанию».

К сожалению у меня не получилось правильно запустить цель discovery , вместо specs_file пустое место :

make discovery
rm -f discovery.log
arm-none-eabi-gcc -Wall -mcpu=cortex-m3 -O0 -ggdb -mthumb -DSTM32F10X_HD -DUSE_STDPERIPH_DRIVER -DF_CPU=72000000 -DDEBUG -DUSE_FULL_ASSERT -Iinclude -I'd:/SourceryG++Lite/arm-none-eabi/include' -ffunction-sections -fdata-sections -Wcast-align -Wcast-qual -Wimplicit -Wpointer-arith -Wswitch -Wredundant-decls -Wreturn-type -Wshadow -Wunused -E -P -v -dD '' >> discovery.log 2>&1
arm-none-eabi-gcc.exe: : No such file or directory

Что именно должно произойти после выполнения цели discovery , просто исчезнут предупреждения Eclipse или появятся новые пути в Path and Symbols?

Вообще-то если значение $(specs_file) пустое, то аргумент из Eclipse неверно передаётся значит.
Например, у меня $(specs_file) преобразуется в E:/work/workspace1/.metadata/.plugins/org.eclipse.cdt.make.core/specs.cpp
Попробуйте в makefile вручную задать:
specs_file := ///specs.cpp
. а вообще, в этом файле 1 байт всего: 0x0A.
Если посмотреть файл discovery.log после выполнения, то там будут расписанные все обнаруженные ключи -I, -D, в том числе относящиеся не к проекту, а к тулчейну. Все обнаруженные пути и определения автоматом заносятся в Paths and Symbols, и руками туда уже вбивать ничего не надо. Ну а на основе определений из P&S Eclipse разруливает подсветку и ветвление кода, Includes в Project Explorer, etc.

    Интересно то, что внутри discovery.log путь к specs_file прописан :
    .../.metadata/.plugins/org.eclipse.cdt.make.core/specs.c
    А в консоли — пусто.
    Символы новые появились в Patch and Symbols , а вот путей к заголовочным файлам нет. Скорее всего с названиями путей где-то нестыковка получилась, потому что много сообщений «ignoring nonexistent directory …»

Уже интереснее. Скорее всего, в makefile надо слеши в путях поменять с обратных на прямые /. Вообще, саму цель discovery самостоятельно запускать не надо. Она запускается автоматически при сборке проекта и периодически при изменениях папок/файлов проекта.

    Опять вернулся к вопросу использования цели discovery.
    Опция просто незаменимая в больших проектах, где приходится либо вручную прописывать пути в Path and Symbols , либо экспортировать/ импортировать.
    Получить список путей и символов в Path and Symbols с помощью цели discovery у меня получилось, но слишком криво, чтобы дополнить статью этой возможностью.
    Во-первых , specs_file приходится вписывать в Makefile, поскольку последний его просто не видит :

    specs_file = D:/ARM/workspace/.metadata/.plugins/org.eclipse.cdt.make.core/specs.c

    Во-вторых , записываемые в Path and Symbols пути напрямую зависят от файлов *.d , которые получаются с помощью опции компиляции -MD (-MMD). Если использовать опцию -MMD , то в Path and Symbols мы не увидим путей к заголовочным файлам, которые подключаются через #include с трехугольными скобочками (к сожалению они не отображаются здесь ) .
    Для получения всех путей в Path and Symbols приходится выполнять такую последовательность действий :

    1.Запустить цель clean (в которой также удаляются все файлы *.d)
    2.Запустить цель all ( которая компилирует исходники с опцией -MD и создает необходимые файлы *.d )
    3.Делать очистку Path and Symbols нажатием на кнопку «clear discovered entries now» в окне Discovery Options
    4.Запускать цель discovery вручную.

    В связи с этими проблемами хочу задать Вам еще несколько вопросов, может быть после их уяснения ко мне придет понимание того, как грамотно воспользоваться возможностями цели discovery:

    1. Как сделать переменную Eclipse specs_file видимой внутри Makefile ?
    2. Каким образом можно автоматически запускать цель discovery ? Если не затруднит, то неплохо бы посмотреть пример из мейкфайла.
    3. Третий вопрос не совсем по теме. Использование опции -MD позволяет получить зависимости объектных файлов от исходных и всех заголовочных , подключаемых с помощью
    #include. Эти зависимости включаются в Makefile с помощью

    include $(wildcard $(OUT_DIR)/*.d)

    Вот пример содержимого такого файла:

    debug/main.o: src/main.c \
    d:\ARM\sourcery\ g++\ lite\bin\../lib/gcc/arm-none-eabi/4.4.1/../../../../arm-none-eabi/include/string.h \

    То есть путь формируется относительно каталога запуска gcc , он формируется автоматически и вставляет обратные слеши Windows. При попытке включения в Makefile эти обратные слеши вызывают ошибки.
    Каким образом можно обойти эту проблему ?
    Пока я нашел выход либо не включать в мейкфайл зависимости от заголовочных файлов, либо пользоваться опцией -MMD (включаются только #include » «), но тогда в Path and Symbols будут видны пути только к заголовочным файлам текущего проекта.

можно воспользоваться командным файлом run_eclipse.bat

Более красиво использовать eclipse.ini. Смотреть параграф 3.2.1 в файле …/eclipse/readme/readme_eclipse.html. Короче там просто указаны те самые аргументы коммандной строки.

Comments are closed.