Возможности Atollic TrueSTUDIO для повышения качества разработки и отладки встраиваемых систем на базе 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 приведен пример списка обнаруженных нарушений правил. На табе Violation для каждого поддерживаемого правила собран список нарушений с указанием имени правила (Rule), серьезности нарушения (Severity), файла кода, где обнаружено нарушение (Source), номера строки в этом файле (Line), имени соответствующей функции (Function) и диагностической информации о проблеме (Diagnostics).

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

По двойному щелчку на интересующей записи открывается форма 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 содержит перечень задач по проекту в рамках выбранного баг-трекера. Предусмотрена удобная настраиваемая фильтрация отображаемых записей. Например, можно показать список всех исправленных ошибок или решенных проблем в конкретной версии программного продукта, список всех задач, запланированных к реализации в предстоящей версии, или список всех запросов новых возможностей, выполнение которых назначено конкретному исполнителю.

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

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

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

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

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

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

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

Опытные инженеры знают, что обнаружить некоторые ошибки в написанном ими коде бывает невероятно трудно. Это может отрицательно сказаться на планировании сроков выпуска проекта или же привести к необходимости проведения дополнительных дорогостоящих обновлений ПО уже в процессе его эксплуатации потребителями [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).

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

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

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

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

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

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

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

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

Например, окно просмотра отслеживаемых данных 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. На панели Debug отображается дерево исследуемого приложения. Task List содержит журнал обрабатываемых задач с указанием детальной информации, включая имя (Name), состояние (State), использование ресурсов процессора (CPU Usage) и стека (Stack Usage) и т. д.

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

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

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

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

Заключение

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

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

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