Ю. Гончаров

 

Технология 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-х основных ветвей ЦСП:

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

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

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

  То есть фактически при помощи 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-скрипты, командные файлы и множество исходных текстов. Число файлов может достигать нескольких десятков. Для удобного управления всем этим конгломератом объектов и его структуризации и служит менеджер проектов, который организует все файлы проекта в разбитое по категориям дерево с удобной навигацией. Добавления и изменение состава проекта производятся простым перемещением файлов методом drag-n-drop, в том числе, и из стандартного File Explorer, а двойное нажатие мышкой приводит к открытию или редактированию выбранного файла. Окно менеджера проектов даёт чёткое графическое представление о структуре и проекта и его составных частей.
  В составе проекта хранятся и все конфигурационные файлы, включая конфигурацию DSP/BIOS, а также опции средств генерации кода, которые задаются теперь не просто ключами командной строки, а при помощи специальной графической утилиты (рис. 5).

(рис 5) Задание опций средств генерации кода

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

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

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

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

  Отдельного рассмотрения заслуживает принятый в технологии eXpressDSP и реализованный в CCS подход к выбору языка написания ЦОС- программ. До недавнено времени уделом программистов на ЦСП был ассемблер, ассемблер и ещё раз ассемблер, однако условия работы меняются, и на современном этапе надо учитывать целый ряд изменившихся факторов. С одной стороны, усложнение алгоритмов делает их реализацию на ассемблере всё более громоздкой и трудоёмкой. С другой стороны, всё более и более жёстко поджимают сроки проведения разработки. Одновременно, усложнение архитектуры самих ЦСП и внедрение параллельных решений требуют от разработчика держать в голове всё больший объём информации, отвлекая его от основной задачи — разработки собственно алгоритма.
  Ещё одной особенностью является ускорение развития ЦСП и более быстрая смена семейств, что требует обеспечить большую степень “платформенной” независимости и лучшую переносимость как между ЦСП одного семейства, так и между семействами ЦСП.
  Совокупность приведённых факторов определяет смену концепции — переход от написания ассемблерных программ с ручной оптимизацией к написанию алгоритмов на языке высокого уровня — С. С учётом специфики ЦОС-задач, при их написании на С на первое место встаёт эффективность компилятора по объёму кода и по скорости его выполнения.
  В состав CCS входит специально разработанные TI для ЦOC-применений средства генерации и оптимизации кода. Причём для каждого семейства ЦСП имеется свой набор таких средств, ориентированный на получение наиболее оптимального кода. Эффективность выходного кода достигается максимальным использованием ресурсов ЦСП при построении кода с учётом специфики его архитектуры. Ярким примером оптимизации служит генерация кода для ЦСП семейства С6000. Как показано на рис. 6,

(рис 6) Оптимизация выполнения кода

использование особенностей параллельной архитектуры ЦСП позволяет существенно сократить количество тактов выполнения даже для такого простого случая как:

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

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

(рис 7) Сравнение методов написания кодов

наилучшего результата можно достичь, используя написание программы на ассемблере, и ручной оптимизацией. Примем этот результат за 100% эффективности. Но при этом трудоёмкость процесса крайне велика. Если писать на линейном ассемблере, с использованием ассемблерного оптимизатора, то эффективность составляет 95–100% при средней трудоёмкости. Наименее трудоёмкий процесс — написание программы на С, при этом эффективность кода составляет 70–80%, а трудоёмкость самая низкая и отличается от трудоёмкости ручной оптимизации зачастую в несколько раз — один и тот же алгоритм можно написать за неделю на С или отлаживать месяц-другой на ассемблере.
  При ручной оптимизации максимальная эффективность достижима, но где гарантия, что разработчик найдёт именно тот самый оптимум, даже потратив несколько месяцев не только на саму оптимизацию, но и на исправление неизбежных при этом ошибок. С учётом того, что современные ЦСП имеют запас по производительности, а время, отпущенное на разработку, зачастую является наиболее критичным фактором, не лучше ли иметь гарантированную эффективность при минимальном времени разработки и количестве ошибок? С учётом того, что структура ЦСП всё усложняется, не лучше ли поручить оптимизацию кода компилятору, который ничего, например, с теми же длительностями команд, не напутает и ничего, в отличие от человека, не забудет, а разработчику оставить написание самого алгоритма, а не укладывание его в рамки конкретного процессора.
  Как показывает практика, написание программ для ЦСП на С в современных условиях при использовании оптимизирующих компиляторов, эффективность которых непрерывно повышается, является оптимальным решением по соотношению времени разработки и получаемой эффективности кода. А с учётом всё более жёстких временных рамок и растущей сложности алгоритмов — единственно возможным методом.
  Для своих ЦСП фирма TI выпускает свободно доступные DSPLib — библиотеки оптимизированных ассемблерных ЦОС-функций с заголовками для вызова их из С-программ, использование которых существенно повышает оптимальность кода.
  При рассмотрении эффективности средств генерации кода не следует забывать и об удобстве работы с ними в составе интегрированной среды разработки:

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

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

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

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

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

  Точки останова служат для останова программы в требуемом месте. В CCS различаются два типа точек останова: программные — по попаданию программы на определённый оператор и аппаратные — по выполнению определённой операции на шине, что позволяет как отслеживать последовательность выполнения программы, так и быстро локализовывать, например, такие неприятные ситуации, как порча по непонятным причинам данных в памяти или выход индекса массива за его пределы. Достаточно просто поставить точку останова на операцию с подозрительной ячейкой ОЗУ. Точка останова может быть ещё и условной. Для такой точки задаётся GEL-выражение, например “gain > 11”, в случае выполнения которого происходит останов программы. Такой подход ещё раз иллюстрирует широкие возможности задания поведения отладчика для максимальной адаптации его к конкретным условиям.
  Следующим типом точки контроля является точка пробника (Probe Points). Если наличие точек останова — это, в принципе, стандартная возможность для любого отладчика, хотя в CCS возможности её применения расширены, то точка пробника — это специальная возможность CCS, ориентированная именно на отладку ЦОС-программ. Фактически точка пробника — это программный аналог щупа осциллографа или логического анализатора, подключаемого к схеме. Точка пробника представляет собой подключаемый к определённой точке программы канал для подачи или снятия данных. Обмен данными с точками пробника происходит прозрачно для исполняемой программы при помощи средств внутрисхемной эмуляции и средств отладчика. Опять же точки пробника могут быть условными и задаваться GEL-выражением.
  В отличие от точки останова, при прохождении точки пробника выполнение программы не останавливается. При попадании на точку пробника может быть выполнено множество различных функций: поданы или сняты данные, перерисованы окна визуализации сигнала или выполнен GEL-скрипт.

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

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

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

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

  Что дальше?

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






Реклама на сайте
тел.: +7 (495) 514 4110. e-mail:admin@eust.ru
1998-2014 ООО Рынок микроэлектроники