Ю. Гончаров

Технология eXpressDSP. Часть II. Интегрированная среда разработчика Code Composer Studio

В предыдущей статье цикла было приведено описание интерфейса JTAG и возможности его применения как интерфейса внутрисхемной эмуляции для ЦСП Texas Instruments. Теперь перейд╦м к программным средствам, которые работают с ЦСП ФИРМЫ TI и внутрисхемными JTAG-эмуляторами.

Рассмотрим основное отличие принципов построения рабочего места разработчика, заложенного в технологию eXpressDSP и в реализующую эту технологию интегрированную среду разработчика Code Composer Studio (CCS).

При традиционном подходе работающие на PC средства разработки использовались только для компиляции программы, загрузки е╦ в процессор и контроля выполнения. При этом сама исполняемая на ЦСП программа про отладчик ничего не знала и общаться с ним не могла. Комплекс средств для тестирования устройства существовал как отдельная система и с отладочными средствами никак не соприкасался. Для просмотра, например, формы сигнала где-либо внутри программы приходилось писать специальный участок кода, который занимался е╦ выводом на ЦАП или кодек, а зачастую и предусматривать установку дополнительного аппаратного кодека для этих целей.

Чем хороша и приятна отладка программ для PC? Всегда под рукой широкий стандартный набор устройств ввода/вывода, хранения и визуализации информации: ж╦сткий диск, клавиатура и монитор. Устройства на базе ЦСП такого набора по своей функциональности лишены. Да, возможно, есть в устройстве и клавиатура и, например, ЖКИ-индикатор, однако предназначены они не для отладочных целей, а их использование не по назначению - это дополнительные затраты времени и ресурсов, которые ограничены. Очень распростран╦нное решение: давайте предусмотрим место под дополнительный кодек, дополнительный разъ╦м для отладочных целей или, на худой конец, поставим светодиод и будем им моргать. Но сложность разрабатываемых устройств переросла моргание светодиодиком. Задачи анализа и управления поведением ЦСП устройств требуют отдельных, дорогостоящих комплексов измерительной аппаратуры. Такая же ситуация и с вводом/выводом сигналов. Ничто в принципе не мешает записать сигнал на ж╦сткий диск через подключенный к PC АЦП и потом просмотреть его. Но это опять затраты времени и аппартуры плюс время на написание программы снятия данных, их обработки и отображения, например, расч╦та и вывода БПФ. Плюс к этому, возможные неявные ошибки в самой программе снятия и визуализации данных. И опять же время, время и ещ╦ раз время, которого никогда не хватает.

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

Одно из основных принципиальных нововведений в CCS - это возможность совместного использования в ней средств программирования, отладки, анализа и тестирования. Если раньше был отдельно отладчик, эмулировавший процессор, отдельно программа на ЦСП и отдельно - средства ввода/вывода, то теперь - итегрированная отладочная среда, в которую входят как средства написания, компиляции и отладки кода, так и средства анализа его работы и обеспечения тестирования. Тем самым организовано взаимодействие между ЦОС программой и средствами отладки.

Простой пример: допустим, что мы проектируем блок обработки речи, устанавливаемый в портативную радиостанцию. Устройство состоит из ЦСП, двух кодеков и Flash-памяти и размещается на маленькой платке, которая должна укладываться в предназначенный для этого отсек радиостанции. Дополнительное место на этой плате отсутствует. Из органов управления имеются один вход ВКЛ/ВЫКЛ и один выход индикации того, что устройство включилось. Алгоритм отработан и выверен на симуляторе. Загружаем его в ЦСП, запускаем и выясняем, что вс╦ вроде работает, но вот устройство через некоторое время работы да╦т сбой. Добавить какие-либо контрольные средства в само устройство сложно, а тестовый стенд, даже если его сделать, может проверить только взаимодействие разработки с внешним миром, но никак не проанализировать е╦ внутреннее поведение. Вот тут и проявляются все возможности анализа, встроенные в CCS.

Есть ещ╦ один немаловажный аспект: стремление максимально разумно и правильно использовать все ресурсы ЦСП разрабатываемого устройства. При этом с увеличением сложности устройства могут возникать всевозможные "узкие моменты", которые как производительностью самого ЦСП, так и исполнением алгоритма обусловлены и требуют быстрой локализации. Встроенные в CCS средства анализа работы алгоритма, прич╦м не только пошаговые, но и в реальном времени, позволяют быстро локализовать самые замысловатые эффекты и порождающие их ошибки.

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

Цикл разработки с использованием CCS

CCS является полностью законченной интегрированной отладочной средой разработчика, которая объединяет в себе все необходимые средства для проведения полного цикла разработки от конфигурирования системы, написания и компилирования программы до отладки и анализа поведения алгоритма (рис. 1).

Рисунок 1. Цикл разработки в CSS

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

Версии CCS

Версии CCS выпускаются для каждого семейства (каждого ядра) ЦСП. Кроме того, при развитии и разработке нового улучшенного ядра ЦСП, как правило, сохраняется совместимость сверху вниз по коду, и с обеими версиями ядра работает одна и та же версия CCS.

В настоящее время выпускается 4 варианта CCS для 4-х основных ветвей ЦСП:

• C6000 Code Composer - поддерживаются ЦСП смейства C6000, построенные на основе ядра С62хх и в перспективе С64хх;
• С5000 Code Composer - поддерживаются соотвественно ЦСП на базе ядра С54хх и С55хх;
• С2000 Code Composer - ЦСП семейств С2хх, С24хх, а также С5х;
• С3х/C4х Code Composer - ЦСП с плавающей точкой семеств С4х, С3х, VC33.

Для всех семейств при этом используется единый отладочный интерфейс.

Конфигурация аппаратной части

Верн╦мся к тому, чем мы закончили предыдущую статью. У нас есть один или несколько JTAG-эмуляторов и подключенные к ним ЦСП, с которыми мы собираемся работать. Первым шагом работы с CCS является задание конфигурации аппаратной части отлаживаемой ЦСП системы (в литературе ещ╦ употребляется термин "целевая система" - target system).

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

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

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

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

Учитывать все эти нюансы и максимумально использовать функциональные возможности устройств позволяет принятая в CCS архитектура подключения отлаживаемой подсистемы.

Модульность построения CCS проявляется уже на этом начальном этапе. Основной блок - сервер отладки (target server). Это модуль, который отвечает за обмен со средствами внутрисхемной эмуляции. С одной стороны, к нему подсоединяются все внутренние модули CCS и дополнительные модули пользователя (PlugIn), а с другой - совокупность отлаживаемых систем (рис. 2).

Рисунок 2. Подключение аппаратной части отлаживаемой системы к CSS

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

Конфигурация отлаживаемой системы зада╦тся в виде дерева в программе визуального конфигурирования Code Composer Setup (рис. 3).

Рисунок 3. Пример задания конфигурации отлаживаемой системы при помощи Code Comproser Setup

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

К каждому драйверу подключается один или несколько ЦСП. Кроме того, если в состав JTAG-пути входит неподдерживаемое устройство, то для него возможно задание режима пропуска (на нашем примере BYPASS1).

Встроенный язык скриптов GEL

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

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

Создатели CCS нашли удачный компромиссный вариант между разумной функциональностью системы и предоставлением разработчику возможностей задания е╦ поведения. В CCS встроен язык описания сценариев - GEL (General Extention Language) - в буквальном переводе, язык расширения. Это внутренний язык с С-подобным синтаксисом. Использование языка GEL да╦т разработчику возможность описания поведения системы на алгоритмическом уровне с использованием готовых библиотечных элементов. При этом функции языка GEL могут встраиваться практически во все элементы интерфейса и во все функции CCS. По сути это лишь слегка ограниченная возможность дописывать к CCS свои участки кода.

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

Привед╦м простой пример. Вот есть точка останова: остановиться при переходе на определ╦нный адрес программы. Просто, понятно, но не гибко и не удобно, особенно в ЦОС-приложениях - остановив программу, не всегда можно безболезненно е╦ продолжить, поскольку приложение работает с внешним сигналом в реальном времени, да и периферийные устройства не всегда безболезненно воспримут останов управляющей программы. Вот если бы условие для точки останова задать. Хорошо. Вводим условную точку останова: остановиться при переходе на определ╦нную строчку программы, если выполнено условие. Вс╦ красиво и функционально, осталость только выяснить, как задать это самое условие. При помощи системы установок? Какой бы сложной эта система не была, всегда найд╦тся ситуация, которую она не опишет. Разработчики CCS предлагают пользователю программы просто написать это выражение самому, при помощи синтаксиса языка С. Просто и удобно. При этом вс╦ обрамление уже есть - надо только вписать в нужное место ключевое выражение. Требования, например, такого вида как: остановиться, если удвоенная энергия сигнала (переменная программы), превышает пороговое значение более чем в 2 раза, - задаются и реализуюся программными средствами.

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

• создание элементов графического пользовательского интерфейса (GUI) для управления отлаживаемой ЦОС-программой;
• диагоностика аппаратной части;
• начальная установка и конфигурирование;
• автоматизация часто выполняемых последовательностей команд;
• добавление пунктов в меню;
• функции работы с отлаживаемым ЦСП: изменение содержимого памяти и регистров, загрузка программы, добавление и удаление точек останова, сброс ЦСП;
• возможности работы с создаваемыми в рамках интерфейса CCS окнами ввода/вывода.

То есть фактически при помощи GEL можно сделать вс╦ то, что можно сделать при помощи пользовательского интерфейса CCS, но только в автоматизированном режиме, что, в сочетании с возможностью добавления дополнений (PlugIn), позволяет строить на базе CCS уже практически программируемые тестовые и управлющие комплексы для разрабатываемого устройства.

Конфигурация объектов

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

В CCS предлагается промежуточная модель: статически конфигурируемое ядро реального времени DSP/BIOS, которое да╦т базовый набор функций реального времени, таких как переключение нитей, ввод/вывод с малой задержкой и обмен между отлаживаемой программой и отладчиком. Также в DSP/BIOS входят средства анализа реального времени, которые позволяют реализовывать взаимодействие с ЦСП программой непосредственно во время выполнения без использования точек останова. Полностью DSP/BIOS занимает около 2 Кслов памяти и требует менее 1 MIPS производительности. Детально состав и функциональные возможности DSP/BIOS будут рассмотрены в следующей статье. DSP/BIOS построен как полностью статическое ядро. Все его ресурсы конфигурируются перед компиляцией программы.

Для задания конфигурации ресурсов DSP/BIOS используется специальная графическая утилита, с помощью которой конфигурируются и инициализируются все объекты DSP/BIOS (рис. 4).

Рисунок 4. Конфигурирование объектов DSP/BIOS

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

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

Интегрированная среда разработки

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

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

Менеджмент проектов

Итак, мы запустили CCS. Первое открываемое по умолчанию окно и первое понятие, с которым мы сталкиваемся - это проект и, соответственно, система управления проектами - менеджер проектов. Разрабатываемые проекты представляют собой достаточно сложные структуры, которые состоят из целого набора, объектов, таких как библиотеки, файлы заголовков, GEL-скрипты, командные файлы и множество исходных текстов. Число файлов может достигать нескольких десятков. Для удобного управления всем этим конгломератом объектов и его структуризации и служит менеджер проектов, который организует все файлы проекта в разбитое по категориям дерево с удобной навигацией. Добавления и изменение состава проекта производятся простым перемещением файлов методом dragn-drop, в том числе, и из стандартного File Explorer, а двойное нажатие мышкой приводит к открытию или редактированию выбранного файла. Окно менеджера проектов да╦т ч╦ткое графическое представление о структуре и проекта и его составных частей.

В составе проекта хранятся и все конфигурационные файлы, включая конфигурацию DSP/BIOS, а также опции средств генерации кода, которые задаются теперь не просто ключами командной строки, а при помощи специальной графической утилиты (рис. 5).

Рисунок 5. Задание опций средств генерации кода

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

Интегрированный редактор

Для редактирования файлов в CCS используется встроенный многооконный редактор с дружественным оконным интерфейсом, аналогичный используемому в MS Visual C++, но имеющий специфические необходимые для DSP расширения. Встроенный редактор имеет систему подсветки синтаксиса для всех типов используемых в CCS файлов, включая GEL-скрипты. Написание, редактирование и отладка кода производятся в едином интерфейсе. Удобству работы способствуют такие функциональные возможности как контекстно зависимые меню, вызываемые правой кнопкой мыши, и плавающие конфигурируемые панели инструментов. Интересной особенностью редактора является включение в контекстно-зависимую систему помощи и систему проверки синтаксиса описания системы команд отлаживаемого DSP, что во многих случаях избавляет от необходимости держать на столе пару лишних томов документации и периодически в них заглядывать.

Если речь зашла о системе помощи, то нельзя не сказать, что встроенная система помощи CCS да╦т ч╦ткое описание всех его функциональных возможностей. Включенная в состав системы помощи программа обучения из последовательных уроков да╦т наглядное представление о последовательности действий и функциональных возможностях интегрированной среды. Наличие системы обучения экономит очень большой объ╦м времени на старте, снимая практически 95% вопросов "А мне бы сделать┘".

Средства генерации кода

Отдельного рассмотрения заслуживает принятый в технологии eXpressDSP и реализованный в CCS подход к выбору языка написания ЦОС- программ. До недавнено времени уделом программистов на ЦСП был ассемблер, ассемблер и ещ╦ раз ассемблер, однако условия работы меняются, и на современном этапе надо учитывать целый ряд изменившихся факторов. С одной стороны, усложнение алгоритмов делает их реализацию на ассемблере вс╦ более громоздкой и трудо╦мкой. С другой стороны, вс╦ более и более ж╦стко поджимают сроки проведения разработки. Одновременно, усложнение архитектуры самих ЦСП и внедрение параллельных решений требуют от разработчика держать в голове вс╦ больший объ╦м информации, отвлекая его от основной задачи - разработки собственно алгоритма.

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

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

В состав CCS входит специально разработанные TI для ЦOC-применений средства генерации и оптимизации кода. Прич╦м для каждого семейства ЦСП имеется свой набор таких средств, ориентированный на получение наиболее оптимального кода. Эффективность выходного кода достигается максимальным использованием ресурсов ЦСП при построении кода с уч╦том специфики его архитектуры. Ярким примером оптимизации служит генерация кода для ЦСП семейства С6000. Как показано на рис. 6, использование особенностей параллельной архитектуры ЦСП позволяет существенно сократить количество тактов выполнения даже для такого простого случая как:

int DotProduct( int *m, int *n, int count)
{int i, int sum=0;
for (i=0; i sum += m[i] * n[i];
return sum;
}

Рисунок 6. Оптимизация выполнения кода

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

Как показано на рис. 7, наилучшего результата можно достичь, используя написание программы на ассемблере, и ручной оптимизацией. Примем этот результат за 100% эффективности. Но при этом трудо╦мкость процесса крайне велика. Если писать на линейном ассемблере, с использованием ассемблерного оптимизатора, то эффективность составляет 95√100% при средней трудо╦мкости. Наименее трудо╦мкий процесс - написание программы на С, при этом эффективность кода составляет 70√80%, а трудо╦мкость самая низкая и отличается от трудо╦мкости ручной оптимизации зачастую в несколько раз - один и тот же алгоритм можно написать за неделю на С или отлаживать месяц-другой на ассемблере.

Рисунок 7. Сравнение методов написания кодов

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

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

Для своих ЦСП фирма TI выпускает свободно доступные DSPLib - библиотеки оптимизированных ассемблерных ЦОС-функций с заголовками для вызова их из С-программ, использование которых существенно повышает оптимальность кода.

При рассмотрении эффективности средств генерации кода не следует забывать и об удобстве работы с ними в составе интегрированной среды разработки:

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

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

Интегрированный отладчик

В состав CCS входит и встроенный отладчик, интерфейс которого, как и у редактора, аналогичен MS Visual C, но имеет целый ряд DSP-расширений. Фактически, окно отладчика - это и есть окно редактирования, только в н╦м можно производить отладочные действия.

Точки останова и контроля

Встроенный отладчик CCS имеет три типа точек останова, вернее даже точек контроля и воздействия на выполнение программы, поскольку точки останова только одного типа являются точками останова в чистом виде:

• точки останова (Break Points);
• точки пробники (Probe Points);
• профильные точки (Profile Points).

Точки останова служат для останова программы в требуемом месте. В CCS различаются два типа точек останова: программные - по попаданию программы на определ╦нный оператор и аппаратные - по выполнению определ╦нной операции на шине, что позволяет как отслеживать последовательность выполнения программы, так и быстро локализовывать, например, такие неприятные ситуации, как порча по непонятным причинам данных в памяти или выход индекса массива за его пределы. Достаточно просто поставить точку останова на операцию с подозрительной ячейкой ОЗУ. Точка останова может быть ещ╦ и условной. Для такой точки зада╦тся GEL-выражение, например "gain > 11", в случае выполнения которого происходит останов программы. Такой подход ещ╦ раз иллюстрирует широкие возможности задания поведения отладчика для максимальной адаптации его к конкретным условиям.

Следующим типом точки контроля является точка пробника (Probe Points). Если наличие точек останова - это, в принципе, стандартная возможность для любого отладчика, хотя в CCS возможности е╦ применения расширены, то точка пробника - это специальная возможность CCS, ориентированная именно на отладку ЦОС-программ. Фактически точка пробника - это программный аналог щупа осциллографа или логического анализатора, подключаемого к схеме. Точка пробника представляет собой подключаемый к определ╦нной точке программы канал для подачи или снятия данных. Обмен данными с точками пробника происходит прозрачно для исполняемой программы при помощи средств внутрисхемной эмуляции и средств отладчика. Опять же точки пробника могут быть условными и задаваться GEL-выражением.

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

На рис. 8 приведены примеры использования точек пробника.

Рисунок 8. Примеры использования точек пробника

При прохождении первой точки пробника (именно при прохождении, а не при останове на точке пробника), записанный в файле сигнал пода╦тся отлаживаемой на ЦСП программе в качестве входного тактового сигнала.

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

Средства визуализации данных

Встроенные средства визуализации данных позволяют просматривать данные и сигналы в их оригинальных форматах во множестве окон просмотра. Окна просмотра присоединяются к точкам подключения, и их содержимое изменяется в реальном времени во время выполнения программы. В состав Code Composer Studio включены стандартные окна просмотра как классических обработчиков, таких как БПФ, так и для популярных коммуникационных форматов, таких как глаз-диаграмма, созвездие, а также средства отображения изображений.

Что дальше?

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