Blonstein S., Katorgi M. EXpressDSP для чайников

Подождите немного. Документ загружается.

Использование преимуществ масштабируемого про-

граммного ядра

Исторически, разработчики систем DSP создавали свои собственные домо-

рощенные планировщики. Этими планировщиками часто выступали карусельные

методы распределения времени DSP или схемы аппаратных прерываний. Пробле-

мы доморощенных планировщиков - это переносимость, расширяемость и экс-

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

ушел на покой, его DSP планировщик быстро станет загадкой.

Инструменты отладки - это тоже проблема. Сколько

функций printf Вы мо-

жете поместить в реальную систему реального времени и надеяться, что она будет

работать?

Ядро DSP/BIOS переадресует эти проблемы платформе TMS320, чем дости-

гается искусное использование ограниченного объема памяти системы и малое

число циклов CPU. Позже в этой главе мы рассмотрим это более подробно.

Переносимость

Проблемой доморощенных систем является поддержка переносимости (мо-

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

проблемы. Однако переносимость может стать серьезным вопросом, если Вы не

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

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

скольких лет.

DSP/BIOS

предлагает набор хорошо документированных и устойчивых

APIs (Application Programming Interface - программный интерфейс приложения -

интерфейс, через который приложение вызывает и использует индивидуальные

программные модули BIOS) для каждого из этих модулей. Программные интер-

фейсы приложения DSP/BIOS широко реализованы в семействе DSP TMS320.

Любое приложение, разработанное на основе ядра DSP/BIOS, может быть легко

собрано и перенесено на другую платформу TMS320. Приложению все равно,

что

микросхема, на которую оно рассчитано, изменена, так как DSP/BIOS обеспечи-

вает слой аппаратной абстракции.

Масштабируемость

Масштабируемость DSP/BIOS похожа на меню в ресторане. Вы выбираете

точно то, что Вы хотите и получаете точно то, что Вы хотите и ничего больше.

Концепция операционной системы реального времени (RTOS – real time op-

erating system)

и ядра (центральной части RTOS, управляющей основными ресур-

сами и планированием потоков) разрабатывались годами. Однако ядра и операци-

онные системы реального времени часто собраны в библиотеки, которые не могут

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

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

встраивается в

результирующую программу и засоряет свободное пространство.

Это не является серьезной проблемой для микропроцессорных приложений с 32

МБ внешней памяти, но это абсолютно смертельно для DSP, в которых внутрен-

няя память так ценна.

DSP/BIOS решает эту проблему путем создания набора дискретных моду-

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

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

удаляются неиспользуемые. Вот некоторые примеры

таких модулей:

• HWI (для аппаратных прерываний)

• SWI (для программных прерываний)

• PIP (для конвейера)

• PRD (для периодических функций) и т.д.

Интегрированная среда разработки Code Composer Studio (IDE CCS)

включает в себя действительно классные графические инструменты

конфигурации. Эти средства DSP/BIOS позволяют Вам собрать и

сконфигурировать DSP/BIOS модули, как если бы Вы читали меню

ресторана. Автоматическая генерация программы после этого может

ассемблировать требуемые модули ядра и подготовить их к включе-

нию в приложение.

Создание объекта во время разработки

Память на DSP настолько ценна, что TI предпринимает несколько дополни-

тельных шагов для уменьшения объема программы ядра в устройстве. Техника

основана на том, что платформа программирования, обычно PC с запущенным

Code Composer Studio, имеет все виды памяти, которых нет у DSP. Это несиммет-

ричный сценарий. Так почему бы не использовать эту асимметрию для вашей вы-

годы?

TI делает

это используя концепцию статической конфигурации модулей.

Многие приложения DSP достаточно статичны. Под этим мы подразумеваем, что

после запуска DSP его операционные характеристики изменяются незначительно,

если вообще изменяются. Многие или все объекты ядра просто должны быть од-

нажды созданы, а затем запущены и оставлены для работы в DSP на всю жизнь

(или до тех

пор, пока кто-нибудь не отключит разъем или батарейку). Однако соз-

дание модулей занимает значительную область памяти программ и данных – ту

ценную память, которую Вы пытались сэкономить.

Альтернативный подход состоит в использовании ресурсов компьютера, на

котором ведется разработка (ПК с работающим Code Composer Studio - CCS), для

создания модуля и сохранения, предварительно созданных модулей ядра,

с после-

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

но, поскольку все делается во время разработки приложения, а не во время его

выполнения, это даже близко не требует режима реального времени.

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

вызывает модуль, который должен быть создан во время

выполне-

ния. DSP/BIOS также поддерживает этот принцип, хотя подобно

всем другим ядрам, это несколько обременительно, но дает возмож-

ность создания модулей во время выполнения программы.

Использование программных прерываний – легкий

В предыдущем р ущества использова-

ния D

ваша система отлична от простой однозадачной, одноканальной сис-

темы,

масштабе реального времени, он

долже

распр

такой ситуации - это использование модели задач

(DSP/

г е

ируемые с

ни-

ми. В

механизм планирования

азделе, мы обсудили некоторые преим

SP/BIOS с точки зрение масштабируемости, устойчивости и переносимости.

Но какая область BIOS должна, по вашему мнению, использоваться для выполне-

ния задач?

Если

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

задач. Фактически

каждому приложению требуется определенный принцип пла-

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

обеспечить работу системы в реальном времени.

Для того чтобы DSP работал в «реальном»

н иногда иметь возможность переключать CPU от одного процесса (про-

граммного потока) к другому потоку с возвращением к первоначальному потоку.

Снова представьте

нашу метафору раннего домашнего утра и проблему

еделения одной ванной между пятью обитателями вашего «роскошного»

дома. Представьте, что кто-то бреется с закрытой дверью, и в это время кому-то

еще понадобилось в туалет. Человеку, который хочет в туалет, ванна нужна

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

ну на минуту и зайти позже. Планирование задач DSP работает аналогично выше-

изложенному примеру - “бреющийся человек” и “человек, использующий туалет”

выступают в роли потока.

Обычное решение в

BIOS TSK). Однако, эти TSK модули зачастую избыточны для многих при-

ложений DSP. Они действительно голодны в смысле размеров как программ, так

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

ти, относящаяся к потоку, предназначенная для временного хранения данных).

Облегченная версия модели задач известна как программное прерывание

(DSP/BIOS SWI). Про раммны прерывания могут достичь значительной части

того, что позволяют модели задач, но с меньшими ограничениями.

Программные прерывания (SWIs) имеют приоритеты, ассоци

ы можете назначить алгоритмам и процессам различные приоритеты, чтобы

обеспечить работу в масштабе реального времени: программные прерывания вы-

сокого уровня могут “прервать” прерывания более низкого уровня. Единственное

предостережение: программное прерывание с высоким уровнем приоритета

должно полностью завершить обработку до того, как дать CPU возможность на-

чать обработку прерывания с

низким приоритетом. Этот процесс известен как

“выполнять до завершения”. Программное прерывание высокого уровня может

быть прервано прерыванием более высокого приоритета, но тогда оно должно

быть полностью обработано до возврата к программному прерыванию меньшего

уровня.

Основание для использования этого подхода заключается в том, что все

программные прерывания в системе могут совместно использовать один общий

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

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

кода TSK. Поэтому, если

это возможно, лучше создавать систему, используя про-

граммные прерывания. В четвертой главе мы соединим некоторые предваритель-

но построенные заготовочные шаблоны, один из которых интенсивно использует

концепции программных прерываний. Во второй части книги мы покажем вам,

как создать приложение, основанное на данных концепциях.

На рис. 2-1 изображен график выполнения программы в Code Composer Stu-

dio. Этот

пример показывает использование различных программных прерыва-

ний, используемых при планировке работы DSP. Вы можете видеть программные

прерывания высоких приоритетов, обрабатываемые через CPU, и по их заверше-

нию переход к программным прерываниям низких приоритетов.

Рисунок 2-1. График работы DSP/BIOS показывающий некоторый программные

прерывания в действии

На рис. 2-1 также показаны периоды времени, когда не выполняется

никакой критической операции и процессор, так или иначе, бездей-

ствует. Однако Вы можете выполнить несколько полезных опера-

ций в течение этого времени предполагаемого бездействия, о чем

мы поговорим в следующем разделе.

Анализ в реальном масштабе времени

Хорошо, пришло время проверки реальности.

Вы только что написали ваше приложение и загружаете его в целевой DSP,

но оно не работает, как было запланировано. Что Вам делать? Вы, скорее всего,

начнете с установки некоторых точек останова в программе, останавливающих

программу, и затем посмотрите на регистры и дамп памяти, чтобы решить воз-

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

мените код, перестроите программу и попытаетесь снова ее запустить.

Но что делать, если проблема не очевидна? Или, что делать, если неполадки

видны только, когда система работает на полной

скорости и таинственным обра-

зом исчезают, когда Вы пытаетесь их устранить с помощью точек останова и дру-

гих операторов отладки? Этот тип проблем появляется очень часто.

К счастью, DSP/BIOS предлагает несколько реальных преимуществ в этой

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

что нужные данные могут быть получены из системы во

время выполнения про-

граммы. Как это возможно?

Как мы упоминали в предыдущем разделе, есть периоды времени, в течение

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

для выполнения приложения. В течение этого времени процессор может переме-

щать данные от целевой платы (платы на которой расположен DSP) в компьютер

разработчика

(ПК с запущенным Code Composer Studio). Этого можно достичь

путем соединения (например, через последовательный кабель, шину PCI, USB ка-

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

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

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

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

ментальных модулей DSP/BIOS и

их преобразования в простые и понятные фор-

маты. В качестве хорошего примера обратитесь к графику на рис. 2-1. Все эти

данные собраны “бесплатно”, а не ценой работы в реальном режиме времени DSP.

Вам, как пользователю, не потребуется что-то дополнительно программи-

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

Code

Composer Studio. То же самое справедливо для графика «загрузки» CPU и окон

статистики, которые показывают, сколько раз выполнялся модуль, среднее и наи-

худшее время выполнения. Все эти возможности реального времени – настоящий

дар для отладки комплексных систем.

Самое замечательное, ничто из этого инструментального кода не должно

вносить изменений в версию, которая отлаживается, по сравнению

с версией, ко-

торая будет поставляться потребителю. Это действительно помогает по двум при-

чинам. Во-первых, у Вас есть только одна версия кода для сохранения. Во-

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

тупны те же самые возможности отладки в масштабе реального времени.

И насколько большой?

Если все эти особенности DSP/BIOS кажутся полезными, Вы, наверное,

спросите себя, сколько адресного пространства занимают модули? На этот вопрос

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

платформ, таких как TMS320C5000 и TMS320C6000. Таблица 2-1 показывает не-

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

что при минимальной конфигурации ядра, в семействе

С5000, оно может быть

достаточно малого размера, порядка одного килослова. Это действительно мало, и

при этом остается много ценной внутренней памяти для приложения. Вот собст-

венно, в чем и заключается программирование DSP.

Таблица 2-1: Размер ядра DSP/BIOS для различных конфигураций

5402 (в 16 битных словах) 6211 (в 8 битных байтах)

Конфигурация ядра

Код Данные Код Данные

3 программных прерыва-

ния, таблица векторов пре-

рываний

1040 158 5940 532

4 программных прерыва-

ния, 1 периодическая

функция, 2 конвейера, ана-

лиз в реальном времени,

обмен данными в реальном

режиме времени, часы ре-

ального времени, таблица

векторов прерываний

3178 897 14812 3132

4 задания, 2 программных

прерывания, 1 почтовый

ящик, 1 семафор, 2 кон-

вейера, анализ реального

времени, обмен данными в

реальном режиме времени,

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

таблица векторов преры-

ваний

5519 1242 24024 4393

Глава 3

Использование XDIAS – как дви-

жение по одной стороне дороги

В этой главе

• Знакомство с правилами дорожного движения DSP

• Использование переносимости кода и гибкости

• Выполнение нескольких каналов DSP с реентерабельностью

• Соблюдение договоренности об именах в DSP

• Совместное использование ценных ресурсов

• Доверие истинным критериям качества работы алгоритмов

Представьте себе мир, где никто не хочет договариваться, по какой стороне

дороги следует ездить. Теперь исключите ограничение по скоростям – пусть все

ездят так быстро, как только они могут. Обгоны в любом месте полностью разре-

шены, и при любом удобном случае разворачивайтесь на 180 градусов, особенно

около школ. Также будет замечательно, если

с вашего автомобиля течет масло на

дорогу, у Вас «лысые» покрышки, и из выхлопной трубы вырывается столб чер-

ного дыма. Наконец, эти ремни безопасности – ведь они лишь для украшения, и

на самом деле пристегиваться ими не надо.

Разве все это не звучит нелепо? Многие из этих вещей запрещены законами

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

окружающей среды. Мы все время от времени жалуемся на многие из этих правил

и указаний, но без большинства из них дороги действительно стали бы небезопас-

ными. А они и без того опасны!

То же самое верно и для DSP программ. В главе 1 мы обсуждали

, чем про-

граммирование DSP отличается от программирования микропроцессоров общего

назначения. Одно из главных отличий (представьте действительно интенсивное

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

таких как внутренняя память, блоки математических операций, специализирован-

ные периферийные устройства и т.д. Если не установлены правила для разделения

ресурсов DSP, то, скорее всего, возникнет

неразбериха.

При написании программ для DSP нарушение закона может проявиться, ко-

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

щие ценные ресурсы и перестанет «уступать дорогу» другим алгоритмам, кото-

рым тоже нужны системные ресурсы. В результате, задача получения эффективно

работающей системы с использованием данного «преступного» алгоритма стано-

вится трудной

, если вообще достижимой.

XDAIS (произносится как «дэйас», без «экс») – это в сущности правила до-

рожного движения для алгоритмов DSP, выполняемых на платформе DSP

TMS320. Среди них есть правила, которые надо обязательно соблюдать, а также

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

димости они могут быть и нарушены. В мире

DSP системный интегратор является

тем человеком, который получает реальную пользу от XDAIS, и поэтому требует

строгого соблюдения этих правил. Системные интеграторы - это люди, на кото-

рых лежит крайне сложная задача сборки единой работающей программы из от-

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

или даже третьей стороной. Если системный интегратор знает, что

все алгоритмы

написаны в соответствии с правилами и указаниями XDAIS, то это действительно

облегчает его работу. Еще более полезным является то, что есть множество алго-

ритмов, которые были официально протестированы на совместимость с XDAIS, и

после прохождения такой проверки эти алгоритмы считаются совместимыми с

eXpressDSP, и маркируются значком, показанным на рисунке 3-1.

XDAIS

состоит из четырех отдельных частей, которые мы рассмотрим в

следующих разделах.

Рисунок 3-1: Знак совместимости с eXpress DSP

Здравый смысл – мобильность и гибкость

Разве бы это не было замечательно, если бы каждый раз, как только написа-

на важная часть кода DSP в виде алгоритма, то этот код мог бы быть использован

другими людьми, работающими с данной платформой DSP? И разве не было бы

полезным, если бы без изменения даже отдельных битов кода, он мог бы быть

применен как в простой, так и в сложной системе? ваш ответ, скорее всего, будет

«Да» на оба эти вопроса. Возможность переносимости и гибкости представляется

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

обходимо следовать некоторым правилам программирования. Следование этому

типу правил обеспечивает такой уровень переносимости и гибкости, который

по

достоинству оценит системный интегратор.

Перемещаемость кода

Все алгоритмы, совместимые с eXpressDSP, должны быть полностью неза-

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

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

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

Следование этому правилу позволяет системному интегратору располагать

код

алгоритма и данные в наиболее подходящем пространстве памяти, принимая во

внимание все остальные особенности системы.

Нет прямому доступу к периферийным устройствам

Хоть и есть сильный соблазн сделать обращения к ключевым периферий-

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

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

устройство доступно. А во-вторых, алгоритм перестает быть переносимым на

другую платформу TMS320 DSP, у которого может быть такая же или похожая

периферия, но с другими регистрами, расположенными в другом месте. Для со-

вместимости с eXpress DSP алгоритм не должен осуществлять прямых обращений

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

Однако некоторым алгоритмам требуется использование кон-

троллеров прямого доступа к памяти (ПДП, Direct Memory Access

– DMA), и практически говоря, им приходится напрямую обра-

щаться к этим контроллерам. Для удовлетворения этому требова-

нию

, XDAIS обеспечивает специальный интерфейс ПДП (DMA).

Мы коснемся этого более детально немного позже в этой главе.

Реентерабельность

Одна из замечательных ос DSP заключается в том,

что он

режное использование чте-

обенностей современных

и могут выполнять одновременно несколько каналов одного и того же ал-

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

дирования голоса. Держать 10 копий одного и того же кода алгоритма было бы

очень неразумно. Более правильным было бы наличие лишь одной копии

алго-

ритма, обслуживающей несколько каналов по расписанию. Однако, обслуживание

нескольких каналов в таком случае достижимо, только если алгоритм способен к

повторным вхождениям (является реентерабельным). Повторное вхождение по-

зволяет прервать алгоритм в любом месте его выполнения, сохранить состояние

для данного канала, осуществить переключение на другой канал, выполнить код

для этого нового

канала, и позже вернуться в начальный канал, восстановить его

состояние и продолжить выполнение.

Классической ошибкой является неб

ния/записи глобальных переменных. Если алгоритм использует

глобальные переменные, то есть вероятность, что эти переменные

будут изменены при прерывании, и работа первоначального канала

будет искажена.

Статическое управление памятью

Как упомина ществовать

езным, если бы требуемые буферы па-

мяти

Вторая г ляет уровень

совме

Использование регистра

Каждый DSP некоторо вом регистров для ис-

польз

ие алгоритма в систему, которая также исполь-

зует D

лось ранее, в идеальном случае должна су

возможность выполнения любого алгоритма как в очень маленькой

программе, так и в очень сложной системе. Одной из типичных

уловок при программировании DSP является так называемое ста-

тическое распределение ресурсов.. Возможно, вам знакомо динами-

ческое управление ресурсами, как, например, распределение памяти

во время выполнения программы

с использованием функции типа

malloc( ). Функция malloc( ) определенно полезна, но она обладает

рядом серьезных ограничений в компактных системах DSP. Прежде

всего, функция malloc( ) может быть выполнена только в действи-

тельном пространстве кода. Во-вторых, malloc( ) требуется опреде-

ленное время для выполнения. И, в-третьих, время выполнения

функции malloc( ) может меняться раз от разу, что недопустимо для

систем реального времени.

Разве не было бы пол

могли быть статически созданы до фактического запуска про-

граммы на выполнение, и тогда использования malloc( ) вообще

можно было бы избежать? Есть хорошие новости: eXpressDSP под-

держивает именно такое определение статического распределения

ресурсов. Что еще замечательнее, все XDAIS алгоритмы могут

быть

выполнены или в их естественном динамическом режиме, или в

статическом. Все это возможно без каких-либо изменений даже

единой строки кода самого алгоритма. Вот это настоящая перено-

симость!

Давайте быть последовательными

руппа правил в стандарте алгоритмов XDAIS опреде

стимости для всех алгоритмов DSP TMS320. В нашей аналогии с автомоби-

лем, эта группа правил соответствует правилу движения по одной стороне дороги.

Хотя решение о выборе правой или левой стороны дороги и является произволь-

ным, соглашение, что все будут делать так в конкретной стране, действительно

помогает.

го семейства обладает множест

ования в программах. Часть из них – общего назначения, часть – для управ-

ления периферийными устройствами. В частности, DSP/BIOS (рассмотренный в

главе 2) использует конкретные биты регистров, необходимые для обеспечения

собственной правильной работы.

Теперь представьте включен

SP/BIOS, без знания того, какие

биты регистров используются. Результатом

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