Рекомендуемые настройки компилятора IAR для встраиваемых проектов | arm-troubleshooting-faq

В этой статье приведены некоторые рекомендации (перевод [1]), посвященные оптимизации проектов IAR, что поможет ускорить их работу и несколько сократить размер двоичного кода.

[Ускоренный вывод терминала (консоль Terminal I/O)]

IAR позволяет держать несколько проектов в Вашем рабочем пространстве workspace, и можно настроить проект для запуска теста в каждом из используемых модулей. На начальной стадии отладки может использоваться конфигурация симуляции (Simulator, без отладки на реальной аппаратуре) и конфигурация Debug для загрузки и выполнения юнит-тестов на реальном целевом процессоре. Если не сделать специальные настройки, то вывод отладочных сообщений в штатную консоль терминала IAR (Terminal I/O) будет происходить очень медленно. Ускорить вывод может изменение настройки проекта для включения буферизованного вывода (Project -> Options -> Linker -> Output -> Buffered terminal output).

Можно применить перенаправление вывода printf в аппаратный интерфейс (UART, SPI и т. п.), что еще больше может ускорить вывод отладочных сообщений в реальном времени выполнения кода [4, 5, 6].

[Автоматическая генерация метрик интенсивности работы кода]

IAR C-SPY может автоматически генерировать информацию покрытия кода (code coverage metrics), когда модули кода работают в симуляторе (конфигурация Simulator, это не работает при запуске тестов на реальной аппаратуре процессора, например в конфигурации Debug). Для этого просто добавьте опцию –code_coverage_file путь_до_выходного_файла в файл PROJ_DIR/settings/PROJ_NAME.[конфигурация].cspy.bat, например –code_coverage_file $PROJ_DIR$\$PROJ_FNAME$CodeCoverageFullResults.log. Однако имейте в виду, что файлы *.cspy.bat автоматически генерируется компилятором, так что потребуется написать скрипт, чтобы в каждый файл *.cspy.bat добавлялась нужная строка при каждом новом запуске компиляции. К счастью, в релизе IAR V6.20 (декабрь 2014) разработчики подправили IDE, так что теперь Вы можете просто указать опцию для этой функции без необходимости прямой правки bat-скриптов (см. Project -> Options -> Debugger -> Extra Options).

После того, как выполнились юнит-тесты для каждого проекта/модуля, и были сгенерированы логи покрытия кода (code coverage), Вы можете выполнить следующие 2 скриптовые команды, чтобы распаковать процентную информацию покрытия кода высокого уровня. Пример:

findstr /C:"Module " %moduleName%CodeCoverageFullResults.log > %moduleName%CodeCoverageAllModulesOnly.log
findstr %modulesOfInterest% "%moduleName%CodeCoverageAllModulesOnly.log" > "%moduleName%CodeCoverageSummary.log"

Эти две команды выполняют поиск всей нужной статистики в логах и выводят результат в один файл.

[При архивировании файлов проекта не забывайте и про файлы *.ewd, *.ewp, *.eww]

Если для архивирования проектов у Вас используется система управления версиями (revision control system), проверьте её настройки, чтобы сохранялись необходимые файлы (но не все). Например, файлы зависимостей *.dep генерируются автоматически изменяются часто, поэтому их не нужно добавлять в коммит. Однако файлы *.eww (настройки workspace) и *.ewp (настройки проекта) содержат важную информацию, поэтому система управления версиями должна отслеживать их, как и файлы исходного кода.

[Включите несколько правил MISRA, чтобы улучшить стиль кодирования]

Наш клиент высказал пожелание, чтобы кодовая база проекта соответствовала некоторым выбранным правилам совместимости с MISRA C. Для стандарта MISRA 2004 это правила 2.3, 2.4, 5.2, 5.3, 5.5, 5.6, 5.7, 6.3, 8.3, 8.7, 8.11, 9.1, 10.1, 10.2, 12.2, 12.4, 12.8, 12.9, 13.1, 14.1, 14.4, 14.5, 14.10, 15.1, 15.2, 16.8, 17.1, 17.2, 17.4, 17.6, 19.10, 19.15, 20.4, 20.5, 20.6, 20.7, 20.8, 20.9, 20.10 и 20.11. Мы включили эти правила в настройках для полной сборки продукта, но оставили их выключенными в проектах юнит-тестов, поскольку фреймворк тестирования Unity выдавал много собственных предупреждений. Хотя мы ввели несколько исключений, которые хорошо задокументировали, включение перечисленных правил MISRA выглядит хорошей рекомендацией для повышения качества кода, и еще лучше, если IAR будет автоматически проверять эти правила. Инструменты статического анализа помогут в будущем выявить проблемы Вашего кода, но включение проверки правил в компиляторе сократит обратную связь проверки. Это поможет Вашей команде избегать проблем с арифметикой указателей, затенением области видимости имени переменных, инициализацией, и с другими неожиданными побочными эффектами.

[Хитрости манипуляции стеком при использовании макросов тестирования Unity]

При отладке мы используем фреймворк тестирования модулей Unity (написанный на C), операционную систему Segger embOS для встраиваемых систем, и компилятор IAR со всеми выключенными оптимизациями. Иногда нам нужно было доказать потокобезопасность определенных ключевых путей обмена, или требовалось создать юнит-тесты для низкоуровневого функционала OS, что требовало реального запуска OS на наших unit-тестах. К сожалению, у embOS есть функционал "Start", но нет функционала "Stop", так что нет встроенного способа "чисто" выйти из OS. Однако IAR и TI предоставляют заголовочный файл intrinsics.h, в котором есть методы манипуляции программным счетчиком, указателем стека и регистрами состояния процессора. Это позволило нам запустить unit-тесты для OS, и после завершения теста перейти обратно к коду, вызвавшему модуль теста после точки, где OS была запущена. Однако обнаружилось, что когда вызываются макросы TEST_ASSERT, компилятор IAR лениво ждет окончания обрамляющей функции, чтобы сбросить указатель стека. Поэтому получалось, что указатель стека отличается до и после вызова TEST_ASSERT. Наше решение этой проблемы состояло в создании отдельного внешнего буфера, и сохранении в него всего содержимого стека перед входом в OS таким образом, чтобы содержимое стека можно было точно восстановить впоследствии. В завершение следует отметить, что хотя было сложно реализовать корректную работу этих тестов, такие проверки значительно улучшают безопасность системы в зависимости от используемой OS, и в будущем защищает поддержку кода от случайного появления дефектов нарушения безопасности выполнения потоков.