План

1. Обзор применения Embedded Windows CE 6.0 для Систем-на-Кристалле (СнК)
2. Общий анализ СнК TI OMAP-L138
3. Применение Embedded Windows CE 6.0  для работы с OMAP-L138
4. PRUSS экосистема, её возможности и драйвер PRU модуля для Embedded Windows CE 6.0
5. DSP ядро: возможности загрузки и коммуникации с применением DSPLink и без
6. Кодирование и декодирование видео (H.264, MPEG4), аудио (MP3, AAC) на DSP ядре
7. Тестирование ARM ядра с Embedded Windows CE 6.0
8. Заключение

Обзор применения Embedded Windows CE 6.0 для Систем-на-Кристалле (СнК)

В последние годы мы наблюдаем активное внедрение встраиваемых систем в различные сферы жизни, что влечёт ещё большие потребности в аппаратных ресурсах процессоров. Системы-на-кристалле (СнК) стали настоящей находкой в современных встраиваемых системах, заменив множество периферийных плат и интегральных схем, одним кристаллом. В большинстве случаев это выгодно как финансово, так и в плане занимаемой площади и потребления. Производительность процессоров неуклонно растёт, применяется всё больше периферии на кристалле, что влечёт применение операционных систем для оптимального использования ресурсов процессора. Одни из таких операционных систем для СнК – семейство Microsoft Windows Embedded CE и Microsoft Windows Embedded Compact.

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

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

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

Отличительной особенностью данного СнК является многоуровневая центральная шина с интегрированным контроллером 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 (OEM Abstraction Layer)
• Драйверы
• Файлы конфигурации

На рисунке 2 представлена структура BSP, в который и входит следующие уровни:

Загрузчик выполняет первоначальную инициализацию необходимых аппаратных ресурсов для загрузки образа операционной системы и переходит на стартовую точку её выполнения. В СнК реализована политика мультизагрузки образов в различные ядра кристалла из разных источников (UART, NAND, NOR, I²C, SPI, HPI), что позволяет запустить загрузчик операционной системы различными методами. На сегодняшний день существует множество способов запуска различных СнК из NAND/NOR памяти. Например, используя внутреннюю ОЗУ для загрузки небольшого кода, который должен в дальнейшем инициализировать PLL и DDR контроллеры, чтобы скопировать основной код загрузчика и операционной системы во внешнюю ОЗУ. Другой вариант – запуск кода напрямую из NOR памяти, который копирует код операционной системы, в память, предварительно инициализировав её.

В данном СнК разработчики использовали иной метод загрузки приложений. Они реализовали возможность начальной инициализации частоты процессоров, настройку памяти и других блоков через специализированный контейнер (рисунок 3), называемый AIS-файлом (Application Image Script). В данный контейнер можно добавить несколько образов для различных ядер, предварительно указав область загрузки кода. Тем самым уже отпадает необходимость разрабатывать стартап кода для инициализации PLL и DDR в загрузчике операционной системы.

Уровень абстракции ядра OAL (OEM Abstraction Layer) – это код отделяющий ядро ОС от конкретной аппаратной платформы. Данный слой содержит реализацию стартового кода системы (инициализации кэша и MMU), обработка прерываний, таймеров, управление питанием и так далее. Предоставляя определённый интерфейс ядру ОС, реализует набор функций и обработчик управляющих кодов (IOCTL). В свою очередь ядро системы предоставляет слою OAL функции, использование которых необходимо при реализации слоя OAL, что позволяет максимально унифицировать взаимодействие между OAL и ядром системы.

Драйвера – это код, который реализует унифицированный интерфейс, абстрагирующий аппаратную или виртуальную архитектуру, и предоставляет возможность управлять множеством периферийных устройств, таких как контроллер EDMA, I²C, 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 присутствуют тесты основных модулей периферии, реализована поддержка тестирования модулей файловой системы, портов ввода/вывода, шин I²C/SPI, через автоматизированные тесты CETK с поддержкой механизма журналирования результатов (KATO).

 

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

Ещё одной особенностью обладает операционная система реального времени Microsoft Windows Embedded 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 модуля для Embedded Windows CE 6.0

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

 

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

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

Ключевыми особенностями являются возможности системы управления питанием и тактированием подсистемы PRU. Для тактирования подсистемы используется половина частоты ядра ARM, это значит, что при работе ядра на частоте 450МГц, существует возможность запустить ядра PRU на частоте 225МГц (4,4 нс на инструкцию). Менеджер питания данного СнК позволяет отключать подсистему PRU, в то время когда в ней нет необходимости, тем самым снижая общее энергопотребление СнК.

Официального компилятора на языке C для подсистемы PRU нет, ровно также отсутствует официальная поддержка в Code Composer Studio. Хотя для удобства разработки программы и сведения всё в один проект, можно настроить среду Code Composer Studio для компиляции кода модуля PRU автоматически. Для разработки исполняющего кода подсистемы используется специализированный компилятор PASM, который использует ассемблер в качестве основного языка.

Пример кода для ядра PRU0:

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

 Пример выходного файла в виде C-массива:

const unsigned int PRU0_Code[] =

{

0x240000e0,

0x24702ce1,

0xe1002180,

0x240000e0,

0x247028e1,

0xe1002180,

0×24247095,

0x2401c0d5,

0×24267096,

…

};

Компилятор располагает код сразу с нулевого адреса ОЗУ команд, поэтому файл в виде C-массива, можно прилинковать к основной программе, например, ARM ядра, и скопировать данные из массива напрямую в ОЗУ команд нужного ядра.

В случае, когда используется иная среда, чем Code Composer Studio, компания Texas Instruments предлагает, для удобства разработки кода с использованием подсветки синтаксиса, использовать Notepad++ или TextPad, к которым уже разработаны файлы настроек с поддержкой синтаксиса кода для модуля PRU (Рисунок 8).

В BSP под Windows CE 6.0 для OMAP-L138 нет поддержки подсистемы PRU. Официально драйвер загрузчика кода существует только в Linux и то, при использовании специализированного патча. Поэтому при реализации проектов был разработан собственный монолитный драйвер модуля PRU с поддержкой аппаратных прерываний от PRU подсистемы. Драйвер является потоковым, что позволяет получить доступ к нему с помощью функций для работы с файловой системой (CreateFile/CloseHandle). Менеджер устройств регистрирует унаследованное пространство имён для драйвера – PRU, с помощью которых можно получить дескриптор для дальнейшей работы с драйвером, и как следствие с устройством.

На рисунке 9 представлены реализованные функции драйвера для взаимодействия с ОС и пользовательским приложением.

Функция PRU_Init выполняет первоначальную инициализацию драйвера и транслирует физические адреса памяти, отведённые под подсистему PRU, на виртуальные, для дальнейшего использования

В функции 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) и использование бесконечных циклов и регистра показывающего текущий адрес выполняемой команды. Выбор способа отладки зависит от типа приложения и удобства использования того или иного метода (вплоть до комбинирования нескольких методов).

DSP ядро: возможности загрузки и коммуникации с применением DSPLink и без

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

Подсистема DSP в СнК OMAP-L138 включает в себя процессорное ядро TMS320C674x с возможностью работы на частоте до 450МГц, кэш-памяти (инструкций и данных), ОЗУ L2 и встроенные средства отладки (Advanced Event Trigerring – AET). К примеру, с такими вычислительными возможностями появляется возможность реализовать алгоритмы обработки изображений, которые были разработаны ещё 80х-годах прошлого столетия.

С точки зрения ОС 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.

На рисунке 10 представлена структура взаимодействия подсистем 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).

В стандартный 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.

На рисунке 11 представлено распределение памяти 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  для оповещения ОС о дополнительных областях ОЗУ которые можно использовать.

Отдельно стоит остановиться на процессе сборки и интегрирования библиотеки в образ 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, то тут всё достаточно просто.

 

 

На рисунке 12 показано окно выбора ядра для отладки. Из показанного окна можно выбрать 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.

 

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

Надо отметить, что стандартная упаковка 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), этот метод гораздо выгоднее в плане использования ресурсов.

 

На рисунке 14 показана схема вызовов при разработке собственного приложения с использованием упаковки DVSDK. При таком подходе разработка приложения сводится к подготовке библиотек DMAI, Codec Engine, DSPLink и контейнера кодеков. Основываясь на примерах, которые представлены в библиотеке DMAI (video_encode_io1, video_decode_io2, audio_decode_io1 и другие), можно разработать собственные приложения, в которые можно прилинковать все статические компоненты необходимые для работы данных примеров. Тем самым достигается унификация интерфейса взаимодействия с подсистемой DSP и контейнером кодеков в частности. Отдельно надо сказать про контейнер кодеков. Данный контейнер содержит в себе готовые библиотеки кодеков, которые поставляются компанией-производителем СнК в бинарном виде. Однако существует возможность добавлять в контейнер собственные кодеки, доступ к которым уже готов, благодаря унифицированному интерфейсу VISA.

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

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

Для проверки производительности использовался тест (http://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 в целом, основывая не только на младших чипах этой серии, но и на других СнК от компании Texas Instruments.

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

 

Автор:  Axonim Devices, Microsoft embedded partner

www.axonim.by