WWW.KNIGA.SELUK.RU

БЕСПЛАТНАЯ ЭЛЕКТРОННАЯ БИБЛИОТЕКА - Книги, пособия, учебники, издания, публикации

 

Pages:     | 1 || 3 | 4 |

«Факультет ИСТ Кафедра ИВТ Конспект лекций по дисциплине Конструирование цифровых процессоров в среде Simulink Автор-составитель: Акчурин Э.А. д.т.н., профессор Редактор: ...»

-- [ Страница 2 ] --

Селектор прерываний. Периферия ПЦОС TMS320C6000 может иметь до 32-х источников прерываний. ЦПУ имеет возможность обрабатывать 12 прерываний. Селектор прерываний дает возможность выбора тех 12 прерываний, которые будут использоваться, и также дает возможность смены полярности внешних входов прерываний.

«Спящие» режимы. Логика снижения потребляемой мощности позволяет снимать тактовые сигналы с элементов ПЦОС для снижения энергопотребления.

Несмотря на свое предназначение для базовых станций, ПЦОС TMS320C также имеют режимы снижения энергопотребления. КМОП схемы в основном потребляют энергию в момент переключения, и чем выше частота работы, тем больше это потребление. При включении «спящих» режимов у ПЦОС снимается тактовая частота сначала с ядра ПЦОС, затем с периферии, размещенной на кристалле, и последний «третий» режим снимает тактовую частоту практически со всего кристалла, в том числе и с блока умножения частоты. ПЦОС имеет встроенный умножитель частоты с возможностью умножения внешней тактовой частоты на 2 и на 4, что делает возможным работу с низкой входной частотой и упрощает проектирование.

4.10. Средства разработки ПЦОС TMS320C Для разработчиков устройств на базе ПЦОС серии TMS320C6000 предлагается широкий набор мощных средств разработки и отладки. Новая архитектура ПЦОС данного семейства предполагает и новый подход к процессу разработки, который позволяют уменьшить время и стоимость создания проекта за счет переноса большей части работы на ПО средств разработки. Разработчику остается написать алгоритм на языке высокого уровня, а его реализация и оптимизация с использованием всех преимуществ архитектуры ПЦОС TMS320C6000 перекладывается на компилятор. Это снимает одну из основных трудностей при работе на ПЦОС с длинным командным словом – распараллеливание алгоритма. Такой подход имеет ряд преимуществ:

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

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

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

С-компилятор, ассемблер и компоновщик.

Отладчик.

Среда Code Composer Studio.

Высокоуровневый С-компилятор, ассемблер и компоновщик. Данные программные продукты представляют собой набор средств для компиляции кода языка С. Они специально ориентированы на реализацию оптимальных программ, созданных по алгоритмам ЦОС. Имеет широкий набор встроенных средств оптимизации, как общего плана, так и специализированных для ПЦОС TMS320С6000. Является ANSI совместимым компилятором. В состав данного продукта входит ассемблерный оптимизатор - средство для перевода последовательного ассемблерного кода в параллельный, специфичный для ПЦОС TMS320С6000.

Отдадчик. Продукт позволяет производить проверку выполнения кода на персональном компьютере без ПЦОС.

Code Composer Studio. Многомодульный программный продукт представляет собой мощную интегрированную отладочную среду для ПЦОС TMS320C6000 и других серий. Имеет развитый оконный интерфейс, встроенные средства редактирования, возможность дизассемблирования и вызова внешнего компилятора, расширенные средства визуализации данных. По оценкам изготовителей среда Code Composer Studio станет стандартом и останется, чуть ли не единственным продуктом для программирования ПЦОС компании Texas Instruments Inc. по крайней мере, до 2020 года.

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

Рассмотрим основные факторы, удорожающие и удлиняющие цикл разработки. Отметим интересную особенность - при усложнении самих устройств идт процесс упрощения разработки их аппаратной части за счт применения интегральных программируемых компонентов. При этом основные затраты при разработке нового изделия приходятся на разработку программного обеспечения. По данным журнала "Embedded System Programming", на разработку программного обеспечения встроенных систем в настоящее время тратиться до 80% времени цикла разработки.

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

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

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

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

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

5.2. Составляющие технологии eXpressDSP Первым аппаратным элементом eXpressDSP является интерфейс внутрисхемной эмуляции на базе тестового интерфейса IEEE 1149 JTAG. Это стандартный тестовый интерфейс, применяемый для тестирования электронных компонентов и устройств. Он имеется в каждом ЦСП Texas Instruments и с рядом дополнений используется как интерфейс внутрисхемного эмулятора. Его использование позволяет легко и просто интегрировать средства внутрисхемной эмуляции в состав разрабатываемого устройства. Интерфейс JTAG дат возможность подключения одного или нескольких ЦСП к одному отладчику с использованием всего 6 сигнальных линий.

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

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

Следующим элементом является технология RTDX - технология обмена данными в реальном времени (Real Time Data Exchange). Она позволяет максимально использовать возможности JTAG-интерфейса, интегрируя в него помимо возможностей внутрисхемной эмуляции возможности обмена данными в реальном времени между ЦСП и хост-компьютером, на котором запускается отладочная среда. Использование технологии RTDX позволяет объединить отлаживаемый ЦСП и хост-компьютер в единую систему с мощными функциями тестирования и анализа в реальном времени.

В качестве программного отладочного средства, работающего с внутрисхемными JTAG-эмуляторами и поддерживающего технологию RTDX, используется интегрированная среда разработчика (IDE) Code Composer Studio (CCS). Это интегрированный функционально законченный продукт, включающий в себя вс необходимое для редактирования, компиляции, отладки и анализа программ. CCS имеет удобный реконфигурируемый пользовательский интерфейс с удобными средствами редактирования кода и развитой системой контекстной помощи, в которую автоматически включается система команд отлаживаемого ЦСП. Для удобства ведения сложных разработок в CCS входят графические средства конфигурирования и ведения проектов.

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

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

Добавление к этому средств анализа реального времени, базирующихся на технологии RTDX, превращает CCS в средство анализа и тестирования в реальном времени.

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

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

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

Планирование: многониточность, тактирование и распределение времени.

Коммуникации: потоковый обмен, связь ЦСП и отладчика, технология Ресурсы: конфигурирование, статистика использования.

анализ: протоколирование событий, ввод/вывод из ЦСП программы, запись данных отладчика.

При использовании средств DSP BIOS мы фактически переходим от написания программы с чистого листа к оперированию терминами многозадачной операционной системы реального времени. При этом отладочные средства предоставляют возможность контроля и управления поведением такой системы. Одним из ключевых компонентов технологии eXpressDSP является DSP Algorithm Standard - набор правил и примов написания программных модулей.

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

Возможность сборки программы из отдельных написанных и оттестированных модулей породило рынок готовых реализаций алгоритмов, написанных в соответствии с DSP Algorithm Standard. Существует и развивается сообщество так называемых третьих поставщиков - фирм, выпускающих на рынок сертифицированные TI программные продукты, такие как, например, кодер MPEG или модем V.34. В данный момент зарегистрировано более 300 третьих поставщиков, и их количество постоянно увеличивается.

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

Следующим моментом стандартизации является стандартизация интерфейсов приложений (API) для стандартной периферии, такой как АЦП и ЦАП. Фактически все новые аналоговые интерфейсы для ЦСП от TI снабжаются драйверами под технологию eXpressDSP. В состав драйвера входят функции инициализации устройства и обмена с ним потоками данных. Драйверами могут снабжаться не только аналоговые интерфейсы, но и прочая периферия, что в свою очередь создат рынок третьих поставщиков аппаратных решений.

Кроме драйверов для периферийных устройств, TI выпускает для ЦСП так называемые библиотеки поддержки чипа (Chip Support Library), в которые входят API для инициализации и управления составными частями ядра ЦСП и его периферийными устройствами, такими как контроллер ПДП, таймер или последовательный порт.

Резюмируя, можно сказать, что разработчику ЦОС-систем предоставляется:

ядро и библиотеки реального времени;

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

библиотеки работы с ЦСП.

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

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

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

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

5.3. Внутрисхемные JTAG-эмуляторы Все ЦСП фирмы TI имеют единый отладочный интерфейс JTAG и работают с внутрисхемным JTAG-эмулятором. Отлаживаемый процессор и эмулятор соединяются по интерфейсу JTAG через специальные выделенные на процессоре выводы. Такое подключение дат возможность отлаживать устройство в той конфигурации и на том процессоре, с которым оно будет работать. Это снимает как вопросы быстродействия эмулятора, так и вопросы изменения электрических параметров при подключении эмулятора.

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

Внутрисхемный JTAG-эмулятор SDSP- На Российском рынке хорошо зарекомендовал себя выпускаемый Воронежским инженерным центром компанией SCAN - фирмой SET - внутрисхемный эмулятор SDSP-510, являющийся полным функциональным аналогом оригинального устройства TI - эмулятора XDS-510, но при этом имеет в несколько раз меньшую стоимость.

Ещ одним преимуществом JTAG-эмулятора является возможность его подключения к уже готовому устройству, из которого выведен JTAG-разъм. Для мобильных применений, для подключению к носимым компьютерам, а также для работы с компьютерами, которые не имеют шины ISA, выпускается внутрисхемный JTAG-эмулятор для подключения к параллельному порту SDSP-PP.

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

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

присоединения кабеля вместо планарной микросхемы;

изменения нагрузочной способности;

компоновки устройства.

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

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

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

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

Рассмотрим подробнее тестовый интерфейс JTAG и принципы работы внутрисхемных JTAG-эмуляторов.

5.4. Тестовый интерфейс JTAG Интерфейс JTAG назван по сокращнному названию образованной в 1985 году группы ведущих производителей электронных компонентов (Joint Test Action Group), которая была создана для решения проблем тестирования сложных электронных устройств. Выработанная группой архитектура последовательного тестового интерфейса была принята как промышленный стандарт IEEE Std.

1149.1-1990 (IEEE Standard Test Access Port and Boundary-Scan Architecture).

Данная архитектура называется ещ по наименованию стандарта - BoundaryScan Architecture - архитектура граничного сканирования.

Интеграция архитектуры BSC в устройство Встраивание архитектуры BST в устройство предполагает обеспечение доступа к выводам микросхемы, точнее, к специальным блокам ввода/вывода - BSC.

При этом предусматривается возможность как контроля состояния вывода при помощи BSC, так и управление состоянием вывода.

BSC располагаются между блоками ввода/вывода и внутренней логикой микросхемы и последовательно включаются в последовательную тестовую цепочку - отсюда и называние - архитектура последовательного сканирования. Точнее сказать, что BSC встраиваются в блоки ввода/вывода. В обычном состоянии BSC не оказывают никакого влияния на работу устройства, и сигналы свободно проходят со входа NDI и внутренней логики устройства на выход NDO. В режиме тестирования последовательно включенные BSC позволяют задавать на своих выходах тестовые воздействия при помощи подаваемых на вход TDI сигналов и снимать со входов BSC отклик, выводимый по линии TDO.

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

Каждое совместимое со стандартом IEEE Std. 1149.1 устройство имеет 4 дополнительных вывода: вход управления TMS, тактовый вход TCK, последовательный вход данных TDI и последовательный выход данных TDO.

Внутри устройства предусматривается специальный контроллер, состоящий из блока управления, называемого портом тестового доступа TAP (Test Access Port) и целого набора сдвиговых регистров: регистра команд, тестового регистра, регистра пропуска и возможных пользовательских регистров.

ТАР управляет переключением потока данных между регистрами. Его состояние определяется последовательностью взаимных состояний тактового сигнала TCK и сигнала управления TMS. В зависимости от состояния TAP, в состав JTAG-пути всегда включается один из регистров.

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

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

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

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

При этом любое устройство неявно адресуется своим положением в цепочке.

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

Производители микросхем предоставляют информацию о реализации JTAGконтроллера и соответствии тестового регистра внешним выводам устройства в специальных файлах в стандартизованных форматах, например BSDL. Подробное описание форматов можно найти на http://www.ti.com/sc/docs/jtag/format.htm.

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

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

5.5. JTAG как отладочный интерфейс в ЦСП Все выпускаемые на данный момент ЦСП Texas Instruments имеют тестовый интерфейс JTAG, который, как и полагается по стандарту, охватывает все блоки ввода/вывода внешних выводов процессора и может использоваться для тестирования межсоединений устройства. Файлы BSDL описания этого JTAGинтерфейса свободно доступны с ftp-сервера Texas Instruments. Кроме этого, сигнальные процессоры имеют ещ и дополнительные JTAG-пути и регистры, ведущие в ядро ЦСП и к его периферийным модулям. Эти пути используются отладочными средствами Texas Instruments для выполнения функций внутрисхемной эмуляции. То есть в ЦСП TI интерфейс JTAG используется как для тестирования межсоединений на плате, так и для доступа к внутренним ресурсам процессора. ЦСП может включаться в JTAG-путь совместно с другими установленными на плате устройствами, которые при работе внутрисхемного эмулятора просто ставятся в режим BYPASS. Интеграция средств JTAG в ЦСП Texas Instruments:

ЦСП Texas Instruments имеют ряд дополнительных выводов: вход сброса JTAG-интерфейса - TRST и два входа эмуляции - EMU0 и EMU1. Все линии выводятся на стандартный 14-контактный разъм. Интерфейс JTAG допускает последовательное соединение нескольких устройств, в данном случае, нескольких ЦСП, а также других JTAG-устройств. Однако при этом следует учитывать, что средства работы с JTAG-архитектурой, предназначенные для тестирования, как правило, работают на малой скорости, а средства внутрисхемной эмуляции для ЦСП Texas Instruments используют практически максимальную для стандарта частоту обмена - около 10 МГц. Подключение внутрисхемного JTAG- эмулятора к отлаживаемому устройству:

К порту JTAG подключается специальное устройство, называемое внутрисхемным JTAG-эмулятором. С другой стороны JTAG-эмулятор подключается к компьютеру. В настоящее время существуют JTAG-эмуляторы для подключения к шине ISA и для подключения к параллельному порту компьютера. Основное назначение внутрисхемного JTAG-эмулятора - обеспечить интерфейс между JTAG-портом ЦСП и компьютером. Совместно с JTAG-контроллером, внутрисхемный эмулятор обеспечивает канал связи между расположенными в ЦСП отладочными узлами и запущенной на PC отладочной средой. Обеспечение средствами JTAG канала между ЦСП и отладчиком Подключенное к JTAG-порту отладочное средство может не только контролировать и управлять ядром ЦСП, но для него доступны также все доступные для ядра периферийные блоки и банки памяти, причм независимо от того, размещены они на кристалле или вне его. Например, при доступе к внешнему ОЗУ средствами внутрисхемной эмуляции выдатся команда на блок управления внешней шиной, и он генерирует цикл обращения к внешнему ОЗУ. Отметим, что доступ к периферийным устройствам при обращении к ним из отладчика производится теми же средствами, что и при доступе к ним исполняемой на ЦСП программы. Операция "прозрачна" для состояния ядра ЦСП и для программы, а с точки зрения периферийного устройства по алгоритму обмена и его временным параметрам, полностью аналогична обращению при выполнении программы. Это обращение выполняется одним и тем же блоком, только команды на него поступают от встроенных средств тестирования через тестовый JTAG-интерфейс. Такой подход позволяет средствам отладки работать не только со стандартными узлами ЦСП, но также и с разработанными пользователем и подключенными к внешним шинам чипа периферийными устройствами.

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

Итак, мы имеем процессор и подключенный к нему внутрисхемный эмулятор.

Перейдм к рассмотрению интегрированной отладочной среды Code Composer Studio, которая работает с этими аппаратными средствами.

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

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

Чем хороша и приятна отладка программ для PC? Всегда под рукой широкий стандартный набор устройств ввода/вывода, хранения и визуализации информации: жсткий диск, клавиатура и монитор. Устройства на базе ЦСП такого набора по своей функциональности лишены.

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

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

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

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

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

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

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

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

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

Учитывать все эти нюансы и максимально использовать функциональные возможности устройств позволяет принятая в CCS архитектура подключения отлаживаемой подсистемы. Модульность построения CCS проявляется уже на этом начальном этапе. Основной блок - сервер отладки (target server). Это модуль, который отвечает за обмен со средствами внутрисхемной эмуляции. С одной стороны, к нему подсоединяются все внутренние модули CCS и дополнительные модули пользователя (PlugIn), а с другой - совокупность отлаживаемых систем. Подключение аппаратной части отлаживаемой системы к CSS Для каждого типа внутрисхемного эмулятора поставляется свой драйвер - это программный модуль, имеющий, с одной стороны, стандартный интерфейс для взаимодействия с отладочным сервером, а с другой - интерфейс для подключения соответствующего JTAG-эмулятора. Именно связка "внутрисхемный эмулятор + драйвер" и образует канал между ЦСП и средствами отладки. Соответственно, эта связка в большой степени и определяет параметры, скорость обмена и функциональные возможности средств внутрисхемной эмуляции.

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

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

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

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

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

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

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

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

Диагностика аппаратной части.

Начальная установка и конфигурирование.

Автоматизация часто выполняемых последовательностей команд.

Добавление пунктов в меню.

Функции работы с отлаживаемым ЦСП: изменение содержимого памяти и регистров, загрузка программы, добавление и удаление точек останова, Возможности работы с создаваемыми в рамках интерфейса CCS окнами ввода/вывода.

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

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

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

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

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

5.11. Ядро реального времени DSP/BIOS Перейдм к рассмотрению элементов технологии, которые относятся к программному обеспечению самих сигнальных процессоров - ядру реального времени DSP/BIOS версии II, которое в дальнейшем будем называть просто DSP/BIOS.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Ещ одно преимущество переносимости - обратный процесс оптимизации.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Исполнение программных прерываний может быть приостановлено программным прерыванием с большим приоритетом или аппаратным прерыванием.

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

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

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

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

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

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

Эти функции выполняются модулем PRD. В нм имеются системные часы - 32разрядный счтчик, изменяющийся каждый раз при вызове функции PRD_tick().

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

5.17. Модуль 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) - средства контроля трассировки и сбора статистики в программе.

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

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

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

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

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

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

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

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

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

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

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

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

5.21. Распределение памяти В ядре реального времени DSP/BIOS реализована единая сквозная система динамического и статического распределения памяти. Что же дат такой подход по сравнению со ставшим уже традиционным распределением памяти командным файлом?

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

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

Ещ одним радикальным нововведением DSP/BIOS II является система динамического распределения памяти, которая практически является элементом полноценной операционной системы реального времени. Наличие такой системы позволяет существенно улучшить "КПД" использования памяти под временные буферы, особенно в системах со сложной обработкой и большим объмом ОЗУ.

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

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

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

Как и в других случаях, потоки в DSP/BIOS делятся на два класса: базовые менее функциональные, но требующие минимальных дополнительных затрат, так называемые каналы (pipe), и более универсальные - потоки (stream), имеющие большую функциональность, но и требующие большего объма кода для обработки. Оба механизма используют механизм передачи через обмен указателями буферов, что позволяет передавать потоки без какого-либо копирования данных. С учтом того, что заполнение буферов производится устройством через каналы ПДП, можно сказать, что в передаче данных модели DSP/BIOS сведены к минимуму не только операции копирования, но и все операции, которые нагружают вычислительное ядро ЦСП.

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

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

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

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

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

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

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

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

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

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

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

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

При написании драйвера используется ряд интерфейсов DSP/BIOS (API).

Для стандартизации функций, отрабатываемых драйвером, предусмотрен специальный, так называемый интерфейс ввода/вывода низкого уровня (Low-level I/O - LIO). В состав LIO входят функции управления, функции работы с очередью ввода/вывода и функции сигнализации. Список функций приведн в таблице. Драйвер, отрабатывающий функции LIO, называется LIO интерфейсом (LIO interface) и обеспечивает один или более канал ввода/вывода на одном или нескольких устройствах. Функции интерфейса LIO:

Название Функция Cntl Настройка Управление Специфичные для конкретного устройства операции управления и настройки GetBuf Получить Работа с очере- Считывает буфер данных PutBuf Положить Работа с очере- Помещает буфер данных IsEmpty Проверка Работа с очере- Проверяет отсутствие IsFull Проверка Работа с очере- Проверяет то, что входная Большинство функций не зависит от направления передачи данных. Это связано с тем, что устройства, которые только выдают или только принимают данные, выполняют практически те же функции, что и устройства, и выдающие и принимающие данные. Основное различие в функциях ввода/вывода заключается в аргументах, которые передаются в функции обмена буферами. В выходном канале передатся заполненный буфер данных, а во входном - пустой буфер. Поскольку операции идентичны, то большая часть управляющего кода в драйвере используется всеми каналами.

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

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

Вс, что находится "внутри" драйвера, обведено штриховой линией. Непосредственно передаваемый в данный момент буфер обычно удерживается в периферийном регистре, например, в регистре источника или примника ПДП, что на рисунке показано в области "периферийное устройство". Область "периферийное устройство" обозначает непосредственно физический модуль, а не логическое устройство. Периферийные устройства с аппаратной очередью, такие как ПДП с перезагружаемыми регистрами, могут "удерживать" в себе несколько буферов для обеспечения непрерывной последовательной передачи. Эта очередь называется "входной" (to device) очередью.

Третье положение буфера - это "выходная" (from device) очередь. Как правило, выходная очередь содержит только один элемент - буфер, который только что был передан. Буфер бертся из входной очереди, когда устройство готово передавать очередной буфер. Затем он передатся в периферийный регистр, когда периферийное устройство готово к передаче очередного буфера. Далее буфер передатся в выходную очередь по завершении передачи, что обычно сопровождается генерацией прерывания. То есть буфер в выходной очереди находится начиная с того момента, когда его передача закончена, и до того момента, когда инициирована соответствующая функция, извещающая приложение о том, что буфер свободен.

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

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

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



Pages:     | 1 || 3 | 4 |
 


Похожие работы:

«ВЫСШАЯ МАТЕМАТИКА ДЛЯ ЭКОНОМИЧЕСКОГО БАКАЛАВРИАТА УЧЕБНИК И ПРАКТИКУМ 4-е издание, переработанное и дополненное Под редакцией профессора Н. Ш. Кремера Рекомендовано Министерством образования Российской Федерации в качестве учебника для студентов высших учебных заведений, обучающихся по экономическим специальностям Рекомендовано УМО по образованию в области математических методов в экономике в качестве учебника для студентов, обучающихся по специальности 061800 Математические методы в экономике...»

«Раздел 1 УМК Министерство образования и науки Российской Федерации Государственное образовательное учреждение высшего профессионального образования УЛЬЯНОВСКИЙ ГОСУДАРСТВЕННЫЙ ТЕХНИЧЕСКИЙ УНИВЕРСИТЕТ УТВЕРЖДАЮ: Декан факультета Информационных систем и технологий В. В. Шишкин 2011 г. РАБОЧАЯ ПРОГРАММА Дисциплины (модуля) Основы теории управления наименование дисциплины (модуля) 230101.62 Информатика и вычислительная техника (шифр и наименование направления) Вычислительные машины, комплексы...»

«1 2 1. Цели освоения дисциплины Целями освоения дисциплины (модуля) являются: формирование у студентов представлений о возможностях использования средств вычислительной техники, ознакомление с современными технологиями сбора, обработки, хранения и передачи информации и тенденциями их развития; обучение принципам построения информационных моделей, проведения анализа полученных результатов, применения современных информационных технологий, развитие навыков алгоритмического мышления; овладение...»

«152 Евсеенко Александр Васильевич Унтура Галина Афанасьевна доктор экономических наук, доктор экономических наук, профессор,ведущий научный Институт экономики и организации сотрудник Института экономи- промышленного производства ки и организации промышленного СО РАН. производства СО РАН. untura@ieie.nsc.ru evseenko@ieie.nsc.ru ИННОВАЦИОННАЯ ЭКОНОМИКА СИБИРИ1 Формирование инновационного сектора экономики Сибири Инновационный сектор экономики формируется в результате функционирования...»

«Фрагменты из заключительного отчета по проекту белорусского республиканского фонда фундаментальных исследований по теме Исследование задачи сворачивания белка методами комбинаторной оптимизации Руководитель проекта А.В.Тузиков Работа выполнена в объединенном институте проблем информатики академии наук Беларуси. Текст подготовил С.Феранчук при участии В.Галатенко, Т.Кирис, В.Дулько, Д.Войтеховского март 2008, г. Минск Содержание 1. Предсказание структуры белка макромицина методом предсказания...»

«2 3 1. Цели освоения дисциплины. Цели освоения социологии: формирование общекультурных компетенций на основе изучения основных теоретических, методологических и практических проблем социологической науки; развитие личностных качеств, способствующих осуществлению профессиональной деятельности в сфере Прикладная информатика на высоком уровне. 2. Место дисциплины в структуре ООП бакалавриата. Социология входит в состав вариативной части гуманитарного, социального и экономического цикла дисциплин...»

«В.Н. Афанасьев, М.М. Юзбашев АНАЛИЗ ВРЕМЕННЫХ РЯДОВ И ПРОГНОЗИРОВАНИЕ Допущено Министерством образования Российской Федерации в качестве учебника для студентов высших учебных заведений, обучающихся по направлению и специальности Статистика МОСКВА ФИНАНСЫ И СТАТИСТИКА 2001 РЕЦЕНЗЕНТЫ: И.И. Елисеева доктор экономических наук, профессор Санкт-Петербургского университета экономики и финансов, чл.-корр. РАН; B.C. Мхитарян доктор экономических наук, профессор Московского государственного университета...»

«b{orqj 5 (87) ISSN 2226-1494 qem“ap|-nj“ap| 2013 ОБЗОРНАЯ СТАТЬЯ Оптические солитоны в средах из двухуровневых атомов Сазонов C.В. 1 ФОТОНИКА И ОПТОИНФОРМАТИКА Оптические диэлектрические наноантенны Краснок А.Е., Белов П.А., Кившарь Ю.С. 23 Управление модами системы связанных кольцевых резонаторов при помощи света Капитанова П.В., Белов П.А. 28 Анализ зонной структуры фотонного кристалла с кратными оптическими длинами слоев Денисултанов А.Х., Ходзицкий М.К. 32 для терагерцового диапазона частот...»

«Учебно – методический комплекс “Охрана труда” 1. Учебная программа, для Белорусского государственного университета по всем специальностям факультета прикладной математики и информатики. 2. Примерный тематический план. 3. Программа курса “Охрана труда” для студентов 5-ого курса ФПМИ. 4. Содержание лекционного курса “Охрана труда”. 5. Курс лекций “Охрана труда”. 6. Темы рефератов по курсу “Охрана труда”. 7. Темы рефератов(дополнение к основным темам по курсу “Охрана труда”). 8. Дополнительные...»

«ВЫСШЕЕ ПРОФЕССИОНАЛЬНОЕ ОБРАЗОВАНИЕ Б А К А Л А В Р И АТ ГЕОДЕЗИЯ УЧЕБНИК Под редакцией проф. Д. Ш. Михелева Рекомендовано Учебно методическим объединением по образованию в области геодезии и фотограмметрии в качестве учебника для студентов высших учебных заведений, обучающихся по укрупненному направлению подготовки Геодезия и землеустройство 11 е издание, переработанное 1 УДК 528.48(075.8) ББК 26.1я73 Г35 Р е ц е н з е н т ы: зав. кафедрой Геодезия и геоинформатика Государственного...»

«Н.Н. Непейвода Инфософия Введение в системный и логический анализ Курс лекций УДК ББК Непейвода Н.Н. Введение в системный и логический анализ. Курс лекций. Приложения математики являются скорее искусством, чем наукой, хотя и базируются на абстрактнейших достижениях точных наук. Данная публикация является первым опытом пособия по курсу, призванному дать интегральный взгляд на полуформальные и неформальные методы, выявить соблазны и трудности, возникающие при приложении математики, и показать...»

«Департамент образования города Москвы Концепция информатизации образовательного процесса в системе Департамента образования города Москвы Утверждена решением Коллегии Департамента образования города Москвы от 16.10.2008 г. № 6/2 Москва 2008 2 Содержание Введение Документы, на которые опирается и ссылается Концепция Состояние проблемы Важнейшие принципы, положенные в основу Концепции Цели, задачи и направления реализации Концепции Ориентиры Концепции Современные образовательные приоритеты,...»

«O‘z DSt 2310:2011 ГОСУДАРСТВЕННЫЙ СТАНДАРТ УЗБЕКИСТАНА Система стандартов по информации, библиотечному и издательскому делу ЭЛЕКТРОННЫЕ ИЗДАНИЯ Основные виды и выходные сведения Издание официальное Узбекское агентство стандартизации, метрологии и сертификации Ташкент O‘z DSt 2310:2011 Предисловие 1 РАЗРАБОТАН Государственным унитарным предприятием Центр научно-технических и маркетинговых исследований - UNICON.UZ (ГУП UNICON.UZ) 2 ВНЕСЕН Техническом комитетом по стандартизации в сфере связи и...»

«В учебнике рассмотрены основные категории аппаратных и программных средств вычислитель­ ной техники. Указаны базовые принципы построения архитектур вычислительных систем. Обес­ печено методическое обоснование процессов взаимодействия информации, данных и методов. Приведены эффективные приемы работы с распространенными программными продуктами. Рас­ смотрены основные средства, приемы и методы программирования. Книга предназначена для студентов технических вузов, изучающих информационные техноло­...»

«Международный консорциум Электронный университет Московский государственный университет экономики, статистики и информатики Евразийский открытый институт Н.Н. Снетков Имитационное моделирование экономических процессов Учебно-практическое пособие Москва 2008 1 УДК 519.86 ББК 65.050 С 534 Снетков Н.Н. Имитационное моделирование экономических процессов: Учебно-практическое пособие. – М.: Изд. центр ЕАОИ, 2008. – 228 с. ISBN 978-5-374-00079-5 © Снетков Н.Н., 2008 © Евразийский открытый институт,...»

«Harold Abelson Gerald Jay Sussman and Julie Sussman with Structure and Interpretation of Computer Programs The MIT Press Cambridge, Massatchusetts London, England The McGraw-Hill Companies, Inc. New York St.Louis San Francisco Montreal Toronto Харольд Абельсон Джеральд Джей Сассман Джули Сассман при участии Структура и интерпретация компьютерных программ Добросвет, 2006 3 Эта книга посвящается, с уважением и любовью, духу, который живет внутри компьютера. “Мне кажется, чрезвычайно важно, чтобы...»

«Федеральное государственное бюджетное учреждение науки Санкт-Петербургский институт информатики и автоматизации Российской академии наук Санкт-Петербургский государственный университет Шестой междисциплинарный семинар Анализ разговорной русской речи 3 АР - 2012 27 – 28 августа 2012 года, Санкт-Петербург, СПИИРАН Санкт-Петербург 2012 ББК 32.965+81.1 А64 Анализ разговорной русской речи (АР3-2012): Труды шестого междисциплинарного семинара – СПб.: Филологический факультет СПбГУ, 2012. – 96 с. ISBN...»

«М 2 1. Цели освоения дисциплины Цели освоения дисциплины Программирование учетно-аналитических задач: формирование у магистров мировоззрения, позволяющего профессионально ориентироваться в быстро меняющейся информационной сфере; ознакомить студентов с приемами программирования в среде современных автоматизированных систем учета и обработки финансово-экономической информации; приобретение умения использовать современные компьютерные технологии для получения, обработки и передачи информации в...»

«Доклад на тему: Компьютерные игры и их влияние на развитие информатики Выполнил Лошкарев И.В. Преподаватель Брагилевский В.Н. Игры всегда присутствовали в жизни человека и так же, как человек, постепенно эволюционировали в те формы, которые позволяли лучше приспосабливаться к потребностям среды обитания. Сегодняшние игры вышли на уровень реалистического компьютерного моделирования, но разве изменились их природа и предназначение?! Первые играющие машины появились в 18 веке. Одним из самых...»

«Государственное управление. Электронный вестник Выпуск № 42. Февраль 2014 г. Гнеденко Е.Д., Кусов И.С., Самсонов Т.Е. Земельное налогообложение и приватизация: двадцать лет реформ на примере Московской области* Гнеденко Екатерина Дмитриевна — кандидат экономических наук, PhD in Agricultural Economics, преподаватель экономического факультета Университета Тафтс, США. E-mail: еkaterina.gnedenko@tufts.edu Кусов Иван Сергеевич — ассистент кафедры экономики инновационного развития факультета...»














 
© 2014 www.kniga.seluk.ru - «Бесплатная электронная библиотека - Книги, пособия, учебники, издания, публикации»

Материалы этого сайта размещены для ознакомления, все права принадлежат их авторам.
Если Вы не согласны с тем, что Ваш материал размещён на этом сайте, пожалуйста, напишите нам, мы в течении 1-2 рабочих дней удалим его.