Вход |  Регистрация
 
 
Время электроники Суббота, 24 августа
 
 


Это интересно!

Новости


Обзоры, аналитика


Интервью, презентации

Ранее

CompactPCI Serial вытесняет VPX в высокоскоростных последовательных соединениях

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

Увеличение возможностей ОСРВ с помощью программных модулей

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

Мобильные МЭМС-датчики с девятью и более степенями свободы

В статье рассмотрены последние достижения мобильных технологий МЭМС — детектирование движения и других параметров со многими степенями свободы, слияние сенсорных данных. Начавшийся переход от автономных трёхосевых сенсорных компонентов к комплексной аппаратно-программной реализации высокоинтегрированных мобильных датчиков с девятью (и более) степенями свободы со слиянием данных подразумевает, что аналогичные возможности имеются при проектировании встраиваемых систем любого масштаба.

Реклама

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

Реклама наших партнеров

 

9 декабря

Разработка устройств на базе TI OMAP-L138 и Microsoft Embedded Windows CE 6.0 R2

Многоядерные процессоры завоёвывают рынок благодаря конкурентной цене и наличию поддержки у множества операционных систем. В результате появляются новые мобильные устройства с прежде недоступными возможностями. В статье дается обзор системы на кристалле OMAP-L138 фирмы Texas Instruments. Рассматриваются вопросы портирования операционной системы Windows CE 6.0 на данную СнК, описаны BSP, подсистемы PRU и DSP, а также различные способы кодирования и декодирования медиаконтента. В следующих выпусках журнала будут представлены результаты тестирования и применения более производительной СнК данного семейства –TMS320C6A8168.



Применение Embedded Windows CE 6.0 для СнК

В последние годы мы наблюдаем активное внедрение встраиваемых систем в различные сферы жизни, что увеличивает потребность в аппаратных ресурсах процессоров. Системы на кристалле (СнК) стали настоящей находкой в современных встраиваемых решениях, поскольку заменяют множество периферийных плат и интегральных схем одним кристаллом. В большинстве случаев это выгодно как финансово, так и в плане занимаемой площади и потребления. Производительность процессоров неуклонно растёт, на кристалле применяется всё больше периферийных устройств, что влечёт применение операционных систем для оптимального использования ресурсов процессора. Одни из таких операционных систем для СнК — семейство Microsoft Windows Embedded CE и Microsoft Windows Embedded Compact.
Microsoft Windows Embedded CE/Compact — многокомпонентная операционная система реального времени (ОСРВ), которая поддерживает такие архитектуры как ARM, MIPS, SH4 и х86. Разработчик, имея пакет аппаратной поддержки для конкретной платформы, способен быстро собрать образ операционной системы, выбрав необходимые компоненты. Ключевой особенностью данного семейства ОС является наличие богатого инструментария для отладки и профилирования кода ядра, пользовательских приложений, системы автоматизированных тестов драйверов (CETK) и слоя OAL (OEM Abstraction Layer), а также множества полезных утилит для управления устройством и его настройкой. Кроме того, необходимо учесть тот факт, что существует возможность переноса кода из приложений, написанных под настольные версии ОС Microsoft Windows, что существенно сокращает время и затраты на разработку конечного устройства.

Общий анализ СнК TI OMAP-L138

TI OMAP-L138 — один из ярких представителей СнК среднего ценового сегмента, в котором сочетаются богатый набор периферии, одно из высокопроизводительных ядер TI DSP C674 с аппаратной поддержкой математических операций с плавающей запятой, экосистема PRUSS — два 32-битных ядра, которые позволяют разгрузить, к примеру, ARM-ядро, выполняя рутинные операции по предварительной обработке потока данных, или превратить одно из ядер PRU в CAN-периферию. Блок-схема данной СнК представлена на рисунке 1.

 

Рис. 1. Общая схема СнК OMAP-L138


Отличительной особенностью этого СнК является многоуровневая центральная шина с интегрированным контроллером EDMA (контроллер прямого доступа к памяти). Во-первых, данная шина имеет внутренние связи с шириной до 64 бита, которые связывают периферию и память, минуя процессор и не занимая остальные связи шины, что позволяет успешно решить проблему арбитража. Во-вторых, к данной шине подключен контроллер прямого доступа к памяти с расширенными возможностями (EDMA), который, в свою очередь, умеет не только передавать данные, не занимая процессоры, но и аппаратно выполнять операции вплоть до сортировки массива. Приятным дополнением к обширной периферии можно назвать видеопорт и SATA-интерфейс с поддержкой скорости передачи до 3 Гбит/с. Это позволяет реализовать на СнК систему захвата, обработки и хранения медиаконтента. Кроме того, в этой СнК присутствует звуковой интерфейс McASP (мультиканальный аудиопорт), который принимает и отправляет данные устройствам по 16 независимым каналам, что позволяет реализовать на базе СнК такие устройства как DVD-проигрыватель, аудиоинтерфейс, аудиопроцессор и многое другое. На наш взгляд, данная СнК достойна внимания со стороны разработчиков и применима для реализации большого количества задач.
На этой СнК реализовано полнофункциональное ядро ARM926EJ-S со всеми необходимыми внутренними модулями для запуска производительной операционной системы. Одной из таких систем можно назвать ОСРВ Microsoft Windows Embedded CE 6.0.

Применение Embedded Windows CE 6.0 для работы с OMAP-L138

При разработке встраиваемых систем на базе ОС одним из самых трудоёмких процессов является разработка BSP. Стабильная работа и качество конечного продукта, в первую очередь, определяется качеством BSP, что требует от разработчика глубоких знаний не только архитектуры применяемой СнК, но и знания и понимания работы самой операционной системы. Для работы ОС необходимо реализовать четыре базовых уровня:
– загрузчик;
– уровень абстракции ядра OAL;
– драйверы;
– файлы конфигурации.
На рисунке 2 представлена структура BSP, в которую и входят следующие уровни.

 

Рис. 2. Структура BSP


Загрузчик выполняет первоначальную инициализацию необходимых аппаратных ресурсов для загрузки образа операционной системы и переходит на стартовую точку её выполнения. В СнК реализована политика мультизагрузки образов в различные ядра кристалла из разных источников (UART, NAND, NOR, I2C, SPI, HPI), что позволяет запустить загрузчик ОС различными методами. На сегодняшний день существует множество способов запуска различных СнК из NAND/NOR-памяти. Например, используя внутреннее ОЗУ для загрузки небольшого кода, который должен в дальнейшем инициализировать PLL- и DDR-контроллеры, чтобы скопировать основной код загрузчика и операционной системы во внешнее ОЗУ. Другой вариант — запуск кода напрямую из NOR-памяти, который копирует код ОС в память, предварительно её инициализировав.
В данной СнК разработчики использовали иной метод загрузки приложений. Они реализовали возможность начальной инициализации частоты процессоров, настройку памяти и других блоков через специализированный контейнер (см. рис. 3), называемый AIS-файлом (Application Image Script). В данный контейнер можно добавить несколько образов для различных ядер, предварительно указав область загрузки кода. Тем самым уже отпадает необходимость разрабатывать код запуска для инициализации PLL и DDR в загрузчике операционной системы.

 

Рис. 3. AIS-контейнер


Уровень абстракции ядра OAL — это код, отделяющий ядро ОС от конкретной аппаратной платформы. Данный слой содержит реализацию стартового кода системы (инициализации кэша и блока управления памятью), обработку прерываний, таймеры, управление питанием и т.д. Предоставляя определённый интерфейс ядру ОС, этот уровень реализует набор функций и обработчик управляющих кодов (IOCTL). В свою очередь, ядро системы предоставляет слою OAL функции, использование которых необходимо при реализации слоя OAL, что позволяет максимально унифицировать взаимодействие между OAL и ядром системы.
Драйверы — это код, который реализует унифицированный интерфейс, абстрагирующий аппаратную или виртуальную архитектуру, и позволяет управлять множеством периферийных устройств, таких как контроллер EDMA, I2C, SPI , ЖКИ-контроллер, видеопорт, контролер ШИМ, USB OTG, USB Host, сетевой контроллер и т.д.
Для максимально быстрой разработки устройства и запуска его в массовое производство необходимо иметь не только готовый BSP (пакета аппаратной поддержки), но и многокомпонентную операционную систему. Большую роль также играет обширный функционал и базовые компоненты, предоставляемые ОС для реализации множества устройств. Также немаловажным является и наличие удобных средств для разработки и отладки пользовательских приложений, графических интерфейсов, сервисов, драйверов и дополнительного функционала. Данным требованиям соответствуют программные продукты компании Microsoft, а именно: ОСРВ Embedded Windows CE 6.0, средства разработки Platform Builder, Visual Studio и Expression Blend.
Компания MPC Data предоставляет базовый BSP для данной СнК. В него входят практически все драйверы периферийных блоков для данного кристалла, уровень абстракции ядра (OAL) и стандартный загрузчик EBOOT.
OAL уровень данного BSP поддерживает:
– параметры загрузки (передаются от загрузчика);
– включение кэша ARM-ядра (кэш инструкций и данных, буферы записи для режима Copy-Back);
– контроллер прерываний (полнофункциональная поддержка с прерываниями от внешних входов);
– выделенный таймер для ОС (с квантами по 1 мс) — используется 32-битный таймер 0;
– программную эмуляцию часов реального времени;
– блок управления памятью (MMU) для формирования таблицы трансляции физических адресов в виртуальные;
– управление системой ввода/вывода;
– профайлер ядра (использует также таймер 0);
– вывод отладочных сообщений через UART2-порт;
– KITL-уровень через сетевую периферию EMAC (с поддержкой работы через прерывания или методом непрерывного опроса) для отладки ядра;
– VMINI-мост для одновременной работы отладчика ядра и сетевого адаптера в ОС;
– SDK-функции для доступа к контроллеру управления периферии, PLL-контроллеру и контроллеру портов ввода/вывода общего назначения (GPIO);
– модуль часов реального времени (RTC);
– сторожевой таймер;
– систему управления питанием с поддержкой функции бездействия OEMIdle().
Кроме того, в BSP присутствуют тесты основных модулей периферии, реализована поддержка тестирования модулей файловой системы, портов ввода/вывода, шин I2C/SPI, через автоматизированные тесты CETK с поддержкой механизма журналирования результатов (KATO). Наличие готовой поддержки KITL и VMINI позволяет отлаживать уже на собранном образе новые драйверы и сервисы с максимальным удобством и скоростью, что позволяет существенно сократить время разработки.

 

Рис. 4. Пример последовательности загрузки драйверов в Windows CE

Рис. 5. Демо-образ Windows CE 6.0 R2 от компании AXONIM Devices с использованием модифицированного BSP на базе отладочного набора OMAP-L138 eXperimenter Kit


ОСРВ Microsoft Windows Embed­ded CE 6.0 обладает ещё одной особенностью — возможностью реализовать сценарии с зависимостью порядка загрузки при автоматической загрузке драйверов во время старта системы. Порядок загрузки прописывается в системном ре­ест­ре, что позволяет загружать драйверы устройств последовательно и строго по взаимосвязям.
Кроме того, компания Texas Instruments предоставляет механизм для работы с DSP-ядром (DSPLink). В BSP для данной СнК реализована возможность подключения описанного выше механизма. Она заключается в выделении зарезервированных секций в ОЗУ, которые помечаются как зарезервированные для операционной системы. Это позволяет разместить в данной области код и данные для DSP-ядра. Одна важная часть данной СнК осталась без внимания разработчиков BSP — это подсистема PRU. Для нее ничего не предусмотрено в пакете аппаратной поддержки.
На сегодняшний день, когда нагрузка на операционную систему увеличивается, многоядерные системы имеют выгодное преимущество, связанное с многогранностью задач на базе ОС. Применяя многоядерные СнК, можно разгрузить основное ядро, которое используется для ОС, переложив сложные вычисления на остальные ядра. Тем самым можно достичь высоких показателей в системах жесткого реального времени. В качестве примера можно привести реализацию системы захвата и сохранения видеоданных в формате 720p с частотой 30 кадров в секунду: в этом случае Windows Embedded CE 6.0 занимается сохранением данных на жёсткий диск, используя SATA-интерфейс. Возможно, дополнительно понадобится передавать данные по сети. Для снижения размера сохраняемых и передаваемых данных их сжимают, используя специализированные видеокодеки (Motion JPEG, H.264, MPEG4 и др.). Если всю работу положить на одно ядро ARM9, то даже на частоте 450 МГц у процессора мало шансов справиться с нагрузкой. Гораздо выгоднее использовать для сжатия видео DSP-ядро. Кодеки для этого предоставляет компания-производитель СнК — Texas Instruments. В таком случае разработчику лишь необходимо написать на базе ОС Windows Embedded CE 6.0 приложение (или сервис), который обслуживает систему сохранения и передачи уже сжатого потока данных, т.к. остальное можно реализовать на других ядрах данной СнК.
В качестве ещё одного показательного примера можно привести реализацию программируемого логического контроллера (PLC). Это устройство требует жёстких временных рамок для обработки внешних событий при управлении, например, станком с ЧПУ. Применение интерфейсов EtherCAT, ProfiNet или ModBus требует от ОС строго детерминированных во времени обработки запросов. Учитывая это, можно распределить нагрузку между оставшимися ядрами данной СнК.

Экосистема PRUSS и драйвер PRU-модуля

Интересной особенностью данного семейства СнК является наличие в нём отдельной подсистемы, основанной на двух 32-битных ядрах с собственной памятью команд и данных. Применение данной подсистемы может быть разнообразно, начиная от реализации дополнительных интерфейсов и обслуживания интерфейсов с целью организации определённых протоколов до разработки вспомогательного центра для ядра DSP или ARM.
На рисунке 6 представлена общая структура подсистемы PRU (программируемый модуль реального времени). Данная подсистема содержит два независимых 32-битных ядра с собственным набором команд. Данные ядра имеют упрощённую RISC-архитектуру, поддерживают 40 команд с детерминированным временем выполнения (1 такт) и расширенной возможностью оперирования битами в регистрах. Кроме того, ядра не имеют конвейера команд и векторов прерываний (все прерывания обрабатываются в режиме опроса через флаг в одном из регистров), отсутствуют команды аппаратного умножения и деления. Также в подсистеме PRU присутствует общий контроллер прерываний. Он позволяет унифицировать события от периферии, ARM, DSP и PRU-ядер. Данный контроллер обслуживает 32 события в двух направлениях: как от подсистемы PRU к ядрам ARM и DSP, так и к системе PRU. Это значит, что данный контроллер прерываний имеет возможность посылать событие контроллерам прерываний ARM- и DSP-ядер, что, в свою очередь, приводит к вызовам обработчиков прерываний этих ядер, если таковые имеются и разрешены в соответствующих регистрах. С помощью контроллера прерываний модуля PRU можно реализовать простое взаимодействие не только между ядрами PRU, но и между ядрами ARM и DSP.

 

Рис. 6. Структура подсистемы PRU


На рисунке 7 представлена структура ядра PRU. Каждое ядро PRU содержит 32 регистра, исполнительный модуль, таблицу с 29 константами и 4-Кбайт ОЗУ команд. Интересной особенностью подсистемы PRU является наличие у каждого ядра независимого быстрого порта ввода вывода (GPIO), подключённого непосредственно к двум регистрам. Это даёт возможность реализовать как собственные интерфейсы связи, так и стандартные, к примеру: UART, CAN, ProfiBus с различными физическими уровнями. Приятным дополнением является наличие ОЗУ команд непосредственно у самого ядра, что и обеспечивает выполнение инструкций за 1 такт. К данным ОЗУ имеют доступ все четыре ядра СнК (ARM, DSP, PRU0 и PRU1), но каждое ядро PRU имеет возможность исполнять код только из своего ОЗУ команд, хотя надо отметить, что оба ядра PRU имеют доступ ко всей периферии через центральную шину. Наличие встроенного ОЗУ команд и данных позволяет разгрузить центральную шину СнК и реализовать взаимодействие с периферией, памятью mDDR/DDR2 и ядрами ARM/DSP с минимальной нагрузкой.

 

Рис. 7. Структура ядра PRU


Ключевыми особенностями являются возможности системы управления питанием и тактированием подсистемы PRU. Для тактирования подсистемы используется половина частоты ядра ARM. Это значит, что при работе ядра на частоте 450 МГц существует возможность запустить ядра PRU на частоте 225 МГц (4,4 нс на инструкцию). Менеджер питания данной СнК позволяет отключать подсистему PRU, когда в ней нет необходимости, тем самым снижая общее энергопотребление СнК.
Официального компилятора на языке C для подсистемы PRU нет. Также отсутствует официальная поддержка в Code Composer Studio. Хотя для удобства разработки программы и сведения всё в один проект можно настроить среду Code Composer Studio для компиляции кода модуля PRU автоматически. Для разработки исполняющего кода подсистемы применяется специализированный компилятор PASM, который использует ассемблер в качестве основного языка.
Пример кода для ядра PRU0:

.setcallreg  r28.w2
.origin  0
.entrypoint  PRU0_AUDIO_PROCESS_CODE

#include «PRU0.hp»

PRU0_AUDIO_PROCESS_CODE:
 MOV r0, 0x00000000
 MOV r1, CTPPR_1
 ST32 r0, r1 

 MOV r0, 0x00000000
 MOV r1, CTPPR_0
 ST32 r0, r1 
 
 MOV32 regEDMA_2_ICR, 0x01C02470
 MOV32 regEDMA_3_ICR, 0x01C02670

 // Initialize pointer to INTC registers
 MOV32 regOffset, 0x00000000
 // Clear SYS_EVT
 MOV32 r31, 0x00000000
 
 // Global enable of all host interrupts
 LDI regVal.w0, 0x0001
 SBCO regVal, CONST_PRUSSINTC, GER_OFFSET, 2

Компилятор PASM поддерживает несколько типов выходных файлов: бинарный, С-массив, HEX-файл и другие (включая аннотированный листинг).
Пример выходного файла в виде C-массива:

const unsigned int PRU0_Code[] =
{
 0x240000e0,
 0x24702ce1,
 0xe1002180,
 0x240000e0,
 0x247028e1,
 0xe1002180,
 0x24247095,
 0x2401c0d5,
 0x24267096,
...
};

Компилятор располагает код сразу с нулевого адреса ОЗУ команд, поэтому файл в виде C-массива можно присоединить к основной программе, например ARM-ядра, и скопировать данные из массива напрямую в ОЗУ команд нужного ядра.
В случае, когда используется иная среда, чем Code Composer Studio, компания Texas Instruments предлагает для удобства разработки кода с подсветкой синтаксиса использовать Notepad++ или TextPad, к которым уже разработаны файлы настроек с поддержкой синтаксиса кода для модуля PRU.
В BSP под Windows CE 6.0 для OMAP-L138 нет поддержки подсистемы PRU. Официально драйвер загрузчика кода существует только в Linux, и только при использовании специализированного патча. Поэтому при реализации проектов был разработан собственный монолитный драйвер модуля PRU с поддержкой аппаратных прерываний от PRU подсистемы. Драйвер является потоковым, что позволяет получить доступ к нему с помощью функций для работы с файловой системой (CreateFile/CloseHandle). Менеджер устройств регистрирует унаследованное пространство имён для драйвера PRU, с помощью которых можно получить дескриптор для дальнейшей работы с драйвером и, как следствие, с устройством.
На рисунке 8 представлены функции драйвера для взаимодействия с ОС и пользовательским приложением. Функция PRU_Init выполняет первоначальную инициализацию драйвера и транслирует физические адреса памяти, отведённые под подсистему PRU, на виртуальные для дальнейшего использования.

 

Рис. 8. Функции драйвера PRUCores.dll


В функции PRU_Deinit реализован механизм освобождения ресурсов при выгрузке драйвера. Функции PRU_PreDeinit и PRU_PreClose используются как заглушки. Остальные функции более плотно используются для обслуживания программно-аппаратной части. Так, функция PRU_Open возвращает дескриптор устройства для функции DeviceIOControl. В свою очередь, PRU_Close выполняет очистку контекста и выполняется при вызове CloseHandle с дескриптором устройства. Функции PRU_PowerUp и PRU_PowerDown используются для оповещения подсистемы PRU о переходе основной системы в состояние Suspend и о выходе из этого состояния. Функция PRU_IOControl нуждается в особом представлении. В ней сосредоточен весь функционал драйвера. При вызове данной функции реализованы следующие параметры:
– IOCTL_PRU_REQ_INT — функция возвращает номер системного прерывания, принадлежащего конкретному номеру события (3…10) контроллера прерываний ARM-ядра;
– IOCTL_PRU_RELESE_INT — функция освобождает системное прерывание, выделенное с помощью IOCTL_PRU_REQ_INT;
– IOCTL_PRU_INT_INIT — функция привязывает системное событие к конкретному дескриптору, полученному от API-функции CreateEvent, для последующего использования с помощью API-функции WaitForSingleObject в пользовательском приложении;
– IOCTL_PRU_INT_DONE — функция сигнализирует ядру, что пользовательское приложение обработало прерывание от PRU-ядра (аналог InterruptDone);
– IOCTL_PRU_LOAD_CODE — функция загрузки кода в ОЗУ команд ядра PRU (обязательно останавливая ядро) также включает питание подсистемы PRU в контроллере PSC (Power and Sleep Controller);
– IOCTL_PRU_MAKE_SINGLESTEP — функция запуска пошагового выполнения программы (для отладки);
– IOCTL_PRU_RUN — функция запуска ядра PRU для свободного выполнения программы в ОЗУ команд;
– IOCTL_PRU_STOP — функция останова ядра PRU;
– IOCTL_PRU_WAIT_FOR_HALT — функция ожидания выполнения ядром PRU команды HALT;
– IOCTL_PRU_SET_PC_STARTUP_POINT — функция установки точки запуска программы;
– IOCTL_PRU_SLEEP — функция перевода ядра PRU в спящий режим с возможностью возвращения по различным событиям;
– IOCTL_PRU_ENABLE_COUNTER — функция включения счётчика цик­лов ядра PRU;
– IOCTL_PRU_GET_PC_COUNTER — функция возвращает текущий адрес выполняемой команды;
– IOCTL_PRU_GET_CYCLE_COUNT — функция возвращает значение счётчика циклов;
– IOCTL_PRU_SET_CYCLE_COUNT — функция записывает новое значение счётчика циклов;
– IOCTL_PRU_GET_STALL_COUNT — функция возвращает количество пропущенных тактов из-за отсутствия кода;
– IOCTL_PRU_WRITE_GP — функция записи в регистры общего назначения (для отладки);
– IOCTL_PRU_READ_GP — функция чтения из регистров общего назначения (для отладки);
– IOCTL_PRU_GET_DRAM_PTR — функ­ция возвращает указатель на область ОЗУ данных ядра PRU, транслированного в область памяти пользовательского приложения.
Данный драйвер является неким связующим звеном между устройством и пользовательским приложением, упрощая процесс разработки и ускоряя выпуск конечного продукта.
Для отладки разработанных для подсистемы PRU приложений применяется несколько методов. Это отображение контрольных точек через ОЗУ данных и регистры общего назначения с помощью: прерываний ARM/DSP-ядер; быстрого порта ввода/вывода (регистр R30) и бесконечных циклов и регистра, который указывает текущий адрес выполняемой команды. Выбор способа отладки зависит от типа приложения и удобства использования того или иного метода (вплоть до комбинирования нескольких методов).

Возможности загрузки и коммуникации с помощью DSPLink

При разработке электронных устройств часто возникает задача удешевить и упростить всю систему. Для этого рассматривается множество вариантов, но вполне очевидно, что в большинстве случаев использование многоядерных систем имеет преимущество. Оно определяется теми возможностями, которые предоставляют современные многоядерные СнК: два и более независимых ядра, общая многоуровневая шина, каналы DMA, общая периферия, готовый канал связи между ядрами и многое другое.
Подсистема DSP в СнК OMAP-L138 включает в себя процессорное ядро TMS320C674x с возможностью работы на частоте до 450 МГц, кэш-памяти (инструкций и данных), ОЗУ L2 и встроенных средств отладки (Advanced Event Trigerring — AET). К примеру, такие вычислительные возможности позволяют реализовать алгоритмы обработки изображений, которые появились ещё в 1980-х гг.
С точки зрения ОС Windows CE 6.0, само ядро DSP не представляет интереса. Код ОС Windows CE 6.0 на DSP-ядре запускать нельзя, и это нецелесообразно. Гораздо полезнее использовать DSP-ядро в качестве мощного союзника ОС Windows CE 6.0 для решения сложных вычислительных задач, к примеру, декодирования или кодирования видеоданных. Следует заметить, что это ядро способно выполнять математические операции с плавающей запятой, что позволяет разработчику сократить время на портирование алгоритма, к примеру, из пакета Matlab. В то же время для DSP, который способен оперировать математическими функциями только с фиксированной точкой, приходилось портировать алгоритм сначала в код с плавающей точкой (и отлаживать его, к примеру, на ПК), а затем, учитывая множество ограничений, переносить на DSP. Таким образом, возникают две разные задачи. Первая — кодировать и декодировать потоки видео- и аудиоданных; вторая — реализовать на ядре DSP самостоятельный алгоритм. Последнюю задачу также можно разбить на две ветви. Первая — использовать ОС DSP/BIOS от производителя СнК (или, возможно, иной ОС); вторая — разработать программу, не зависящую от какой-либо ОС (код Bare Metal). Так или иначе, ОС Windows CE 6.0 позволяет реализовать оба варианта. Компания-производитель СнК позаботилась о предоставлении готового варианта канала связи между ядрами — DSPLink.
DSPLink — это библиотека для организации межпроцессорного взаимодействия (ARM<->DSP) с использованием готового API. DSPLink предполагает использование ОС DSP/BIOS на стороне DSP.
На рисунке 9 представлена структура взаимодействия подсистем ARM и DSP при помощи описанной выше библиотеки. В СнК OMAP-L138 отсутствует модуль IPC (Inter-Processor Communication), поэтому для обмена информацией между ядрами используется ОЗУ L2 DSP, общее ОЗУ (Shared RAM) либо mDDR/DDR2 ОЗУ. С помощью библиотеки DSPLink можно загрузить код в DSP-ядро и запустить его на исполнение, организовав при этом канал обмена с ядром ARM с помощью готового API. Данный API позволяет не только оперировать состоянием ядра DSP, но и организовать обмен сообщениями между ядрами (MSGQ), обмениваться потоковыми данными (CHNL), строить циклические буферы (RingIO) и др. Основная цель этих механизмов состоит в построении экосистемы для работы с кодированием и декодированием аудио- и видеоданных. Компания-производитель данной СнК предоставляет готовые кодеки (в виде бинарных библиотек) для декодирования и кодирования аудиоданных (AAC, MP3 — только декодирование, WMA), голосовых данных (G.711, G.722, G.726), видеоданных (H.264, MPEG2 — только декодирование, MPEG4) и изображений (JPEG).

 

Рис. 9. Взаимодействие подсистем ARM и DSP с использованием библиотеки DSPLink


В стандартный BSP под Windows CE 6.0 для этой СнК не входит библиотека DSPLink, хотя некоторая связь в BSP всё же имеется. Дело в том, что для работы сложных приложений на DSP необходимо использовать mDDR/DDR2 ОЗУ для хранения данных. Это ОЗУ используется ОС Windows CE 6.0 для работы приложений, сервисов, драйверов и ядра. Тогда следует разделить память на области, доступные только ядру ARM и ОС Windows CE 6.0, область, доступную только для ядра DSP, и область, доступную обоим ядрам, для библиотеки DSPLink. Разумеется, это разделение носит формальный характер, т.к. вся область mDDR/DDR2 доступна ядру ARM, но ОС Windows CE 6.0 уже не станет использовать под свои нужды область памяти, отведённую под ядро DSP и для обмена данными с помощью библиотеки DSPLink.
На рисунке 10 представлено распределение памяти mDDR ОЗУ при использовании DSPLink. ОС Windows CE 6.0 использует 24-Мбайт ОЗУ для приложений, драйверов и сервисов. Кроме того, введена дополнительная область ОЗУ размером 63 Мбайт, которая также может использоваться в ОС Windows CE 6.0. На рисунке видно, что для библиотеки DSPLink отведено 2-Мбайт ОЗУ. Если этого недостаточно, необходимо изменить конфигурацию памяти в BSP ОС Windows CE 6.0, что уменьшит дополнительную область ОЗУ (63 Мбайт для приложений). Кроме того, следует исправить конфигурационные файлы BSP, т.к. ОС Windows CE 6.0 применяет функцию OEMGetExtensionDRAM для оповещения ОС о дополнительных областях ОЗУ.

 

Рис. 10. Распределение памяти в Windows CE 6.0 при использовании библиотеки DSPLink


Отдельно стоит остановиться на процессе сборки и интегрирования библиотеки в образ Windows CE 6.0. Для сборки собственно библиотеки используются пять ингредиентов:
– Code Generation Tool C6000;
– DSP/BIOS;
– Windows CE 6.0 (включая установленный Platform Builder + Visual Studio);
– Windows CE BSP для OMAP-L138;
– ActiveState Perl.
Все эти составляющие требуются для того, чтобы упростить и по возможности абстрагировать сборку от того же Code Composer Studio. Особых сложностей сборка библиотеки DSPLink не вызывает, хотя требует времени и внимания при конфигурировании. После успешной сборки полученные файлы переносятся в BSP. Дополнительные настройки не требуются — достаточно добавить компонент из пакета исходных кодов DSPLink в рабочий проект ОС Windows CE 6.0.
Следующий вариант использования подсистемы DSP в ОС Windows CE 6.0 — без DSP/BIOS. В этом случае библиотека DSPLink не подходит, а обмен между подсистемами ARM и DSP приходится организовывать самостоятельно, как и загрузку кода в DSP и его старт. В некоторых случаях это даже удобнее, чем использование библиотеки DSPLink. Поэтому для реализации собственных проектов OAL был модифицирован в BSP OMAP-L138 для Windows CE 6.0. После этого появилось средство для полного манипулирования ядром DSP. Это позволило реализовывать алгоритмы связи, неприменимые при работе с библиотекой DSPLink. Однако данный подход требует решения другого ряда задач, связанных, к примеру, с распределением секций приложения DSP, поскольку для старта приложения DSP необходим правильный адрес точки входа. И таких моментов немало. Следует заметить, что множество разработчиков с опытом программирования с DSP серии C6000 найдут такой подход более целесообразным с точки зрения распределения временных ресурсов.
Отдельно необходимо сказать о способах отладки приложений на DSP. Если у разработчика приложения для DSP имеется возможность использовать JTAG и среду Code Composer Studio, то в этом случае всё достаточно просто.
В окне выбора ядра для отладки можно выбрать DSP-ядро и подключиться к нему отладчиком, не останавливая подсистему ARM. Это значит, что при работающей ОС Windows CE 6.0 можно параллельно отлаживать алгоритмы с помощью JTAG и среды Code Composer Studio. Если отлаживать код без JTAG и среды Code Composer Studio, задача усложняется тем, что для отладки DSP-кода придётся прибегать к различным нестандартным методам. Например, к добавлению контрольных точек в программу для отображения в определённых ячейках памяти состояния ядра DSP. Методов достаточно много, а выбор зависит от простоты реализации и от результата отладки.

Кодирование и декодирование видео (H.264, MPEG4), аудио (MP3, AAC) на DSP-ядре

При использовании кодеков, предоставляемых компанией-производителем данной СнК, необходимо использовать всю подсистему для работы с готовыми кодеками. Для ОС Windows CE 6.0 компания предлагает готовую упаковку с исходными кодами вплоть до поддержки фильтров Direct Show для Windows Media Player.
На рисунке 11 представлена последовательность вызовов при использовании упаковки DVSDK 1.00.00.05 WinCE. При использовании фильтров Direct Show необходимо применять промежуточный уровень для связи фильтра Direct Show и VISA API (Video, Image, Speech, Audio API), который в дальнейшем использует кодеки на подсистеме DSP через библиотеку Codec Engine. В качестве этого промежуточного уровня выступает динамическая библиотека TIMM.DLL. В ней реализованы примитивы для работы с видео- и аудиопотоками.

 

Рис. 11. Последовательность вызовов при использовании кодеков на подсистеме DSP для Windows Media Player


Следует отметить, что стандартная упаковка DVSDK WinCE 1.00.00.xx не содержит исходных кодов для СнК OMAP-L138. Поэтому для реализации собственных проектов были портированы исходные коды из упаковки DVSDK 4.02 под ОС Linux Embedded (где реализована поддержка фреймворка GStreamer с кодеками на DSP) и совмещены с упаковкой DVSDK WinCE 1.00.00.05. В первую очередь, она предназначена для СнК OMAP3530, хотя сохраняется возможность добавлять новые платформы. Переделка занимает время и требует внимательной настройки всех компонентов (Codec Server, Codec Engine, DSPLink, DShow Filter и самой ОС Windows CE 6.0). Однако специалистам компании AXONIM Devices удалось запустить декодирование AVI-контейнера, в котором присутствовал видеопоток с разрешением 720×576 (MPEG4) и аудиоданными MP3. При этом результирующая скорость воспроизведения составила 30 кадров в секунду при загрузке ядра ARM примерно на 30% (воспроизведение видео по сети). При модификации кода DVSDK были выявлены и устранены ошибки в библиотеках EDMA и Codec Engine, которые существенно снижали производительность всей системы.
Ещё один вариант применения кодеков на стороне подсистемы DSP с упаковкой DVSDK заключается в разработке собственного приложения. Этот вариант находит намного больше применений, чем использование компонентов Direct Show и Windows Media Player. Что касается AVI-контейнеров, то анализатор придётся писать самостоятельно или портировать из проектов с открытым кодом. Однако если говорить о кодировании того же видеопотока, полученного от видеовхода (VPIF), этот метод гораздо выгоднее в плане использования ресурсов.
На рисунке 12 показана схема вызовов при разработке собственного приложения с использованием упаковки DVSDK. При таком подходе разработка приложения сводится к подготовке библиотек DMAI, Codec Engine, DSPLink и контейнера кодеков. Основываясь на примерах, представленных в библиотеке DMAI (video_encode_io1, video_decode_io2, audio_decode_io1 и др.), можно разработать собственные приложения, в которые можно присоединить все статические компоненты для работы данных примеров. Тем самым достигается унификация интерфейса взаимодействия с подсистемой DSP и контейнером кодеков, в частности. Отдельно следует сказать про контейнер кодеков. Он содержит в себе готовые библиотеки кодеков, которые поставляются компанией-производителем СнК в бинарном виде. Однако существует возможность добавлять в контейнер собственные кодеки, доступ к которым уже готов, благодаря унифицированному интерфейсу VISA.

 

Рис. 12. Последовательность вызовов при использовании кодеков на подсистеме DSP при разработке пользовательского приложения

 

Тестирование ARM ядра с Embedded Windows CE 6.0

Тестирование образа на стандартном BSP было сделано самостоятельно компаний MPC Data и представлено в виде таблиц Excel в приложении к BSP (см. рис. 13). Тестирование проводилось на модуле LogicPD OMAP-L138 SOM-M1. На данном модуле используется память 166-МГц mDDR ёмкостью 128 Мбайт, хотя имеется возможность использовать память DDR2 ёмкостью до 512 Мбайт, что влияет на производительность. Соответственно, данные тесты носят только познавательный характер, т.к. являются относительными.

 

Рис. 13. Тест производительности Whetstone


Для проверки производительности использовался тест (www.roylongbottom.org.uk/whets.c)
На процессорах Marvell PXA270, TI OMAP-L138 и Cirrus Logic EP9315 работала ОС Windows CE 6.0 R2, дополнительные библиотеки поддержки функций с плавающей запятой не использовались.

Заключение

Обладая, казалось бы, не самым производительным ядром ARM926EJ-S с частотой до 456 МГц (в свободном доступе — до 300 МГц), оснащенная набором периферии (SATA, модуль работы с SD/MMC-картами, McASP, McBSP и др.) и дополнительными ядрами DSP, PRU, эта СнК вызывает оправданный интерес при разработке встраиваемых систем. OMAP-L138 можно применять как основное ядро не только в мобильных, но и в стационарных системах для решения широкого круга задач, связанных с воспроизведением и хранением медиаконтента. Кроме того, она хорошо интегрируется в оборудование для медицинских приложений и автоматизации процессов.
В ходе работы у нас сформировались только положительные впечатления от использования СнК OMAP-L138 компании Texas Instruments и семейства C6-Integra в целом, которые основаны не только на младших кристаллах данной серии, но и на других СнК этой компании.



Вы можете скачать эту статью в формате pdf здесь.
Оцените материал:

Автор: Артём Столяров, Денис Михаевич, AXONIM Devices, Microsoft Embedded Partner



Комментарии

0 / 0
0 / 0

Прокомментировать





 

Горячие темы

 
 




Rambler's Top100
Руководителям  |  Разработчикам  |  Производителям  |  Снабженцам
© 2007 - 2019 Издательский дом Электроника
Использование любых бесплатных материалов разрешено, при условии наличия ссылки на сайт «Время электроники».
Создание сайтаFractalla Design | Сделано на CMS DJEM ®
Контакты