Печатные публикации

#18: Возможности Atollic TrueSTUDIO для повышения качества разработки и отладки встраиваемых систем на базе ARM

Анна Сергеева. Возможности Atollic TrueSTUDIO для повышения качества разработки и отладки встраиваемых систем на базе ARM // Компоненты и технологии. 2015. № 6.  С. 107-113


В статье показано, как с помощью профессионального инструмента Atollic TrueSTUDIO можно повысить качество и эффективность процесса разработки программного обеспечения на C/C++ для встраиваемых систем на базе микроконтроллеров ARM.


Опубликовано в разделе "Встраиваемые системы"

Эта же статья на сайте журнала

О важности выбора инструментальных средств


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


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


Большинство разработчиков признают, что написание кода - это самая легкая часть их работы. А вот что действительно доставляет им массу неприятностей и заставляет прилагать максимум усилий — так это борьба с ошибками в программном коде. При этом, причины ошибок могут быть самыми разнообразными, включая случайные опечатки, ошибки при невнимательной спешной работе или сбои программ при непредсказуемых условиях.


Почему так происходит? Во многом это объясняется высокой конкуренцией на рынке и постоянно возрастающими запросами потребителей к поддерживаемым функциональным возможностям и системным характеристикам для встраиваемых продуктов. Так что разработчики вынуждены постоянно вносить коррективы и новые требования к и без того плотным графикам выпуска новых усовершенствованных версий своей продукции.


Особенности выбора инструментов для разработки встраиваемых систем


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


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


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


Выбор в пользу Atollic TrueSTUDIO


Среди таких инструментов можно назвать Atollic TrueSTUDIO. Это современная профессиональная среда разработки, ориентированная на ПО для встраиваемых систем на базе широко распространенных в настоящее время микроконтроллеров ARM. [1]


Он, как и большинство инструментов разработки, содержит такие необходимые составляющие как редактор, компилятор, компоновщик и отладчик. Это вполне стандартный набор, поэтому более интересно будет уделить внимание некоторым расширенным возможностям Atollic TrueSTUDIO, которые в большинстве сред разработки встраиваемых систем отсутствуют, но являются очень удобными в работе и помогают повысить качество и эффективность всего процесса разработки ПО.


Среда разработки Atollic TrueSTUDIO предоставляет целый ряд встроенных полезных инструментов, которые поддерживают параллельную компиляцию, проверку исходного кода на соответствие общепринятым стандартам кодирования, анализ сложности кода, возможности экспертной оценки кода. Также доступна RTOS-осведомленная отладка с анализом сбоев, с поддержкой отладки для многоядерных и многопроцессорных систем, с отслеживанием событий, данных и управляющих инструкций и т. д. Обо всем этом и пойдет речь далее.


Интегрированные инструменты анализа кода


Одним из способов улучшения качества кода является использование средств статического анализа исходного кода.


Такие инструменты исследуют написанный разработчиками код и выдают отчет, который содержит перечень рекомендаций по внесению в код ряда полезных улучшений. В случае с Atollic TrueSTUDIO, такие средства встроены в саму среду разработки (IDE). Так что и применять их становится еще удобнее, поскольку нет необходимости переключаться между несколькими рабочими приложениями.


Atollic TrueSTUDIO поддерживает проверку кода на соответствие стандарту кодирования MISRA-C, наиболее широко распространенному в отрасли встраиваемых систем в настоящее время. [2]


MISRA-C — это стандарт кодирования, разработанный MISRA для языка программирования C. Он определяет подмножество языка C, соблюдение которого повышает безопасность, совместимость и надежность кода. По сути, это ключевые достоинства стандарта для разработчиков встраиваемых систем. [3]


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


На рис. 1 показано, как встроенный в Atollic TrueSTUDIO статический анализатор выполняет проверку C-кода на соответствие стандарту MISRA-C. Он выдает статистику в текстовом и графическом формате, для удобного и быстрого обзора текущего состояния кода.


Рис. 1. Результаты работы встроенного инструмента анализа исходного кода


На закладке Inspection Summary приведен перечень предопределенных правил стандарта, включая идентификатор (Rule ID) и краткое описание (Rule title), а также счетчик (Count) обнаруженных нарушений правил в исследуемом коде. На правой панели Distributed Violations результаты проверки представлены в виде диаграммы, где обнаруженные ошибки сгруппированы по типам.


Встроенный в TrueSTUDIO статический анализатор кода обеспечивает высокий уровень проверки соответствия стандарту MISRA. Он автоматически проверяет код на соответствие и идентифицирует любые строки кода, в которых обнаруживает нарушение правил стандарта MISRA.


Рис. 2. Список нарушений правил и их описание


На рис. 2 приведен пример списка обнаруженных нарушений правил. На табе Violation для каждого поддерживаемого правила собран список нарушений с указанием имени правила (Rule), серьезность нарушения (Severity), файл кода, где обнаружено нарушение (Source), номер строки в этом файле (Line), имя соответствующей функции (Function) и диагностическая информация о проблеме (Diagnostics).


По двойному щелчку на интересующей записи открывается форма Rule Explanation, где выдается разъяснение нарушенного правила (Description) и предоставляются примеры хорошего (Good Example) и плохого (Bad Example) кода для каждого поддерживаемого правила стандарта.


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


Анализ сложности и метрики исходного кода


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


Для измерения сложности кода Atollic TrueSTUDIO имеет специальный встроенный инструмент. Он базируется на стандартном алгоритме расчета и предоставляет показатели сложности кода для каждой C-функции в проекте, а также информацию о количестве строк кода, используемых для реализации каждой такой функции.


Помимо этого, Atollic TrueSTUDIO может обеспечить и другие типы метрик кода. В частности, он способен измерить количество строк в файлах и функциях, а также степень комментирования и цикломатическую сложность кода, как на уровне отдельных файлов, так и на уровне всего проекта (рис. 3). Это помогает разработчикам определить, какие части кода нуждаются в улучшении, что обычно означает снижение числа ошибок и упрощение поддержки кода.


Рис. 3. Вычисление метрик кода в Atollic TrueSTUDIO


Atollic TrueSTUDIO позволяет использовать все эти возможности в рамках ежедневного рабочего процесса, поскольку способен поддерживать проверку исходного кода приложения для оценки его качества в автоматическом режиме, через определенные заданные интервалы времени.


Такое измерение и управление сложностью кода C-функций в проекте является одним из самых дешевых и лучших способов сокращения количества ошибок и затрат на эксплуатационное обслуживание проекта.


Экспертная оценка исходного кода


Еще один способ снижения уровня ошибок и дефектов на ранних этапах развития проекта — это экспертная оценка или обзор кода.


В основе здесь лежит формальный процесс, где разработчики проекта изучают код, созданный друг другом. И выполняются эти действия неоднократно, на разных этапах проекта, как до выпуска альфа- или бета-версии, так и после реализации или обновления ключевых возможностей в проекте.


Atollic TrueSTUDIO является, пожалуй, первой средой разработки встраиваемых систем, которая сочетает возможности экспертной оценки исходного кода и организацию и проведение итоговых совещаний экспертов.


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


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


Как правило, экспертная оценка кода выполняется в три шага.



  1. Фаза индивидуального исследования кода, где эксперты изучают исходный код, написанный коллегами, и высказывают свои замечания. Они описывают характер проблем и могут присваивать им предполагаемый уровень важности.

  2. Фаза командного исследования кода, где в формате совещания эксперты обсуждают, что делать с каждой выявленной проблемой в коде, и тут же могут назначать конкретных участников команды, ответственных за переработку кода. Так, например, в ходе совещания эксперты могут решить, какие комментарии не являются существенными или обоснованными, какие допустимы, но не требуют исправлений, а какие справедливы и должны быть немедленно приняты к действию.

  3. Фаза переработки кода и устранения проблем, где участники команды занимаются решением проблем, которые им назначены по результатам совещания. По мере устранения каждой проблемы, ее состояние фиксируется в централизованном хранилище данных, так что менеджер проекта и другие участники команды могут легко отслеживать ход вносимых исправлений и объем оставшихся проблем, которые по-прежнему требуют внимания.



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


Рис. 4. Форма просмотра состояния результатов экспертной оценки кода


В таблице представлены имя эксперта (Reviewer), путь и имя файла, содержащего проблемный код (File), строка в файле, где эксперт оставил комментарий (Line), сам текст комментария эксперта (Summary), предполагаемая или оцененная в ходе совещания степень серьезности проблемы (Severity), принятое на совещании решение по проблеме (Resolution).


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


Интегрированный клиент системы контроля версий


Возможности современных микропроцессоров растут с каждым годом, и за счет этого они получают способность поддерживать все более объемные и сложные встраиваемые программные приложения. Соответственно, увеличивается сложность и размер кода таких программ. И вопросам управления процессами разработки ПО приходится уделять все больше и больше внимания.


В ходе разработки программного проекта, исходный код постоянно подвергается огромному количеству изменений. И здесь, если не будет применяться какая-либо методика контроля промежуточных версий, то очень быстро начнется путаница и станет совершенно невозможно выяснить, кто сделал те или иные изменения в коде, когда и зачем. Также по истечение некоторого времени ценная информация о том, как изначально выглядел оригинальный код, может быть безвозвратно утрачена. А это приведет к потере страховочной возможности вернуться к предыдущему состоянию кода, когда он был заведомо исправным.


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


Что касается Atollic TrueSTUDIO, то прямо в его среду разработки интегрированы возможности управления кодом C/C++, где, для поддержки таких инструментов контроля версий кода, как Subversion (SVN) и GIT, доступен удобный графический клиент (рис. 5).


Рис. 5. Интеграция TrueSTUDIO с системой контроля версий Subversion (SVN)


На панели Project Explorer отображено дерево структуры рабочего проекта. SVN Properties используется для настройки параметров и свойств подключения к системе. SVN Repository отображает дерево структуры выбранного рабочего репозитория в системе хранения версий. На панели Revision Graph недавние версии файлов и связи между ними отображены в виде графа. На нижней панели History приведен перечень изменений в коде с возможностью просмотра деталей по каждой записи.


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


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


Интегрированный клиент системы отслеживания ошибок


Еще один клиент, интегрированный в среду разработки Atollic TrueSTUDIO, - это графическая оболочка для подключения к внешним системам отслеживания ошибок и управления запросами, имеющих структуру базы данных. Поддерживается взаимодействие с большинством популярных баг-трекеров, среди которых можно назвать Trac, Bugzilla, Mantis и другие.


Подключаясь к одной из таких систем с помощью клиента, встроенного в Atollic TrueSTUDIO, участники проекта получают удобный способ добавлять новые отчеты об обнаруженных ошибках или запросы новых возможностей, изменять статус заявок, а также просматривать интересующие заявки, выполняя обращения к базе данных системы с различными фильтрами (рис. 6).


Рис. 6. Интеграция TrueSTUDIO с внешней системой отслеживания ошибок


Панель Task Repositories содержит набор репозиториев, доступных в рамках системы отслеживания ошибок, к которой подключен TrueSTUDIO. Здесь можно выбрать конкретный баг-трекер для работы с заявками по нему.


Панель Task List содержит перечень задач по проекту в рамках выбранного баг-трекера. Поддерживается удобная настраиваемая фильтрация отображаемых записей. Например, здесь можно показать список всех исправленных ошибок или решенных проблем в конкретной версии программного продукта, список всех задач, запланированных к реализации в предстоящей версии, или список всех запросов новых возможностей, реализация которых назначена на конкретного исполнителя.


В примере на рисунке показан полный список задач по всему проекту (All tickets), список блокирующих ошибок (Blocker tickets) и список задач, запланированных к реализации в конкретных версиях (Version 1.0 и Version 2.0). Для удобства восприятия они снабжены индикаторами новых, решенных, прорабатываемых задач.


В нижней части экрана приложения можно просматривать детальную информацию по каждой выбранной заявке (на рисунке это Ticket 9). В зависимости от настроек системы и от состояния текущей заявки, одни атрибуты доступны только для чтения, другие же можно редактировать. Основные атрибуты: дата создания (Created), дата последнего изменения (Last Modification), статус (Status), приоритет (Priority) и другие.


Дополнительно в секции Attachements можно добавлять скриншоты, выполнять их редактирование (обрезка изображения, добавление стрелок и пояснительного текста) и присоединять их к заявкам в виде вложенных файлов.


Есть и еще одна существенная особенность Atollic TrueSTUDIO при взаимодействии с системой контроля ошибок. Он позволяет сохранять контекст решения задач в каждый момент времени.


Вот какое преимущество это дает. Например, если разработчик при решении какой-либо проблемы работает с 3 различными файлами, то при каждом сеансе работы над данной проблемой все эти 3 файла будут открыты автоматически, и курсор будет расположен на тех же самых местах, что и в прошлый сеанс работы. И при этом совершенно не важно, был этот предыдущий сеанс несколько недель или даже месяцев назад. Так что, разработчик каждый раз быстро погружается в суть проблемы, за решение которой несет ответственность.


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


Дополнительные инструменты отладки кода


Разработчики с достаточным опытом знают, что обнаружить некоторые ошибки в написанном ими коде бывает невероятно трудно. Это может отрицательно сказаться на планировании сроков выпуска проекта или же привести к необходимости проведения дополнительных дорогостоящих обновлений ПО уже в процессе его эксплуатации потребителями. [4]


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


Остались далеко позади те времена, когда для отладки проектов средних размеров было достаточно применять примитивные отладчики, работающие по принципам пошагового исполнения, прогона до точки останова и возврата результата в качестве параметров функции printf.


Сегодняшние отладчики должны поддерживать возможности отслеживания событий, данных и инструкций, с занесением результатов в журнал исполнения для последующего анализа. Также отладчики должны содержать анализаторы сбоев для выяснения причин, по которым разрабатываемое приложение привело процессор в неисправное состояние, и еще возможности RTOS-осведомленной отладки, и т.д.


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


Анализатор сбоев для процессоров на базе ARM Cortex-M


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


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


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


Для отслеживания подобных причин сбоев в работе процессоров Atollic TrueSTUDIO содержит интегрированный инструмент анализа сбоев. Он способен автоматически определять, что привело систему в неисправное состояние. В дополнение к визуализации того места в системе, где произошел сбой, этот инструмент также предоставляет информацию о причинах и обстоятельствах сбоя (рис. 7).


Рис. 7. Встроенный в Atollic TrueSTUDIO анализатор сбоев для ARM Cortex-M


На форме анализатора Fault Analyzer отображаются обнаруженные сбои, с указанием детальной информации по неисправностям оборудования (Hard Fault Details), шины (Bus Fault Details), использования (Usage Fault Details), управления доступом к памяти (Memory Management Fault Details), а также содержимое регистров во время сбоя (Register Content During Fault Exception). Также в исходном коде подсвечиваются строки, в которых произошел данный сбой. Доступен просмотр кода как в формате исходных файлов проекта, так и в формате дизассемблированного кода.


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


Расширенные возможности системного анализа


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


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


Atollic TrueSTUDIO предоставляет расширенные возможности высококачественной отладки кода встраиваемых приложений.


В нем используются средства отслеживания поведения уровня событий, данных, приложений. Применяются востребованные разработчиками технологии отладки в режимах SWV (Serial Wire Viewer), SWO (Serial Wire Output) и ITM (Instrumentation Trace Macrocell).


Совместное применение этих технологий позволяет обрабатывать и получать через JTAG-кабель различные необходимые типы данных от системы, функционирующей в реальном времени и в нормальном режиме эксплуатации. [5]


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



  • Верно ли функционируют алгоритмы управления.

  • Были ли повреждения отдельных участков памяти по причине неосторожности.

  • Является ли поведение указателей ожидаемым.

  • Какие участки кода требуют оптимизации и их местоположение.

  • Какие конкретные строки кода привели к нарушению доступа к памяти и их местоположение.

  • Каков общий характер поведения операционной системы реального времени и межплатформенного программного обеспечения.

  • Запускаются ли приложения ожидаемым образом.



Как упоминалось, среди возможностей Atollic TrueSTUDIO есть отладка в режиме SWV, причем с отслеживанием событий в режиме реального времени. Это позволяет детально исследовать поведение системы в процессе ее функционирования.


Доступны следующие возможности.



  • Отображение в реальном времени значений переменных или адресов памяти (рис. 8).

  • Отслеживание прерываний и исключений, со сбором статистики по времени исполнения (рис. 9).

  • Ведение журнала регистрации всех событий чтения и записи в указанное место памяти, с указанием номеров строк кода, откуда поступили управляющие инструкции (рис. 10).

  • Измерение интервала времени исполнения между двумя независимыми точками кода.

  • Графическое отображение результатов в виде диаграмм, таблиц и графиков в реальном времени (рис. 11).

  • Перенаправление возвращаемых результатов функции printf() в любой из 32 параллельных и взаимонезависимых портов ITM.

  • Пользовательское отслеживание событий программного уровня с использованием инструментирования кода в режиме отладки ITM.



Рис. 8. Профилирование значений переменных в реальном времени


Рис. 9. Отслеживание прерываний и исключений в реальном времени


Рис. 10. Ведение журнала регистрации событий чтения и записи


Рис. 11. Графическое наблюдение времени исполнения различных функций


Так, например, окно просмотра отслеживаемых данных SWV Data Trace (рис. 10) отображает значения переменных и адресов в памяти, в реальном времени и на всем протяжении функционирования отлаживаемого приложения. Таким образом, это окно предоставляет точный журнал всех событий чтения и записи в конкретное указанное место.


По двойному щелчку на той или иной записи в журнале открывается соответствующий файл исходного кода с размещением курсора ровно в той строке, откуда произведено чтение или запись в память. Отметим, что это очень легкий способ выяснить, например, в какой строке кода происходит непреднамеренная перезапись памяти или переменной.


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


Есть и другие возможности. Для оптимизации времени исполнения кода есть функции измерения времени исполнения и профилирования собранных статистических данных (SWV Statistical Profiling, рис. 8).


Кроме того, можно задействовать диаграммы времени исполнения различных C-функций, измеряя с их помощью время исполнения между двумя независимыми частями программы (рис. 11), или же оценивать минимальное, максимальное и среднее время обработки прерываний (рис. 9).


Atollic TrueSTUDIO также поддерживает трассировку программного обеспечения по интерфейсу ITM. Это позволяет перенаправлять возвращаемые результаты функции printf() по JTAG-кабелю в консоль отладчика.


В дополнение к отслеживанию данных и событий в режиме отладки SWV, современные отладчики также должны поддерживать еще и отслеживание инструкций ETM/ETB, регистрируя события по их обработке в специальном журнале для последующего автономного анализа.


Отслеживание этих инструкций имеет особенную ценность в системах, функционирование которых не допускает прерываний в указываемых точках останова (например, приложения управления запущенными двигателями машин). А используя отслеживание инструкций, разработчики могут обойти эти ограничения и все равно исследовать поток исполнения приложения в ходе его отладки.


В Atollic TrueSTUDIO отслеживание инструкций позволяет регистрировать события потока исполнения кода в реальном времени.


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


На форме Trace Log (рис. 12) доступен просмотр данных о событиях, таких как содержимое инструкции (Instruction), имя соответствующей функции (Function), время исполнения (Time), код операции (OpCode), индекс (Index), адрес в памяти (Address), а также суммарный объем накопленных к настоящему моменту данных (Total).


Рис. 12. Журнал отслеживаемых инструкций ITM


К слову сказать, объем записываемых данных внушительный. Речь идет об объемах порядка 100 МБ данных в бинарном представлении или 5-10 ГБ данных в формате, удобном для человеческого восприятия, и это за каждую секунду времени исполнения приложения на платформе Cortex-M4. Вот поэтому-то здесь и будет полезно применять настраиваемые отладочные триггеры старта/останова или точек прерывания. С их помощью осуществляется управление запуском и завершением процесса записи отслеживаемых событий, и таким образом снижается объем накапливаемых данных.


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


RTOS-осведомленная отладка


Как правило, коммерческие инструменты и среды разработки не ориентированы на использование с какой-либо конкретной ОС реального времени (RTOS). А значит, возможности отладчиков носят довольно общий характер и не позволяют детально отображать структуры данных, характерные для конкретных типов ядер.


Тут на помощь приходит применение отладки уровня ядра. И TrueSTUDIO поддерживает подобный режим отладки для большинства распространенных ОС реального времени, включая такие как embOS, ThreadX, RTXC, FreeRTOS и µC/OS.


Рис. 13. Отладка уровня ядра для приложения на платформе µC/OS


На рис. 13 приведен пример отладки уровня ядра для встраиваемого приложения, предназначенного для запуска на платформе µC/OS. На панели Debug отображается дерево исследуемого приложения. Task List содержит журнал обрабатываемых задач с указанием детальной информации, включая имя (Name), состояние (State), использование ресурсов процессора (CPU Usage) и стека (Stack Usage), и т.д.


На панели System Information отображается общая информация о системе: версия, состояние, ключевые таймеры и счетчики. Панель Message Queues отображает очередь сообщений, Fault Analyzer – анализатор сбоев, который уже упоминался ранее.


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


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


Заключение


По совокупности многих факторов, разработка встраиваемых систем является достаточно непростым процессом. И чем более сложным должно быть приложение, тем большее число участников оно предполагает задействовать. Для этого организуется работа удаленных, географически распределенных команд. Или же работа выполняется силами относительно небольших команд, но в интенсивном режиме. Сроки разработки постоянно сжимаются, а требования руководства варьируются. Все это способно повысить уровень стресса в команде разработчиков и поставить под угрозу успех всего проекта.


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


В статье показано, как работа в среде Atollic TrueSTUDIO становится легче и удобнее, позволяет создавать и поддерживать код на порядок более высокого качества, существенно уменьшать время, усилия и затраты на дополнительную отладку и, конечно, предоставлять потребителям всегда только исправные и надежные продукты.


Литература


[1] О среде разработки Atollic TrueSTUDIO - www.atollic.com/truestudio

[2] А. Сергеева. Возможности статического анализатора Atollic TrueINSPECTOR для повышения качества встраиваемых приложений. 2015.4.

[3] MISRA-C: "Guidlines for the use of the C language in critical systems", 2004.

[4] А. Сергеева. Тестирование работоспособности промышленного компьютера. // Компоненты и технологии. 2014. № 2.

[5] А. Сергеева. Автоматизация модульного тестирования с Atollic TrueVERIFIER для повышения качества встраиваемых приложений. 2015. № 5.