Обзор возможностей Qt Creator 4.10 и QBS 1.14 для программирования микроконтроллеров

Здравствуйте, товарищи программисты «железячники» и все кто им сочувствует. Я хотел бы представить небольшой обзор возможностей IDE Qt Creator в связке с системой сборки QBS в части программирования микроконтроллеров. Кому эта тема интересна, добро пожатовать по кат.

Буквально на днях, тихо и незаметно, вышел релиз Qt Creator 4.10, в котором добавлены некоторые улучшения для работы с микроконтроллерами (в простонародье — «baremetal» устройствами). В этот релиз Qt Creator интегрирована сборочная система QBS 1.14 в которой также есть новые улучшения. О некоторых таких улучшениях и пойдет ниже речь.

Улучшения в Qt Creator

Все эти улучшения доступны только при включенном плагине BareMetal, который активируется через меню «Help -> About Plugins -> Device Support -> BareMetal».

  1. Теперь поддерживаются три новых компилятора, основные сведения о которых приведены ниже в таблице:
    Компилятор Поддерживаемые архитектуры
    IAR EW ARM, AVR, 8051 (MCS51)
    KEIL ARM, 8051 (MCS51)
    SDCC 8051 (MCS51)

    Примечание: Стоит заметить, что продукты от IAR EW и KEIL для разных архитектур предоставляются отдельными пакетами, которые нужно устанавливать независимо. В отличии, скажем, от компилятора SDCC который поддерживает несколько архитектур сразу.

  2. Теперь эти новые компиляторы автоматически определяются на вкладке «Tools -> Options -> Kits -> Compilers -> Auto-detected».

    Например, у меня это выглядит следующим образом:

    Примечание: Как видно, для языка С++ отсутствует компилятор KEIL для MCS51, что корректно, т.к. этот компилятор поддерживает только C. Также здесь будет отсутствовать и компилятор SDCC по той же причине.

  3. Имеется также возможность ручного добавления этих новых компиляторов через меню «Tools -> Options -> Kits -> Compilers -> Add»:

  4. Для компилятора будет автоматически определено его ABI (архитектура, формат и ширина слова). Информацию об этом можно посмотреть, просто кликнув на компиляторе.

    Например, у меня для IAR EW и архитектуры 8051 (MCS51) это выглядит следующим образом:

    Примечание: В данном случае был выбран компилятор, который был автоматически определен, поэтому поля ABI здесь неактивные. Но при ручном добавлении компилятора пользователь может выбрать корректное ABI, если по каким-либо причинам оно определилось неправильно.

  5. Для компилятора будут автоматически определены все его макросы. Таким образом они будут корректно подсвечены в редакторе кода.

    Примечание: Исключением являются только ключевые слова некоторых компиляторов (например, для архитектуры 8051), которые будут подсвечены с предупреждением. Но это уже другая история.

  6. Для компилятора будут автоматически определены директории с его заголовочными файлами. Таким образом они будут корректно подсвечены в редакторе кода.
  7. Реализованы парсеры ошибок и предупреждений этих новых компиляторов, которые выводятся в панель «Issues».

Улучшения в QBS

QBS будет неотъемлемой частью данного обзора, поэтому имеет смысл поговорить и об его улучшениях:

  1. Добавлена поддержка этих новых компиляторов (некоторых из них еще с начиная с версии 1.13).
  2. Реализована возможность автоматического определения установленных компиляторов и создания профилей. Для чего используется утилита qbs-setup-toolchains.

    В моем случае это выглядит так:

    c:\Qt-meta\Tools\QtCreator\bin>qbs-setup-toolchains.exe --detect ... Trying to detect IAR toolchains... Profile 'iar-arm' created for 'C:/Program Files (x86)/IAR Systems/Embedded Workbench 8.3/arm/bin/iccarm.exe'. Profile 'iar-mcs51' created for 'C:/Program Files (x86)/IAR Systems/Embedded Workbench 8.0/8051/bin/icc8051.exe'. Profile 'iar-avr' created for 'C:/Program Files (x86)/IAR Systems/Embedded Workbench 8.0/avr/bin/iccavr.exe'. Trying to detect KEIL toolchains... Profile 'keil-mcs51' created for 'C:/Keil_v5/C51/BIN/c51.exe'. Profile 'keil-arm' created for 'C:/Keil_v5/ARM/ARMCC/bin/armcc.exe'. Trying to detect SDCC toolchains... No SDCC toolchains found. ... 

    Чтобы посмотреть что там было обнаружено, можно воспользоваться GUI утилитой qbs-config-ui.

    В моем случае это выглядит так:

Особенности создания проекта

Тут важно иметь представление и уметь корректно заполнять свойства проекта для модулей cpp и qbs.

Остановимся на наиболее важных из них и рассмотрим их подробнее:

  • qbs.toolchain — это свойство автоматически заполняется при генерации профиля для выбранного компилятора. Ниже в таблице представлены возможные значения этого свойства:
    Имя тулчейна Значение свойства
    IAR EW iar
    KEIL keil
    SDCC sdcc

  • qbs.architecture — это свойство автоматически заполняется при генерации профиля для выбранного компилятора. Ниже в таблице представлены возможные значения этого свойства:
    Имя архитектуры Значение свойства
    ARM arm
    AVR avr
    8051 (MCS51) mcs51

  • cpp.cLanguageVersion — это свойство позволяет установить версию используемого стандарта для языка С. Возможные варианты использования приведены в таблице ниже:
    Имя тулчейна Возможные варианты По умолчанию
    IAR EW c89 Последняя версия в зависимости от версии тулчейна.
    KEIL c99 (только для ARM) Последняя версия в зависимости от версии тулчейна.
    SDCC c89, c99, c11 Последняя версия в зависимости от версии тулчейна.

    Примечание: Важно заметить, что тулчейны IAR EW и KEIL не предоставляют возможности выбора версии стандарта. По умолчанию они используют самую свежую версию, реализованную в конкретной версии компилятора (или c99 или c11, нужно смотреть в release-notes к компилятору). Обычно имеется возможность только выбрать старую версию стандарта c89.

  • cpp.cxxLanguageVersion — это свойство позволяет установить версию используемого стандарта для языка С++. Возможные варианты использования приведены в таблице ниже:
    Имя тулчейна Возможные варианты По умолчанию
    IAR EW Нет Последняя версия в зависимости от версии тулчейна
    KEIL c++03, c++11 (только для ARM) c++03 (только для ARM)
    SDCC Не поддерживается Не поддерживается

  • cpp.entryPoint — это имя точки в хода в программе, которая используется при линковке. Её необходимость определяется используемым рантаймом. Например, если использовать рантайм от IAR EW (т.е. линковаться с её библиотеками и использовать её скрипты линкера), то в этом случае имя точки будет "__program_start". Т.е. это целиком и полностью зависит от разработчика.
  • cpp.driverFlags — это общие флаги, которые будут передаваться компилятору и ассемблеру. В некоторых случаях, они также будут передаваться и линковщику (это зависит от типа тулчейна). Этими флагами могут быть флаги указания типа процессора, сопроцессора и т.д.

    Например, для компилятора IAR EW для архитектуры AVR это могут быть:

    cpp.driverFlags: ["--cpu=can128", "-ms"]

  • cpp.driverLinkerFlags — это флаги, которые будут передаваться линковщику без изменений, в отличии от cpp.linkerFlags, которые могут быть автоматически дополнительно обернуты некоторыми ключевыми словами. Для компиляторов IAR EW и KEIL предпочтительнее использовать cpp.driverLinkerFlags, т.к. эти компиляторы всегда используют отдельный исполняемый файл линковщика для линковки. Для компилятора SDCC предпочтительне использовать cpp.linkerFlags, т.к. команды этого компилятора в чем-то аналогичны компилятору GCC.
  • cpp.commonCompilerFlags — это общие флаги, которые будут передаваться как компилятору C так и компилятору C++.

    Например, для компилятора IAR EW это может быть флаг включения специфичных расширений данного компилятора:

    cpp.commonCompilerFlags: ["-e"]

  • cpp.сFlags — это флаги, которые будут передаваться только компилятору C.
  • cpp.сxxFlags — это флаги, которые будут передаваться только компилятору C++.
  • cpp.staticLibraries — это список библиотек с которыми необходимо линковать приложение. Отмечу, что cpp.dynamicLibraries не поддерживаются в данных компиляторах (как я знаю), поэтому имеет смысл использовать только cpp.staticLibraries.
  • cpp.assemblerFlags — эти флаги будут переданы только ассемблеру.

Для задания файлов скриптов для линковщика имеется специальный тег «linkerscript», который и необходимо использовать, например:

         Group {             name: "Linker Scripts"             fileTags: ["linkerscript"]             files: ["cfg3soim.xcl", "cfgcan128.xcl"]         } 

Примечание: Причина в том, что для разных компиляторов имеются различные варианты именования этих файлов. Для того же GCC это могуть быть файлы с расширениями *.ld, *.x, *.xn, *.xbn и пр. (что уже говорить о других компиляторах…). Поэтому решено было не заморачиваться с тегированием всех возможных расширений файлов для конкретных компиляторов, а просто использовать тег «linkerscript» по назначению и ситуации.

Чтобы посмотреть как это все работает, QBS предоставляет набор простейших примеров, которые только «дрыгают» ножкой и мигают светодиодом.

Что с отладкой

К сожалению, ситуация с отладкой плачевная. Продукты (IDE) IAR EW и KEIL используют свои отладчики, но, т.к. эти продукты являются проприетарными, то раздобыть где-то описание работы протоколов этих отладчиков не представляется возможным. Единственный вариант — это попытаться выполнить реверс-инжиниринг плагинов для Eclipse (например, IAR EW предоставляет эти плагины), но для этого необходима серьезная мотивация.

Но могу немного обрадовать, если скажу, что для архитектуры ARM можно использовать отладчик GDB. По крайней мере у меня это работало для IAR EW (но вот, с KEIL что-то не вышло, возможно там надо указывать какие-то дополнительные флаги линковщику).

Что дальше

Здесь я немного спойлерну, скажу что в следующих версиях (не знаю в каких именно), должны добавиться архитектуры STM8 и MSP430, а также в QBS будут реализованы генераторы в нативные проекты IAR EW и KEIL (что даст возможность, например, отлаживать проекты).

На этой ноте я заканчиваю свое повествование, всем спасибо, кто уделит внимание этому обзору.


ссылка на оригинал статьи https://habr.com/ru/post/467323/

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *