В предыдущих статьях цикла мы рассмотрели общий состав технологии eXperssDSP и структуру среды разработчика Code Composer Studio. Теперь перейдём к рассмотрению тех элементов технологии, которые относятся к программному обеспечению самих сигнальных процессоров - ядру реального времени DSP/BIOS версии II, которое в дальнейшем будем называть просто DSP/BIOS.

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

DSP/BIOS представляет собой ядро реального времени, которое предоставляет разработчику следующие сервисы:

гибкий планировщик задач с возможностью мультизадачной работы;

уровень аппаратной абстракции для работы с периферийными устройствами процессора;

устройство независимого ввода/вывода для передачи потоков данных в реальном времени;

средства анализа поведения ЦОС-приложения и обмена с ним данными в реальном времени.

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

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

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

Для реализации этих достаточно противоречивых требований при построении DSP/BIOSбыла выбрана следующая модель: DSP/BIOS является статически конфигурируемым ядром реального времени со статически определяемой приоритетной моделью исполнения процессов. Что же достигается такой моделью? Во-первых, минимизация дополнительных расходов памяти, поскольку в исполняемый код включаются только модули, необходимые при реализации данной задачи, а не вся операционная среда. Во-вторых, достигается оптимизация производительности процессора, поскольку большинство статических вызовов после компиляции упаковываются в несколько команд. Далее, поскольку время выполнения команд ЦСП известно, конфигурация системы задаётся статически и тоже известна, модель исполнения и система приоритетов также задаётся статически, то мы имеем полностью предсказуемое и однозначно определённое поведение системы.

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

Как уже говорилось, при построении любой операционной системы важным вопросом является дополнительный расход ресурсов на предоставляемые ей сервисы. В операционной системе реального времени, кроме расхода ресурсов процессора и памяти, добавляется ещё и фактор расхода времени. С учётом достаточно ограниченных ресурсов систем ЦОС, а также очень жёстких временных рамок, очень большое значение имеет правильный выбор операционной среды. С одной стороны, ОС должна предоставлять достаточно гибкий и удобный набор функциональных возможностей, а с другой - расходовать как можно меньше ресурсов. При построении DSP/BIOS была выбрана многоуровневая модель построения системных сервисов. Для каждой области имеются несколько типов вызовов, аналогичных по назначению, но различных по функциональным возможностям и, соответственно, по расходуемым ресурсам. Так, существует нить типа "прерывание" с базовыми возможностями и очень малым временем реакции и существует нить типа "задача" с гораздо большим набором предоставляемых сервисов, но и с другими временными параметрами переключения и отработки. Аналогично, существует статическое распределение памяти, которое вообще не потребляет ресурсов процессора, так как задаётся утилитами конфигурации. Кроме того, существует динамическое распределение памяти, использование которого требует включения в исполняемый код соответствующего модуля и работает через системные вызовы, но позволяет разным процессам использовать ОЗУ совместно. Такая модель, совместно с моделью конфигурирования самого ядра DSP/BIOS, когда в выходной код добавляются только используемые компоненты, позволяет сочетать быстрое время реакции и малый объём дополнительного кода с широкими функциональными возможностями операционной системы реального времени.

Одной из задач, решаемых DSP/BIOS, является предоставление разработчику уровня аппаратной абстракции, то есть единого логического интерфейса работы с аппаратной частью системы ЦОС, при этом учёт особенностей работы аппаратных узлов того или иного ЦСП возлагается на инструментальные средства. При этом имеется как интерфейс к программированию узлов ядра процессора, таким как таймер и контроллер ПДП, так и стандартный интерфейс для организации каналов ввода/вывода, включающий в себя драйверы периферийных устройств, драйверы портов, к которым они подключаются, например McBSP, и средства организации стандартных потоков ввода/вывода.

При правильном использовании средств DSP/BIOS вполне достижим уровень аппаратной абстракции, при котором получается полная междуплатформенная переносимость приложения. Фактически, сбывается очень давняя мечта разработчиков - если на конечной стадии разработки выяснится, что ресурсов выбранного ЦСП не хватает или, что ещё более болезненно, законченная и с таким трудом упакованная задача требует расширения, то можно просто перейти на более мощный ЦСП, при это можно даже поменять платформу, ничего не меняя в написанном, проверенном и отлаженном коде. Ещё одно преимущество переносимости - обратный процесс оптимизации. Можно взять мощный ЦСП, спокойно написать и отладить задачу, имея запас производительности для сервиса и отладки, на обкатку вариантов реализации и на оптимизацию участков кода, а затем, отладив и оптимизировав задачу, перенести её на оптимальный по параметрам и цене ЦСП для серийного выпуска устройства. С учётом наличия ЦСП различной мощности и объёма памяти в совместимых корпусах, возможности практически безболезненного переноса позволяют производить как функционально-стоимостную оптимизацию, так и модернизацию устройства без дорогостоящих затрат на модернизацию аппаратных составляющих устройства, например, на переразводку печатных плат. Как пример аппаратной совместимости, приведём ЦСП семейства С5000, где в одном корпусе и совместимыми по выводам выпускаются ЦСП от 'VC5401 (50 MIPS, 8 Кслов ОЗУ, цена менее $6) до 'VC5416 (160 MIPS, 128 Кслов ОЗУ), причём параллельно с ЦСП выпускается и совместимая по выводам номенклатура компонентов поддержки, таких как микросхемы источников и супервизоров питания.

Использование библиотек поддержки микросхем (Chip Support Library), абстрагирующих аппаратный уровень основных функций, библиотек ЦОС-функций (DSP Library), предоставляющих оптимизированные для каждой платформы основные ЦОС-алгоритмы с единым интерфейсом, интерфейсов DSP/BIOS для управления выполнением приложения, а также оптимизирующих компиляторов с языка С для написания алгоритмов, позволяет создать реально абстрагированное, "отвязанное" от конкретной платформы ЦОС-приложение. Причём это приложение не будет являться лабораторным экспериментом, а будет реальной "боевой" разработкой с достаточным для практического применения уровнем оптимальности исполнения.

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

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

Компоненты DSP/BIOS

Рассмотрим основные компоненты DSP/BIOS в среде разработчика Code Composer Studio, показанные на рис. 1.

Рис. 1. Компоненты DSP/BIOS

На хост-компьютере пишутся исходные файлы проекта (на С, С++ или ассемблере), использующие интерфейсы DSP/BIOS API. Затем с помощью утилиты конфигурирования определяются те компоненты, которые будут использоваться в проекте, и их параметры. Исходные тексты, библиотека DSP/BIOS и файлы конфигурации образуют проект, из которого средствами генерации кода получается исполняемый файл, который загружается в ЦСП. Встроенные средства анализа CodeComposerStudio позволяют производить мониторинг исполнения программы.

Рис. 2. Утилита конфигурации

DSP/BIOS достаточно сложная статически конфигурируемая система, для задания конфигурации которой используется специальная графическая утилита, интегрированная в Code Composer Studio (рис. 2). Утилита конфигурации - это специализированный визуальный редактор, который позволяет выбирать, какие модули DSP/BIOS будут включены в систему, а какие нет, а также задавать их параметры. Все параметры задаются статически до компиляции. При этом утилита конфигурации позволяет оценить объём требуемой под служебные нужды памяти, а также проверить соответствие заданных параметров, что позволяет избежать ошибок уже на начальном этапе конфигурации системы и сэкономить время на старте. Ещё одной функцией утилиты конфигурации является привязка проекта к конкретной аппаратной платформе. Именно в утилите конфигурации задаются параметры карты памяти, распределения прерываний и привязки тактовой частоты процессора к системным часам реального времени. При этом для различных ЦСП существуют уже готовые начальные схемы конфигурации DSP/BIOS.

Все модули ядра реального времени DSP/BIOS могут быть разбиты на 6 групп, каждая их которых предоставляет свой интерфейс (API) пользовательским приложениям:

группа функций анализа реального времени и обмена данными;

функции аппаратной абстракции;

функции ввода/вывода, независимые от аппаратных устройств;

функции управления выполнением нитей;

функции взаимодействия и синхронизации нитей;

прочие функции.

Мультиниточная приоритетная модель построения

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

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

Многониточное приложение может выполняться на одном процессоре за счёт того, что более приоритетные нити могут прерывать исполнение менее приоритетных (рис. 3). В DSP/BIOS существует 30 уровней приоритета, разбитых на 4 класса исполняемых нитей. DSP/BIOS также предоставляет средства синхронизации исполнения нитей и средства коммуникации между ними. При построении многониточной системы также допускается использовать потоки с разной частотой дискретизации.

Рис. 3. Приоритетная модель исполнения нитей

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

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

В DSP/BIOS существует четыре типа нитей, которые разбиваются на два класса - прерывания и задачи. Эти классы отличаются моделью исполнения и видами вызова и завершения.

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

При помощи Конфигурационной Утилиты обработчики привязываются к конкретным источникам прерываний, задаётся расположение в памяти таблицы прерываний и самого модуля менеджера HWI.

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

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

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

Рис. 4. Приоритеты исполняемых нитей

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

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

Имея минимальные дополнительные затраты на переключение контекста, программные прерывания являются идеальным механизмом для структурирования приложений, которые исполняют множество параллельных алгоритмов на разных скоростях, например, в телекоммуникационных приложениях, где имеется обработка звуковой информации, обычно проводимая на частотах 8-16 кГц и обработка фреймов данных, длительностью 1-20 мс. Каждая из задач имеет свои временные рамки и требует своих затрат производительности. Поскольку имеется обусловленная техническими особенностями регулярная последовательность генерации событий, то ориентация процессов с более критическими временами исполнения на программные прерывания с большим приоритетом позволит оптимально распределить процессорное время.

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

Периодические функции

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

Рис. 5. Периодические функции

Эти функции выполняются модулем PRD. В модуле имеются системные часы - 32-разрядный счётчик, который изменяется каждый раз при вызове функции PRD_tick(). Функция PRD_tick может вызываться как обработчиком прерывания от системного таймера, который будет управлять системными часами, так и любым другим периодическим процессом, например, тактовой частотой приёма данных. Далее менеждер PRD позволяет разработчику планировать исполнение процессов с различной частотой. Можно создавать несколько PRD-объектов с разным периодом вызова. Поскольку все PRD-объекты управляются одним и тем же системным тактовым сигналом, то период вызова определяется целым числом тактов системного тактового сигнала или вызовов PRD_tick(). Нектороые приложения требуют только однократного исполнения функции после определённого периода задержки. Для таких случаев предусмотрен режим однократного запуска периодической функции.

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

Синхронизируемые задачи

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

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

Работой с задачами в DSP/BIOS занимается модуль TSK. Задачи исполняются в соответствии со своим приоритетом. Имеется 15 уровней приоритета плюс остановленное состояние (отрицательный приоритет).

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

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

Рис. 6. Состояния задачи

Каждая задача может находиться в одном из четырёх состояний исполнения (рис. 4):

выполнение - выполнением данной задачи занимается процессор;

готовность - задача поставлена в очередь на исполнение и ждёт освобождения процессора;

блокировка - задача не исполняется, а ожидает, когда произойдёт определённое системное событие;

удаление - задача удалена и не будет продолжать выполняться снова.
Как уже было сказано выше, задачи ставятся на выполнение в соответствии с уровнем приоритета.

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

Задачи в DSP/BIOS очень похожи на аналогичные задачи в других распространённых системах реального времени, таких как PSOP, VxWorks и Nucleus. Разработчики, работавшие в этих средах, найдут работу в DSP/BIOS привычной, но более удобной.

Средства межпроцессорной коммуникации и синхронизации

Кроме возможности обмена потоками данных общего вида, которая будет рассмотрена позже, в DSP/BIOS предусмотрены специальные средства синхронизации процессов и специальные средства быстрого и простого обмена небольшими объёмами данных.

Базовым средством синхронизации задач являются семафоры. В DSP/BIOS реализованы счётные семафоры. Счётный семафор хранит внутренний счётчик состояния. Если счётчик отличен от нулевого значения, то задача при запросе семафора не блокируется. Наличие внутри семафора не логического значения, а счётчика даёт возможность применять различные схемы междупроцессорной синхронизации.

При создании семафор инициализируется определённым значением. Обычно - это количество ресурсов, которые синхронизирует семафор. Операции с семафором включают ожидание (pending) - уменьшение счётчика семафора и отправка (posting) - увеличение счётчика. SEM_pend() ожидает семафора, а SEM_post() используется для установления семафора. Если задача ожидает семафора, то вызов SEM_post() переводит её из очереди задач, ожидающих семафора, в очередь задач, имеющих статус "готовность" и стоящих в очереди на исполнение.

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

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

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

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

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

Второй тип - очереди. В отличие от почтового ящика, очередь может содержать несколько элементов (сообщений), которые могут быть поставлены в очередь или взят из очереди. Все сообщения в очереди обрабатываются по принципу FIFO: первым поставлен в очередь - первым считан из очереди.

Модуль RTA - средства анализа реального времени

Средства анализа реального времени дают разработчикам возможность анализа контроля поведения приложения во время его исполнения . Все эти средства фактически работают через один и тот же JTAG-интерфейс, через который работает и отладчик, используя его как относительно низкоскоростной канал реального времени. Большая часть средств анализа реального времени требует наличия в памяти процессора ядра реального времени DSP/BIOS. Кроме предоставления выполняемых сервисов для средств анализа, ядро DSP/BIOS поддерживает физический канал связи реального времени с хост-компьютером. Кроме того, используя ядро DSP/BIOS для построения приложений с целью использовать его мультизадачные возможности и сервисы ввода/вывода, разработчики автоматически получают инструмент для снятия и передачи в реальном времени информации, которая используется средствами анализа и визуализации среды разработки Code Composer Studio. Предоставляемые модулем RTA сервисы можно разделить на следующие группы:

Журнал сообщений (Message Event Log) - средства отображения упорядоченной по времени последовательности событий, записываемых в журнал ядра независимыми нитями, что позволяет отслеживать и протоколировать исполнение программы. Приложение может записывать события в журнал через вызовы DSP/BIOS. Также события могут заноситься в журнал средствами ядра при отслеживании состояния нити. Сбор статистики (Statistic Accumulators) - средства отображения статистики исполнения, собираемой во внутреннем аккумуляторе ядра. Статистика отображает динамические параметры процесса выполнения ядра, начиная от простых счётчиков и изменения во времени данных, до вычисления ожидаемого интервала исполнения независимых нитей. Сбор статистики выполняется непосредственно через вызовы DSP/BIOS или же средствами самого ядра, отслеживающими распределение и исполнение нитей, а также выполнение ими операций ввода/вывода.

Каналы обмена данных с хост-компьютером (Host Data Channels) - средства связи объектов ввода/вывода ядра и файлов - расположены в хост-компьютере и позволяют организовывать между ними стандартные потоки данных. Они используются для тестирования и анализа поведения алгоритмов. Эта группа сервисов также позволяет перехватывать на лету любые другие пересылки потоков данных через модули ядра и отсылать их в хост-компьютер для последующего анализа.

Сервер управляющих команд (Host Command Server) - средства контроля трассировки и сбора статистики в программе.

Использование средств анализа реального времени (рис. 7) интегрированно с возможностями отладчика Code Composer Studio даёт возможность анализа поведения программы в те моменты, когда обычно отладчик не используется - во время исполнения программы.

Рис. 7. Средства анализа Code Composer Studio

Обмен данными с хост-компьютером в реальном времени - технология RTDX (Real Time Data Exchange)

Технология RTDX (рис. 8) позволяет производить обмен данными между хост-компьютером и системой на базе ЦСП без помех исполняемому на ЦСП приложению. Этот двунаправленный канал реального времени позволяет как производить сбор и анализ данных хост-компьютером, так и взаимодействовать с исполняемым ЦОС-приложением. Данные, принятые от ЦСП, могут использоваться для анализа и визуализации на хост-компьютере. При этом параметры приложения могут подстраиваться по командам хост-компьютера без остановки приложения. RTDX-каналы позволяют производить полное тестирование алгоритмов при помощи стандартных отладочных средств - подачу тестовых воздействий на ЦОС-приложение и анализ получаемых результатов.

Рис. 8. Структура обмена данными RTDX

RTDX имеет два уровня - программный и аппаратный. Небольшая RTDX библиотека исполняется на ЦСП. ЦОС-приложение обращается к вызовам этой библиотеки, когда необходимо считать или записать данные в RTDX-канал. Аппаратный уровень образуется средствами внутрисхемной JTAG эмуляции, которые обеспечивают обмен данных по отладочному интерфейсу между ЦСП и хост-компьютером. Передача данных обеспечивается в реальном времени, параллельно с исполнением ЦОС-приложения, при этом на последних моделях ЦСП, таких как VC55xx, обеспечивается непрерывный поток данных со скоростью до 2 Мб/с.

На хост-платформе RTDX библиотека работает интегрированно с Code Composer Studio. Средства анализа и визуализации данных работают с библиотекой RTDX через стандартный интерфейс COM API. Возможна работа с RTDX не только средств CodeComposerStudio, но и других стандартных средств анализа и визуализации, работающих через интерфейс COM, например, пакета LabVIEW фирмы NATIONAL INSTRUMENTS или электронных таблиц Microsoft Excel.

Хост-библиотека RTDX поддерживает два режима работы - напрерывный и периодический. В непрерывном режиме данные просто накапливаются во внутреннем буфере RTDX библиотеки и не записываются в файл. Этот режим используется, когда надо непрерывно снимать и отображать данные ЦОС-приложения и не надо сохранять их в файл. В периодическом режиме данные записываются в файл. Этот режим используется, когда надо собирать большие объёмы данных и хранить их в файле.

Уровень абстрагирования аппаратного обеспечения

Одной из составляющих DSP/BIOS являются функции для работы с базовыми аппаратными компонентами, независимо от их физического воплощения. Интерфейс абстрагирования аппаратного обеспечения даёт возможность работы с основным аппаратным обеспечением через простой логический интерфейс, независимый от самого устройства. При абстрагировании таких компонентов, как, например, таймер и аппаратные прерывания, существенно облегчается переход от устройства к устройству. Поскольку разные ЦСП имеют разный набор периферии, то в состав DSP/BIOS включена библиотека поддержки конкретного ЦСП - Chip Support Library (CSL), в которой содержатся функции работы со всеми его функциональными модулями.

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

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

Часы реального времени

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

Использование такой привязки абстрагирует системные часы от конкретного ЦСП и привязывает их к реальному времени. А поскольку к системным часам привязывается планировщик нитей и планировщик периодических процессов, то и вся система привязывается к реальному времени. Модуль CLK позволяет иметь два вида системных часов - высокого и низкого разрешений. Часы низкого разрешения обычно используются для планировщиков нитей и периодических функций. Часы высокого разрешения - прямая функция от такта ЦСП. Они показывают число, на которое изменился регистр таймера за время выполнения какой-либо операции. Часы высокого разрешения обычно используются для измерения времени исполнения функций или для измерения временных интервалов.

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

Более полную информацию о DSP/BIOS, среде разработки CodeComposerStudio, сигнальных процессорах, а также последние новости о других продуктах TEXAS INSTRUMENTS можно узнать на сервереwww.texas.ru.