Tecnol´ogico de Costa Rica Escuela de Ingenier´ıa Electr´onica
Dise˜
no e implementaci´
on de un marco de trabajo para el
desarrollo de aplicaciones embebidas en el DSP del Sistema en
Chip DM8168
Informe de Proyecto de Graduaci´on para optar por el t´ıtulo de Ingeniero en Electr´onica con el grado acad´emico de Licenciatura
Jos´e Alberto L´opez Mata
Resumen
Este documento presenta el dise˜no e implementaci´on de un marco de trabajo para el desarrollo de aplicaciones embebidas en el Sistema en Chip DM8168. Este sistema perte-neciente aTexas Instruments(TI) contiene un procesador digital de se˜nales que posibilita c´omputo dedicado como el de algoritmos de procesamiento digital de im´agenes (PDI). El desarrollo e implementaci´on de aplicaciones multimedia en el procesador de se˜nales est´a bajo la mira del proyecto.
El marco de trabajo sirve como base de desarrollo para un programa de prueba que utiliza una t´ecnica de procesamiento digital de im´agenes. Este toma una imagen a la cual le aplica un operador Sobel. Este funciona como una m´ascara que opera sobre el contenido de la imagen para revelar sus bordes. El programa de prueba es ejecutado en una plataforma de desarrollo donde el Sistema en Chip se encuentra empotrado, esta plataforma ofrece los medios para desarrollar y probar aplicaciones embebidas.
Abstract
This document describes the design and implementation of a framework for embedded applications development for the DM8168 System-on-Chip. This system from Texas Ins-truments has a Digital Signal Processor for dedicated operations, such as digital image processing algorithms. The development and implementation of multimedia applications on the DSP is under the scope of the project.
The framework works as a base for the development of a test program that uses digital signal processing techniques. The application grabs an image and computes a Sobel operator over it, this operator works as a mask that computes data over the image content to expose its edges. The test program runs in a development platform where the System on Chip is embedded, this platform offers the means for the development and testing of embedded applications.
Agradecimientos
En primer lugar agradezco a mi familia, por ense˜narme el valor del esfuerzo que me per-miti´o llevar a cabo el presente proyecto. Especialmente a mis padres Alicia y Roberto, quienes me ense˜naron a siempre aspirar metas altas y por esforzarse d´ıa a d´ıa para ayu-darme a completar esta etapa de mi vida. A mis amigos por ser fuente de motivaci´on y apoyo en el transcurso de toda mi carrera.
A RidgeRun por darme el espacio para desarrollar mi proyecto, agradezco a su personal por la paciencia y ayuda t´ecnica que brindaron en el transcurso del mismo. Tambi´en, agradezco al Tecnol´ogico de Costa Rica, por darme las oportunidades para realizar mi carrera y as´ı crecer personal y profesionalmente.
Jos´e Alberto L´opez Mata Cartago, 27 de junio de 2013
ii ´Indice general
2.8.1 xdc . . . 19
2.8.2 xs . . . 19
3 Marco de trabajo para la ejecuci´on de procesos remotos 21 3.1 Integraci´on con el SDK . . . 21
4 Implementaci´on de detector de bordes 33 4.1 Personalizaci´on de la interfaz de media digital . . . 33
5 Configuraci´on del ambiente de ejecuci´on 39 5.1 Partici´on de Linux . . . 39
5.2 Carga de m´odulos . . . 39
6 Resultados y An´alisis 43 6.1 Factorizaci´on de secuencia de construcci´on . . . 43
A Mapa de memoria del SDK para el DM8168 57
´
Indice de figuras
1.1 Esquema del entorno de desarrollo del marco de trabajo . . . 2
2.1 Arquitectura del sistema en chip DM8168 [25] . . . 6
2.2 Diagrama de comunicaci´on entre un cliente y un servidor . . . 7
2.3 M´odulo de evaluaci´on DM8168 [19] . . . 8
2.4 Sistema de comunicaci´on por video que se implementa en el EVM DM8168 [10] . . . 9
2.5 Sistema de integraci´on de aplicaciones del SDK . . . 11
2.6 Ejemplo de tuberia de GStreamer . . . 11
2.7 Imagen original de una copa junto a su imagen filtrada con operador Sobel [6] . . . 13
2.8 Estructura de pools y b´uferes de CMEM . . . 15
2.9 Ciclo de vida de un algoritmo [42] . . . 16
2.10 Contenido de un paquete RTSC . . . 17
2.11 Diagrama de aplicaciones cliente - servidor en el SoC DM8168 . . . 19
3.1 Marco de trabajo junto al sistema de integraci´on de aplicaciones del SDK . 22 3.2 Configuraci´on del ambiente de desarrollo GNU/Linux . . . 23
3.3 Construcci´on de software para un ambiente multiprocesador . . . 23
3.4 Generaci´on de contenido para arquitectura DM8168 . . . 24
3.5 Diagrama de flujo simplificado de operaci´on del marco de trabajo . . . 25
3.6 Estructura de metaprograma config.bld para construir paquetes RTSC . . . 27
3.7 Estructura de metaprograma ARM.cfg para configurar aplicaci´on cliente . 27 3.8 Ejemplo de comando utilizado por la clase . . . 28
3.9 Sequencia de comandos de la clase . . . 29
3.10 Comandos para generar paquetes RTSC base con xdcTools . . . 30
3.11 Diagrama de secuencia de construcci´on . . . 31
4.1 Envoltura del operador Sobel en la funci´on process de la interfaz xDM . . . 34
4.2 Expansi´on de estructura de IUNIVERSAL del codec Sobel . . . 34
4.3 Diagrama de flujo de la operaci´on del filtro Sobel . . . 35
4.4 Diagrama de operaci´on de aplicaci´on cliente . . . 37
5.1 Configuraci´on de CMEM para alojar los b´uferes del DSP . . . 40
iv ´Indice de figuras
5.2 Configuraci´on del ambiente de ejecuci´on para la aplicaci´on del filtro de im´agenes . . . 41 6.1 Comparaci´on de sistemas de construcci´on original y factorizado . . . 44 6.2 Imagen de ejemplo con resoluci´on de 640 x 480 convertida a escala de grises
y procesada por el operador Sobel . . . 46 6.3 Juego de imagenes filtradas por operador Sobel con diferentes niveles de
´
Indice de tablas
2.1 Bloques del mapa de memoria para la arquitectura DM8168 . . . 12 6.1 Reducci´on de tiempo de construcci´on de software . . . 45 6.2 Carga de procesamiento de operador Sobel ejecutado en el procesador ARM
y en los procesadores ARM y DSP . . . 47
Lista de s´ımbolos y abreviaciones vii
Nomenclatura
SoC: Sistema en Chip
DSP: Procesador Digital de Se˜nales PDI: Procesamiento Digital de Im´agenes SDK: Kit de desarrollo de software
RTSC: Componente de Software de Tiempo Real XDAIS: Est´andar de interoperabilidad de algoritmos xDM: Interfaz de media digital
CE: Codec Engine
Kernel horizontal de operador Sobel
+1 0 −1 +2 0 −2 +1 0 −1
Kernel vertical de operador Sobel
+1 +2 +1
0 0 0
+1 +2 +1
Cap´ıtulo 1
Introducci´
on
1.1
Sistemas empotrados en el mercado de
tecno-log´ıas
El proyecto se lleva a cabo enRidgeRun – Embedded Solutions, empresa que se especializa en software empotrado y ofrece soluciones hechas a la medida para sistemas basados en GNU/Linux, esto incluye herramientas de desarrollo de software, n´ucleos, controladores, aplicaciones y servicios de ingenier´ıa [33].
La empresa participa en el mercado de productos y servicios multimedia en un ambiente muy competitivo, donde se tienen que generar soluciones utilizando tecnolog´ıas nuevas que mutan constantemente. Esto implica a su vez un reto para que los desarrolladores de software puedan aprovechar estas tecnolog´ıas e innovar soluciones. Un caso concreto es el del Sistema en Chip DaVinci Media 8168 de TI, este sistema est´a compuesto de m´ultiples unidades de procesamiento dedicado. Una de ellas es el Procesador Digital de Se˜nales (Digital Signal Processor, DSP) C6748[25], donde un desarrollador que implemen-ta software en esimplemen-ta unidad puede verse involucrado con distintos obst´aculos t´ecnicos; como t´ecnicas de programaci´on orientadas a componentes, tecnolog´ıas espec´ıficas de software del propietario, reglas de integraci´on de algoritmos [21], t´ecnicas de procesamiento digital de se˜nales, entre otros.
La empresa, en miras a fortalecer sus soluciones embebidas busca conocer m´as a fondo esta arquitectura para aprovechar sus recursos tanto de hardware como de software y competir m´as en el mercado de aplicaciones multimedia.
1.2
Implementaci´
on de soluciones en el DSP C6748
La falta de las herramientas de software que faciliten la integraci´on de aplicaciones embe-bidas en el Sistema en Chip (System-on-Chip, SoC) DM8168 es una necesidad presente.
2 1.3 Marco de trabajo para la ejecuci´on de procesos remotos
El proyecto dise˜na e implementa un marco de trabajo que permita aprovechar los recur-sos ofrecidos por la arquitectura, espec´ıficamente el DSP C6748. De esa manera se abre un camino para incursionar en t´ecnicas m´as sofisticadas para procesar datos multimedia, como lo son los algoritmos de PDI.
1.3
Marco de trabajo para la ejecuci´
on de procesos
remotos
El aporte del proyecto corresponde a dise˜nar un marco de trabajo para el Kit de Desa-rrollo de Software de RidgeRun (Software Development Kit, SDK). El marco de trabajo se encarga de agrupar y enlazar los componentes del SDK necesarios para formar un sis-tema de construcci´on que genere contenido ejecutable para el SoC DM8168. Esto con la finalidad de facilitar el proceso de construcci´on de software que pueda ejecutarse en un ambiente multiprocesador y as´ı formar una base para generar aplicaciones multimedia m´as complejas.
Para establecer una prueba base de las capacidades del marco de trabajo y del SoC se implementa una aplicaci´on de detecci´on de bordes en im´agenes. Para ello se integra un operador Sobel en la arquitectura, este procesa cada secci´on de la im´agen para calcular el gradiente de la misma y as´ı exponer sus bordes.
La Figura 1.1 muestra un esbozo del entorno en el que el marco de trabajo se desarrolla, el cual est´a integrado con el SDK y utiliza el software y dem´as recursos que lo componen. El marco de trabajo se encarga de generar aplicaciones con contenido local y remoto. La primera es donde una aplicaci´on cliente ejecutada en el procesador ARM administra un proceso remoto. La segunda es donde una aplicaci´on servidor en el DSP ejecuta tareas de c´omputo dedicado y entrega los datos procesados al cliente.
Sistema en Chip DM8168
1 Introducci´on 3
1.4
Objetivos y estructura del documento
El proyecto tiene como objetivo integrar al SDK un marco de trabajo para facilitar el desarrollo de algoritmos que se ejecuten en el DSP de la arquitectura DM8168. Para conseguirlo se necesita que el marco de trabajo permita el funcionamiento en conjunto de componentes de software necesarios para ejecutar un proceso remoto.
El marco de trabajo sirve de base para el desarrollo de un programa de prueba que aplica un filtro Sobel sobre una imagen, el cual se ejecuta en el procesador digital de se˜nales. Adem´as para cumplir lo anterior hay que definir el ambiente de ejecuci´on de la arquitectura para que la aplicaci´on se ejecute en un ambiente multiprocesador.
El documento establece el marco te´orico en el cap´ıtulo 2, as´ı permite a los lectores fami-liarizarse con los conceptos t´ecnicos necesarios para el desenvolvimiento de tem´aticas m´as espec´ıficas de los sistemas embebidos y el procesamiento digital de se˜nales.
Cap´ıtulo 2
Marco Te´
orico
2.1
Sistemas empotrados
Un sistema empotrado (o embebido) es un sistema de computaci´on que fue elaborado con la finalidad de cubrir necesidades espec´ıficas. Estos sistemas al ser fabricados con fines particulares, le permite a los ingenieros de dise˜no de hardware optimizarlos en reducci´on de tama˜no y precio de producci´on; y a su vez aumentar su fiabilidad y desempe˜no. Los sistemas empotrados pueden formar parte de sistemas de c´omputo de se˜nales digitales, anal´ogicas o mixtas; tambi´en pueden estar compuestos de sistemas de un solo procesador o multiprocesador [11, 38].
Estos dispositivos pueden emplearse en diferentes aplicaciones: en el ´area de multimedia como decodificadores de audio, en transportes como computadoras a bordo en trenes, en la industria como l´ıneas de ensamblaje, entre muchas otras. Texas Instruments fabrica y da soporte a dispositivos afines a los sistemas empotrados como por ejemplo microproce-sadores, procesadores digitales de se˜nales y SoC.
2.2
Sistema en chip DM8168
2.2.1
Arquitectura
El SoC DM8168 pertenece a la serie DaVinci de TI, cuya caracter´ıstica principal es la eficiencia del procesamiento de aplicaciones multimedia. La Figura 2.1 muestra la arqui-tectura DM8168, donde resaltan diferentes unidades que se enuncian a continuaci´on:
• Procesador ARM Cortex A8: Se encarga de control de procesos, c´omputo de prop´osito general y administraci´on de tareas.
• SGX: Unidad dedicada a procesamiento gr´afico en 3D (tercera dimensi´on).
• Procesador de se˜nales C6748: Toma la funci´on de procesador auxiliar, es capaz de
6 2.2 Sistema en chip DM8168
ejecutar eficientemente algoritmos dedicados de procesamiento digital de se˜nales.
• Subsistema Ducati: Compuesto por diferentes unidades, como el controlador de media, coprocesadores y subsistema de video.
HDVICP2: Coprocesadores dedicados para im´agenes y video en alta definici´on.
HDVPSS: Susbsistema de procesamiento de video para captura y despliegue de contenido. Controlador de Media: Comprende dos procesadores ARM Cortex M3 que administran a los m´odulos HDVICP2 y HDVPSS [44].
Figura 2.1: Arquitectura del sistema en chip DM8168 [25]
2 Marco Te´orico 7
2.2.2
Esquema de operaci´
on cliente-servidor
En sistemas multiprocesador como el DM8168, las unidades pueden tener diferentes es-quemas de operaci´on como maestro-esclavo o cliente-servidor [14]. La Figura2.2 muestra el funcionamiento del procesador ARM como un administrador que ejecuta aplicaciones cliente y el cliente invoca un proceso remoto en otra unidad. La aplicac´ıon servidor se ejecuta en el procesador esclavo, captura los datos a la entrada, los procesa y devuelve al procesador ARM.
En el SoC DM8168, se puede presentar la ejecuci´on de una tarea en el procesador ARM y parte de ella se descarga a alguna unidad auxiliar (procesadores M3, DSP, o SGX). De esta forma la carga del procesador ARM se aligera y se aprovecha el uso de unidades dedicadas.
Figura 2.2: Diagrama de comunicaci´on entre un cliente y un servidor
2.2.3
M´
odulo de evaluaci´
on DM8168
El sistema en chip DM8168 se usa en conjunto con una plataforma de desarrollo para poner en pr´actica soluciones completas. El m´odulo de evaluci´on (Evaluation Module, EVM), como muestra la Figura 2.3 ofrece conectividad y expansiones como puertos de video component y HDMI (High Definition Multimedia Interface) de entrada y salida, comunicaci´on serie y por red [35], entre otros.
Algunos ejemplos de aplicaciones que se pueden realizar con el EVM DM8168 son:
• Sistemas de transmisi´on de datos
• Sistemas de videoconferencia
• Visi´on por computadora
• Procesamiento digital de im´agenes (PDI)
• Sistemas de seguridad
8 2.3 Ambiente de desarrollo GNU/Linux
Figura 2.3: M´odulo de evaluaci´on DM8168 [19]
La Figura 2.4 muestra un diagrama de bloques para un sistema de comunicaci´on por video que puede llevarse a cabo en el EVM. La plataforma captura video con los puertos de entrada, lo procesa con el SoC DM8168 y se entrega por medio de los puertos de salida a un medio que lo utilice. Como una pantalla de entrada anal´ogica o un sistema de transmisi´on por red.
2.3
Ambiente de desarrollo GNU/Linux
GNU/Linux es un sistema operativo basado en Unix, caracterizado por ser desarrollado bajo un modelo de c´odigo abierto. Linux es un sistema central que administra y manipula recursos de hardware para que estos sean usados por programas de software, Linux en conjunto con GNU forman un sistema operativo completo basado en Unix [48].
Muchos tipos de programas se pueden ejecutar sobre GNU/Linux en una computadora de prop´osito general, esto incluye al SDK para el SoC DM8168 de RidgeRun.
2.3.1
Shell
2 Marco Te´orico 9
Figura 2.4: Sistema de comunicaci´on por video que se implementa en el EVM DM8168 [10]
frecuentado utilizar el Shell por medio de la linea de comandos, el SDK lo utiliza como un medio para accesar a diferentes recursos de programaci´on.
2.3.2
GNU Make
GNU Make es una utilidad que facilita y organiza la construcci´on de software. Los programas inform´aticos pueden volverse muy grandes, esto conlleva a que su construcci´on se vuelva m´as compleja y m´as dif´ıcil de manejar. Debido a esas razones, este programa utiliza comandos que permiten al c´odigo fuente ser construido de forma ordenada. La utilidad GNU Make se utiliza por medio de archivos especiales t´ıpicamente llama-dos Makefiles, dentro de ellos se definen comandos de construcci´on de software que son invocados por GNU Make [9].
2.4
SDK: Kit de Desarrollo de Software
10 2.4 SDK: Kit de Desarrollo de Software
compiladores y dispositivos empotrados, paquetes de software de c´odigo abierto como de software propietario (por ejemplo de TI) [32].
Por medio del SDK es posible programarle a los SoC rutinas de inicializaci´on en memoria, que al momento de encendido del dispositivo permiten la ejecuci´on de un sistema operativo GNU/Linux embebido, uso del sistema de archivos por red, comunicaci´on con PC por medio del puerto serie, entre otros. Todo esto para darle al desarrollador un soporte completo de construcci´on, implementaci´on y supervisi´on a las aplicaciones embebidas.
2.4.1
Compilaci´
on cruzada
La compilaci´on cruzada es el proceso de compilar una aplicaci´on desde una m´aquina con un tipo de arquitectura, y el producto es c´odigo ejecutable para otra m´aquina o disposi-tivo con arquitectura distinta [24]. Los procesadores ARM que pertenecen a un sistema embebido no tiene los recursos de hardware y de software suficientes para propiciar un ambiente de desarrollo completo y funcional como el del SDK, por medio de la compilaci´on cruzada es posible desarrollar software con el SDK desde una computadora de prop´osito general con arquitectura x86 o x64 hacia un sistema embebido de otra arquitectura. Existen distintas herramientas de construcci´on que permiten la compilaci´on cruzada. Pa-ra procesadores ARM, el SDK la lleva a cabo con CodeSourcery. CodeSourcery hace compilaci´on cruzada para arquitecturas ARM y distintos sistemas empotrados basados en Linux [34].
2.4.2
Sistema de integraci´
on de aplicaciones
RidgeRun adquiere software propietario o de c´odigo abierto con miras a integrarlo al SDK para llevarlo luego a un sistema empotrado. La Figura2.5esboza el sistema de integraci´on de aplicaciones del SDK. Este est´a compuesto de un sistema de configuraci´on que permite personalizar el entorno de desarrollo con las opciones requeridas para integrar aplicacio-nes. Tambi´en tiene un sistema de construcci´on que ofrece definiciones, herramientas para compilaci´on cruzada y software que unifica las secuencias de construcci´on de contenido. El SDK adem´as dispone de un sistema de clases, estas permite la integraci´on de aplica-ciones con sistemas de construcci´on espec´ıficos. Por ejemplo si una aplicaci´on tiene un sistema de construcci´on basado en autotools (un conjunto de herramientas para la cons-trucci´on autom´atica de paquetes de software [28]), el SDK ofrece una clase de autotools que se usa para integrar aplicaciones que implementen este esquema [18].
2 Marco Te´orico 11
Sistema empotrado
Sistema de integración de aplicaciones del SDK
programas de propietario o código abierto
Sistema de configuración Sistema de construcción
Sistemas de clases
Figura 2.5: Sistema de integraci´on de aplicaciones del SDK
de color y finalmente por un elemento que despliega el video convertido en un monitor de entrada anal´ogica.
Figura 2.6: Ejemplo de tuberia de GStreamer
El sistema de integraci´on de aplicaciones del SDK tambi´en ofrece una clase para generar elementos de GStreamer, dando as´ı m´as funcionalidad a las aplicaciones con las que la empresa trabaja y facilitando su uso en distintos escenarios multimedia.
2.4.3
Mapa de memoria
Un mapa de memoria describe la distribuci´on de los datos en una tabla de memoria [17]. La arquitectura DM8168 usa un mapa de memoria de tama˜no 1GB, el cual es accesado y manejado por diferentes unidades bajo un esquema de memoria compartida.
12 2.5 Aplicaciones de procesamiento digital de se˜nales
Tabla 2.1: Bloques del mapa de memoria para la arquitectura DM8168 Segmento Longitud [MB] Direcci´on base Uso
LINUX MEM 1 364 0x80000000 Partici´on del sistema Linux
CMEM 20 0x96C00000 Segmento de memoria
con-tiguo
DSP ALG HEAP 20 0x98000000 Para reserva de memoria
para algoritmos
DSP DATA 12 0x99500000 Datos del ejecutable del
DSP
7 0x9DD00000 C´odigo ejecutable y datos
para el Controlador de Me-dia - HDVICP2
Reserved MC-HDVPSS Firm-ware
17 0x9E600000 C´odigo ejecutable y datos
para el Controlador de Me-dia - HDVPSS
UNUSED 3 0x9F900000 Bloque de memoria libre
B´uferes de datos
El mapa de memoria del SDK es utilizable a trav´es de b´uferes de datos. Estos son contenedores de informaci´on que se guardan en memoria para el almacenamiento temporal de datos [20], con los b´uferes se puede transmitir informaci´on entre aplicaciones o unidades que tengan acceso a la memoria del sistema.
2.5
Aplicaciones de procesamiento digital de se˜
nales
El procesamiento digital de se˜nales (PDS) genera soluciones en la actualidad en diversos campos. El PDS es una ciencia que se encarga del estudio y modelado de se˜nales captadas del mundo real para procesar sus datos por medios digitales [15].
2 Marco Te´orico 13
2.5.1
Operador Sobel como filtro de imagenes
Este operador funciona como una m´ascara que calcula sobre la imagen el gradiente de su contenido. La Figura 2.7 es un ejemplo de una imagen filtrada con un operador Sobel, donde se revela informaci´on de contraste l´uminico entre puntos contiguos y esto hace que se expongan zonas donde existen bordes.
El vector gradiente ∇f, se define como la tasa m´axima a la que se presenta un cambio de intensidad para una funci´on x,y [47].
∇f = (δ(f)/δ(x))i+ (δ(f)/δ(y))j (1)
donde la intensidad se refiere a intensidad lum´ınica y cada una de las derivadas parciales hace referencia a los cambios lum´ınicos en los espacios x y y.
Figura 2.7: Imagen original de una copa junto a su imagen filtrada con operador Sobel [6]
La detecci´on se logra utilizandoKernels, estos son matrices matem´aticas que operan sobre el pixel de la imagen y sus pixeles circundantes. El operador Sobel est´a compuesto de dos Kernels, uno que detecta los contrastes lum´ınicos de manera horizontal y el otro de manera vertical. [1]
• Kernel horizontal: este Kernel procesa la aproximaci´on digital de la derivada parcial respecto a la direcci´onx, δ(f)/δ(x)
14 2.6 Interfaces de programaci´on
Cada uno de ellos se posiciona sobre el pixel y calcula el cambio de intensidad entre el pixel y sus pixeles circundantes. El resultado del filtro es el c´alculo de la magnitud del gradiente |∇f|, esta se obtiene a partir de la ra´ız cuadrada de la suma de la potencia al cuadrado de las derivadas parciales [47],
|∇f|=p(δ(f)/δ(x))2+ (δ(f)/δ(y))2 (2)
La aproximaci´on digital de |∇f| se reduce a la suma de los resultados de las derivadas parciales.
2.6
Interfaces de programaci´
on
Las interfaces de programaci´on son medios y recursos de programaci´on para llevar a cabo distintos tipos de tareas [30]. Estas cubren diferentes prop´ositos para darle funcionalidad a las aplicaciones, por ejemplo una aplicaci´on que corre en un sistema GNU/Linux embebido puede reservar memoria para guardar datos y por medio de funciones transmitir esos datos a un proceso que es llevado en otra unidad.
2.6.1
Codec Engine
Desde la perspectiva de un desarrollador de aplicaciones, Codec Engine (CE) es un con-junto de interfaces que instancian y ejecutan algoritmos estandarizados. Particularmente con CE se pone en pr´actica el esquema de operaci´on cliente - servidor, este sirve como marco de trabajo que permite a la aplicaci´on cliente comunicarse con contenido remoto del DSP [23]. Por medio de esta interfaz se puede:
• Configurar par´ametros y argumentos de operaci´on
• Inicializar algoritmos y procesos
• Ejecutar procesos remotos
Codec Engine es un producto de software Texas Instruments. Este ofrece archivos y secuencias de construcci´on que de forma manual, se pueden utilizar junto al SDK para construir paquetes ejecutables para el DSP y el SoC.
2.6.2
OSAL: Capa de abstracci´
on de sistema operativo
2 Marco Te´orico 15 del sistema operativo, como registro e inicializaci´on de tareas y manejo de memoria para futuro uso por parte del algoritmo [46].
2.6.3
CMEM: Controlador de memoria f´ısica
CMEM es un m´odulo que facilita el manejo de uno o varios bloques de memoria f´ısica contigua y ofrece servicios de traducci´on de memoria virtual a f´ısica. Este controlador evita fragmentaci´on de memoria y asegura bloques de memoria contigua grandes para sistemas que se ejecutan por tiempo prolongado [12].
Por medio del SDK se le asigna a CMEM un espacio en el mapa de memoria. Este sector contiene a los b´ufer de datos que utiliza el procesador ARM y el DSP para intercambiar datos. El procesador de se˜nales no utiliza una unidad que le permita direccionar o inter-pretar memoria virtual, por eso el DSP opera con memoria f´ısica y CMEM le ofrece estos bloques en un formato en que los pueda accesar.
CMEM trabaja bajo una configuraci´on de bloques llamados pools, la Figura 2.8 ilustra como se compone esta estructura. Por medio de comandos se le asigna a CMEM un n´umero de pools definido a lo largo de una direcci´on de memoria y que cada uno de ellos almacene un n´umero particular de b´uferes los cuales tienen un tama˜no espec´ıfico. Estos se definen con base en las necesidades de memoria de la aplicaci´on y del sistema en el cual se ejecuta.
Búfer1 Búfer2 B1 B2 B3 B4
Dir. 0 x98
0000 00
Figura 2.8: Estructura depools y b´uferes de CMEM
2.6.4
xDM: Interfaz de media digital
Para programar aplicaciones en un ambiente de tiempo real, TI ofrece un conjunto de reglas y recomendaciones para implementar aplicaciones llamado XDAIS, el cual denota est´andar de interoperabilidad entre algoritmos. Por medio de reglas de programaci´on y convenciones de uso de recursos XDAIS se encarga de que diferentes algoritmos sean construidos en cierto tipo formato y puedan convivir en tiempo de ejecuci´on [7].
16 2.7 RTSC: Componentes de Software de Tiempo Real
de m´etodos y recursos escritos en el lenguaje de programaci´on C. Este ofrece variables, funciones, estructuras y otros recursos de programaci´on para implementar algoritmos multimedia [42].
IUNIVERSAL
IUNIVERSAL provee los m´etodos para adherir un algoritmo a la interfaz de multimedia, as´ı aprovechar a la arquitectura DM8168 con procesos que corren en el DSP llamados desde el procesador ARM [8]. Esta interfaz permite a los desarrolladores integrar algoritmos personalizados al DSP como por ejemplo algoritmos de segmentaci´on de im´agenes. El ciclo de vida de un algoritmo se ilustra en la Figura 2.9, desde una aplicacion cliente se hace un llamado a las funciones de la interfaz para llevar a cabo el siguiente ciclo de acciones:
• algAlloc: Se reserva memoria para el algoritmo
• algInit: Se inicializa el proceso que maneja el algoritmo
• algActivate: Activaci´on del algoritmo
• process: Procesamiento de datos
• control: Control de comportamiento del algoritmo en tiempo de ejecuci´on
• algDeactivate: Desactivaci´on del algoritmo
• algFree: Se libera la memoria reservada
Figura 2.9: Ciclo de vida de un algoritmo [42]
2.7
RTSC: Componentes de Software de Tiempo Real
2 Marco Te´orico 17 Los RTSC son desarrollados bajo el paradigma de programaci´on orientada a componentes. A diferencia de la programaci´on orientada objetos este paradigma abarca el ciclo de vida completo del software, estandariza su abstracci´on de tal manera que cualquier software definido e implementado por un tercero puede ser manipulado e implementado por la empresa [31].
Adem´as, las herramientas que utilizan esta estructura estandarizada le facilita a los desa-rrolladores la construcci´on, uso y reutilizaci´on de estos componentes, con la finalidad de acelerar el tiempo de creaci´on de aplicaciones embebidas. Por medio de los RTSC se puede manejar el ciclo de vida completo de un componente de software, desde su construcci´on hasta la monitorizaci´on de su operaci´on en tiempo real en un ambiente de ejecuci´on [26]. Una de las caracter´ısticas especiales de los RTSC es su portabilidad. El modelo RTSC permite el desarrollo de componentes escritos en C a trav´es de cualquier herramienta de compilaci´on, en cualquier entorno de desarrollo y para cualquier plataforma embebida. Esto revela que adem´as de portabilidad entre sistemas, los Componentes de Tiempo Real tienen adem´as un atributo de agnosticidad.
Los RTSC se manejan en un formato depaquetes como el que ense˜na la Figura 2.10. Los paquetes RTSC pueden agrupar distintos tipos de software, desde c´odigo fuente, biblio-tecas, archivos de configuraci´on y construcci´on u otros paquetes RTSC. En un contexto pr´actico, un paquete es un directorio que contiene el software necesario para ser construido y ejecutado en un ambiente de desarrollo:
Otro contenido
Figura 2.10: Contenido de un paquete RTSC
18 2.7 RTSC: Componentes de Software de Tiempo Real
• package.bld: Este archivo opera como un programa para construir el paquete, desde un punto de vista sencillo este archivo define cuales componentes estar´an involucra-dos a la hora de construir el paquete y que contenido distribuir cuando el paquete haya sido construido.
Los archivos package.xdc y package.bld forman una base para un paquete RTSC, teniendo estos se puede agregar m´as contenido que define caracter´ısticas al paquete, qu´e es lo que hace y otros atributos.
2.7.1
Servidor
En el desarrollo de aplicaciones para sistemas multiprocesador como el DM8168, se imple-menta software bajo el modelo de aplicaciones cliente - servidor. La Figura 2.11 muestra como el DSP ejecuta una aplicaci´on servidor que procesa datos provenientes del proce-sador ARM, esta opera sobre un ambiente de ejecuci´on que cuenta con controladores e interfaces del sistema. Una aplicaci´on servidor es un paquete RTSC, que anida a otro pa-quete RTSC llamadocodec, el cual contiene la implementaci´on del algoritmo para procesar los datos [41].
SYS/BIOS6
SYS/BIOSTM 6.x es un sistema operativo de tiempo real avanzado que puede ser
imple-mentado en un procesador ARM, un DSP o un microcontrolador. Est´a dise˜nado para uso en aplicaciones embebidas que necesitan calendarizaci´on, sincronizaci´on e instrumentaci´on de tiempo real [36].
La aplicaci´on servidor del DSP es corrida por este sistema operativo, debido a esto es necesario tener este paquete disponible para que el marco de trabajo lo utilice en su flujo de construcci´on de la aplicaci´on servidor.
2.7.2
Codec
2 Marco Te´orico 19
Sistema en Chip DM8168
ARM Cortex A8 DSP C6748
Sistema operativo GNU/Linux embebido
Sistema operativo de tiempo real BIOS6
Figura 2.11: Diagrama de aplicaciones cliente - servidor en el SoC DM8168
2.8
xdcTools
xdcTools es un producto que contiene todas las herramientas necesarias para crear, trans-portar, probar y ejecutar a los RTSC [5]. A partir de xdcTools, el SDK puede generar paquetes de software de tiempo real y contenido ejecutable para el DSP C6748.
2.8.1
xdc
xdc es un comando pertenecienta a xdcTools. Este es utilizado para construir paquetes RTSC y ejecutables que usan estos paquetes [2]. El comando es una envoltura de GNU Make, la cual le provee definiciones, opciones y variables propias de los paquetes RTSC que son necesarias para construir el software.
2.8.2
xs
Cap´ıtulo 3
Marco de trabajo para la ejecuci´
on
de procesos remotos
El dise˜o del marco de trabajo toma como punto de partida el reconocimiento de los paquetes de software necesarios para construir aplicaciones que se ejecuten en el DSP, esto involucra la utilizaci´on de Componentes de Software de Tiempo Real esenciales que generen c´odigo que sea ejecutado en un ambiente multiprocesador.
A partir de esto, se elaboran los m´etodos que incorporen las tecnolog´ıas de los RTSC y las interfaces de software necesarias al SDK de la plataforma. Esto para asistir al desa-rrollador de software con el proceso de construcci´on de aplicaciones embebidas, bajo el formato en el que el SDK integra aplicaciones al DM8168. Para ello se agrupa e imple-menta componentes de construcci´on especializados, contenido de software espec´ıfico para la arquitectura y secuencias de construcci´on que permiten entregar contenido ejecutable para el SoC.
3.1
Integraci´
on con el SDK
Las soluciones para aplicaciones multimedia que brinda la empresa en su mayor´ıa se desarrollan utilizando al SDK. Por lo tanto, es importante que el marco de trabajo se adapte a los m´etodos y formatos utilizados por el SDK con la intenci´on de que a los desarrolladores de software les sea r´apido y f´acil construir aplicaciones embebidas para el SoC, adem´as de darle portabilidad al marco de trabajo y facilitar su mantenimiento. La Figura 3.1 ense˜na como el marco de trabajo funciona en conjunto con el SDK y su sistema de integraci´on de aplicaciones. El marco de trabajo se apega a los sistemas de configuraci´on y construcci´on existentes, tambi´en da una clase para la generaci´on de contenido remoto que amplia las posibilidades de construir software, en este caso c´odigo ejecutable para el DSP de la arquitectura DM8168.
22 3.2 Esquema de operaci´on del marco de trabajo
ARM DSP
SoC DM8168
Sistema de integración de aplicaciones del SDK
programas de propietario o código abierto
Sistema de
Figura 3.1: Marco de trabajo junto al sistema de integraci´on de aplicaciones del SDK
3.2
Esquema de operaci´
on del marco de trabajo
El marco de trabajo tiene como prop´osito simplicar el proceso de construcci´on de software que se ejecuta en un ambiente multiprocesador, esto involucra la compilaci´on de paquetes de codecs y servidores para el DSP, adem´as de aplicaciones cliente para el procesador ARM. Para llegar a esto se puede definir un esquema de operaci´on general.
3.2.1
Configuraci´
on de entorno de desarrollo
Para que el marco de trabajo construya software debe contar con un entorno de desarrollo configurado, esto signfica contar con rutas, variables, paquetes y utilidades de software reconocidas y listas para usar.
La configuraci´on del entorno se ilustra en la Figura 3.2. Por medio de definiciones del SDK se cargan al entorno las variables y rutas de los paquetes necesarios para cons-truir contenido para el Sistema en Chip, entre los que resaltan: Codec Engine, OSAL, XDAIS, xDM y IUNIVERSAL. Con el entorno configurado, la capa superior encargada de construir software, puede usar estos componentes y generar contenido ejecutable.
3.2.2
Capa de construcci´
on
3 Marco de trabajo para la ejecuci´on de procesos remotos 23
Figura 3.2: Configuraci´on del ambiente de desarrollo GNU/Linux
comandos del marco de trabajo para generar contenido ejecutable para el SoC.
Ambiente de desarrollo GNU/Linux
Contenido ejecutable para ambiente multiprocesador
Figura 3.3: Construcci´on de software para un ambiente multiprocesador
3.2.3
Generaci´
on de software
24 3.3 Sistema de construcci´on
Figura 3.4: Generaci´on de contenido para arquitectura DM8168
3.3
Sistema de construcci´
on
El sistema de construcci´on consiste en el conjunto de secuencias que lleva a cabo el marco de trabajo para generar software para la arquitectura.
El sistema de construcci´on utiliza definiciones del usuario y definiciones internas para ejecutar alguna secuencia en particular. A partir de estas definiciones, durante el flujo de construcci´on el marco de trabajo accesa contenido interno para construir paquetes de software que tienen las caracter´ısticas determinadas por el usuario y que tienen las especificaciones apropiadas para el empotrado.
La Figura 3.5 muestra una simplificaci´on de los pasos que necesita el marco de trabajo para construir contenido, los cuales son:
• Configuraci´on
A partir de especificaciones de usuario en un archivo Makefile, se definen los nombres y a su vez las rutas de los paquetes que se pretende construir.
• Modos de uso del marco de trabajo
El marco de trabajo tiene secuencias de construcci´on que utiliza por defecto, por medio del Shell y la utilidad GNU Make el usuario puede interactuar con el marco de trabajo y as´ı determinar esquemas de construcci´on alternativos.
El modo de uso por defecto es el de integrar al SDK c´odigo propietario o c´odigo abierto existente. Por ejemplo, si se desea integrar al SDK un codec de codificaci´on de im´agenes JPEG, el marco tiene rutinas que permite manipularlo, construirlo y ejecutarlo en el SoC. Este tipo de uso tiene la ventaja de permitir la integraci´on de codecs compatibles con la arquitectura hechos por alg´un tercero.
3 Marco de trabajo para la ejecuci´on de procesos remotos 25 Adem´as de construir el software, se tienen un modo para destruirlo. El modo, usa se-cuencias para eliminar el contenido ejecutable que el marco de trabajo genera. Esto sin afectar archivos fuente ni archivos base del paquete que son necesarios para reconstruirlo.
• Construcci´on e instalaci´on de contenido
Finalmente, se construye el software con diferentes herramientas y comandos. Luego se instala el contenido en el sistema de archivos del SoC DM8168.
Inicio
Fin
modo de operación
Construcción de software
destruir contenido configuración
Instalación de contenido generación de
paquetes RTSC
Figura 3.5: Diagrama de flujo simplificado de operaci´on del marco de trabajo
3.4
Clase para la ejecuci´
on de procesos remotos
El SDK maneja un sistema de construcci´on de aplicaciones basado en clases, estas son archivos de la aplicaci´on GNU Make que tienen la informaci´on necesaria para generar aplicaciones embebidas bajo alg´un esquema de construcci´on.
26 3.4 Clase para la ejecuci´on de procesos remotos
hecha por el c´odigo fuente del DSP.
3.4.1
Metaprogramas
Para construir software para un ambiente de tiempo real, espec´ıficamente paquetes RTSC, la clase es asistida por metaprogramas. Los metaprogramas tambien pueden componer un paquete RTSC, solo que estos en vez de estar orientados a ser un producto final, se encargan de proveer informaci´on que asista al proceso de construcci´on de otros paquetes of software.
Un paquete RTSC que contenga un archivo package.xdc y package.bld, se construye a partir de definiciones de un archivo llamado config.bld. Este especifica cual herramienta de compilaci´on se utiliza, para cual o cuales dispositivos construir el paquete y con cuales opciones.
La Figura 3.6 muestra el contenido de este archivo que utiliza el marco de trabajo para construir paquetes RTSC. A partir de ellos se puede:
• Definir para cual procesador de la arquitectura DM8168 se va a construir c´odigo
• Cual herramienta va a construir el contenido
• Bajo que perfil y cuales opciones
• Para cual plataforma o m´aquina (m´odulo de evaluaci´on DM8168)
• Cual mapa de memoria va a utilizarse
A partir de los metaprogramas se pueden obtener definiciones para construir aplicaciones que manejen otro esquema de construcci´on del SDK. En el caso de aplicaciones cliente que son ejecutadas en el procesador ARM, estas pueden ser construidas con otra clase del SDK como la de autotools. Los dem´as sistemas de construcci´on que se implementan en las clases del SDK no manipulan Componentes de Tiempo Real como xdcTools, esto conlleva a generar una interfaz entre el sistema de construcci´on que maneja RTSC y otro sistema de construci´on que no lo maneje.
Para esto, un metaprograma llamadoARM.cfg es utilizado por la clase para generar ban-deras de compilaci´on y enlazado que son entregadas al sistema que construye aplicaciones cliente. En la Figura 3.7 el metaprograma define variables que abstraen informaci´on de los paquetes necesarios para construir la aplicaci´on del procesador ARM. A partir de la variable A, se usa una funci´on de xdcTools llamada xdc.useModule para obtener las definiciones necesarias del paquete OSAL.
3 Marco de trabajo para la ejecuci´on de procesos remotos 27
Figura 3.6: Estructura de metaprogramaconfig.bld para construir paquetes RTSC
Figura 3.7: Estructura de metaprograma ARM.cfg para configurar aplicaci´on cliente
3.4.2
Comandos de construcci´
on
La clase es utilizada por medio de comandos, estos pertenecen a los archivosMakefile. En la Figura 3.8 se ilustra el esquema de un comando t´ıpico para construir paquetes, el cual est´a compuesto por diferentes partes:
• Comando: Invoca una herramienta de construcci´on
• Componentes: Software que necesita el comando para funcionar
• Argumentos y opciones
28 3.4 Clase para la ejecuci´on de procesos remotos
El comando forma un bloque base que utiliza la clase en diferentes etapas de construcci´on. Una agrupaci´on de comandos definen las secuencias que usa el marco de trabajo para construir software para el procesador ARM y el DSP.
Componentes
Figura 3.8: Ejemplo de comando utilizado por la clase
3.4.3
Flujo de operaci´
on
La clase lleva un orden en el cual construye el contenido, esto se debe a una relaci´on de dependencias entre paquetes. Por ejemplo, para que una aplicaci´on servidor anide un codec, este primero debe de encontrarse construido. Ocurre de esta manera, porque la aplicaci´on del DSP ocupa anidar un codec que tenga las capacidades para ejecutarse en un ambiente de tiempo real.
Teniendo en cuenta la relaci´on de dependencia entre el paquete del servidor y el paquete del codec, se introduce otra dependencia. Como la aplicaci´on cliente se construye a partir de definiciones de la aplicaci´on servidor interpuestas por el metaprograma ARM.cfg, es un requisito que la aplicaci´on servidor se encuentre construida.
Esto abre paso a que el flujo de construcci´on t´ıpico sea de primero el codec, despu´es el servidor y por ´ultimo la aplicaci´on cliente. La Figura3.9ense˜na este flujo de construcci´on para paquetes existentes que se integran al SDK. Los comandos de xdcTools, xdc y xs ocupan un conjunto de rutas que definen los componentes para generar software llamadas Rutas XDC. Para el caso del codec, estas rutas apuntan a las interfaces XDAIS y IUNI-VERSAL ya que el algoritmo se implementar´a a trav´es de estas. Adem´as de las rutas, xdcTools opera con Argumentos XDC, como argumento se introduce al metaprograma config.bld el cual tiene las definiciones de la arquitectura y la herramienta de compilaci´on. En las Opciones XDC se utiliza la opci´on de reporte, la cual detalla en la l´ınea de co-mandos del Shell todas las etapas de construcci´on. Otra de las opciones es entrega, esto especifica que al finalizar la construcci´on del paquete se genere una versi´on comprimida de este. Con esto el paquete comprimido puede ser transportado a otro entorno de desarrollo y ser reutilizado. Al final del comando se especifica el codec que se desea construir. Cuando el codec termina de construirse, la clase delega la construcci´on al siguiente coman-do que construye a la aplicaci´on servidor. Este trabaja bajo el mismo formato del codec, lasRutas XDC contienen ahora m´as componentes para involucrarlos en la construcci´on, como el paquete BIOS6 y el codec construido en la etapa anterior.
3 Marco de trabajo para la ejecuci´on de procesos remotos 29 a los metaprogramas introducidos como argumentos, el comando abstrae la informaci´on necesaria para generar banderas de compilaci´on y enlazado que puedan ser interpretadas para el sistema de construcci´on de la aplicaci´on cliente. La aplicaci´on que se ejecuta en el procesador ARM es contruida con alguna de las clases que ofrece el sistema de construcci´on del SDK.
Figura 3.9: Sequencia de comandos de la clase
30 3.4 Clase para la ejecuci´on de procesos remotos
Adem´as del flujo de construcci´on de paquetes existentes, la clase permite crear paquetes RTSC desde cero como una utilidad del marco de trabajo. La Figura 3.10 muestra los comandos para generar un codec y una aplicaci´on servidor desde cero. La clase utili-za el comando xs para lanzar programas de xdcTools que automatizan la generaci´on de paquetes. Con las rutas y opciones especificadas el comando ejecuta la aplicaci´on genco-decpkg que genera autom´aticamente un paquete base para el codec. A parte del codec, se puede lanzar la aplicaci´on genserverpkg que genera una aplicaci´on servidor con las especificaciones del metaprograma config.bld.
Figura 3.10: Comandos para generar paquetes RTSC base con xdcTools
3 Marco de trabajo para la ejecuci´on de procesos remotos 31
Inicio
modo de operación
gencodecpkg destruir contenido
configuración del marco de trabajo
instalación de software en el sistema de archivos
del SoC DM8168 Construcción
de servidor Construcción
de codec
Generación de banderas con configuro
genserverpkg
Construcción de aplicación cliente
Fin
Cap´ıtulo 4
Implementaci´
on de detector de
bordes
El marco de trabajo se utiliza para integrar al SDK una aplicaci´on de prueba para filtrar im´agenes. TI tiene una biblioteca de procesamiento digital de im´agenes llamada IMGLIB [37]. Esta ofrece una funci´on del lenguaje de programaci´on C que implementa un operador Sobel utilizando dos Kernels de im´agenes.
4.1
Personalizaci´
on de la interfaz de media digital
Para procesar datos en el DSP el operador Sobel es llamado a trav´es de la interfaz xDM, esto implica que la funci´on de IMGLIB se encuentre apegada al formato y m´etodos de la interfaz.
4.1.1
Funci´
on
process
La funci´on process de xDM es llamada para que tome los datos provenientes del la aplica-ci´on cliente, que los procese con el detector de bordes y que devuelva la imagen filtrada. La Figura 4.1ense˜na como la biblioteca de IMGLIB est´a envuelta por la funci´onprocess. Adem´as, con argumentos de esta funci´on, se le pasa al operador Sobel informaci´on del tama˜no de la imagen. Esto permite que la imagen sea procesada de la forma correcta. Existen algoritmos que al finalizar devuelven argumentos de salida, la funci´on process permite manejar estos argumentos. Sin embargo para este caso particular el operador Sobel de IMGLIB no los necesita y por lo tanto no son devueltos.
34 4.2 IMG sobel 3x3
Figura 4.1: Envoltura del operador Sobel en la funci´onprocess de la interfaz xDM
4.1.2
Expansi´
on de argumentos de la interfaz IUNIVERSAL
IUNIVERSAL es una interfaz gen´erica, esta no tiene por defecto atributos de altura y ancho de im´agenes. Para que el codec responda a un tama˜no de imagen definido por la aplicaci´on cliente, el tama˜no es manipulado a trav´es de la interfaz. La Figura 4.2 muestra como un codec anida la estructura de argumentos de entrada de IUNIVERSAL. A partir de esta se adhieren los atributos necesarios para que la interfaz pueda manipular la informaci´on de las dimensiones de la imagen y operar este contenido en el filtro. La aplicaci´on se trabaja con una imagen cuya resoluci´on es de 640 pixeles a lo ancho y 480 pixeles a lo alto (640x480).
Estructura base de IUNIVERSAL
Altura en pixeles de la imagen Estructura en C de codec Sobel
640 px 480 px
Ancho en pixeles de la imagen
Figura 4.2: Expansi´on de estructura de IUNIVERSAL del codec Sobel
4.2
IMG sobel 3x3
4 Implementaci´on de detector de bordes 35 forma horizontal y vertical con base en la informaci´on de los pixeles circundantes. Despu´es se calula la magnitud del gradiente con la suma de los resultados de los Kernels.
La umbralizaci´on se hace a partir de funciones condicionales. Para un pixel, el c´alculo de la magnitud del gradiente es llevada a cero si es inferior ante un par´ametro de umbral definido o llevado a su m´aximo si el c´alculo de la magnitud del gradiente es mayor ante el par´ametro de umbral. Por cada pixel procesado se realiza una escritura en el b´ufer de salida. Si el b´ufer de entrada no ha sido recorrido por completo se itera las veces necesarias para filtrar la imagen por completo.
Inicio
Figura 4.3: Diagrama de flujo de la operaci´on del filtro Sobel
4.2.1
Formato de la imagen
36 4.3 Aplicacion cliente
crudo. El formato crudo presenta ´unicamente datos propios de la imagen sin metainfor-maci´on que la caracterize, as´ı es posible que el operador recorra de manera iterativa el b´ufer de entrada pixel por pixel, sin la necesidad de reconocer alg´un formato y tener que decodificarlo para aplicar el filtro.
Adem´as, como el operador Sobel calcula el gradiente del contenido, la informaci´on de cromacidad de la imagen (como el color de esta) es irrelevante. M´as bien, el filtro opera sobre el contraste que existe entre diferentes regiones de la im´agen, precisamente los contrastes l´uminicos. Debido a lo anterior la im´agen de entrada se presenta en escala de grises y formato crudo. Se considera la relaci´on de tama˜no en pixeles de la imagen con el tama˜no en memoria de la misma. Tomando un caso pr´actico se utiliza una tuberia de GStreamer que genera un archivo crudo, en escala de grises y a 8 bits por pixel,
8 bits/pixel= 1 byte/pixel
640 x 480 pixeles = 307200 bytes
Estos datos se usan para reservar memoria, y as´ı asegurar el espacio suficiente en el mapa de memoria cuando la aplicaci´on se ejecute.
4.3
Aplicacion cliente
La aplicaci´on que se ejecuta en el procesador ARM llama al proceso remoto utilizando Codec Engine. Adem´as de eso, realiza los preparativos necesarios para ser una aplicaci´on funcional en un entorno de ejecucci´on GNU/Linux embebido. La Figura 4.4ilustra como funciona la aplicaci´on desde el comienzo hasta el final.
La memoria que se utiliza para transmitir los datos del procesador ARM al DSP debe de ser configurada. En esta etapa se define que la memoria es f´ısica contigua, adem´as de sus banderas y alineaci´on. Con los par´ametros de memoria listos, la funci´onMemory Alloc de la interfaz OSAL reserva espacio para los b´ufer de entrada y salida, el controlador CMEM se encarga de reservar memoria f´ısica contigua a partir de la solicitud de la aplicaci´on cliente.
Codec Engine debe cargar componentes para manejar un proceso remoto. Con la apertura de un proceso de Codec Engine a trav´es de la funci´on Engine open es posible comuni-carse con otros procesadores bajo un esquema cliente - servidor, esto abre el paso a la inicializaci´on del algoritmo con la funci´onUNIVERSAL create y hacer uso de ´el.
4 Implementaci´on de detector de bordes 37 Por otro lado, si los preparativos est´an listos se puede empezar el llamado al proceso del DSP. Como el operador Sobel necesita tener las dimensiones de la imagen, se definen esos valores en los argumentos de entrada de IUNIVERSAL (que se encuentran expandidos) para manejar estos datos. La aplicaci´on lee un archivo (de formato crudo) que es colocado en el b´ufer de entrada y se invoca a la funci´onprocess para ejecutar el filtro de imagenes. Cuando el c´omputo de los datos termina, la informaci´on recibida en el b´ufer de salida es escrita en un archivo, este archivo contiene la imagen con bordes detectados por el operador Sobel. Finalmente se libera la memoria ocupada por la aplicaci´on.
Inicio Configuración de
Cap´ıtulo 5
Configuraci´
on del ambiente de
ejecuci´
on
Para llevar la implementaci´on del filtro de im´agenes a la arquitectura, el marco de trabajo da especificaciones al sistema operativo GNU/Linux embebido. Estas indican bajo cuales condiciones de operaci´on la aplicaci´on puede ejecutarse, esto se hace por medio de un programa del Shell que es entregado junto a la aplicaci´on del filtro al momento de la instalaci´on. Este lleva a cabo inicializaciones y configuraciones del sistema antes de que el detector de bordes sea ejecutado.
Por medio de la Figura 5.2 se representan las tareas que hace el programa del Shell, que consisten en cargar m´odulos al sistema GNU/Linux embebido y configurar el uso de memoria de la partici´on.
5.1
Partici´
on de Linux
En el mapa de memoria del EVM DM8168 se toma una porci´on de la partici´on de Linux para alojar el ejecutable del DSP. Esto lleva a que el programa reduzca con un comando el tama˜no de la partici´on:
MEM=168M
Esto reduce la partici´on del sistema Linux de 364MB a 168MB.
5.2
Carga de m´
odulos
La estructura de CMEM para la aplicaci´on de prueba se muestra en la figura 5.1. La aplicaci´on cliente necesita reservar b´uferes de entrada y salida. Al momento en el que la aplicaci´on cliente llama a la funci´on para reservar memoria, CMEM atiende la solicitud
40 5.2 Carga de m´odulos
y le asigna uno de los b´ufer disponibles. Esto se realize por medio de un par´ametro que define las caracter´ısticas de memoria y un comando que carga el m´odulo:
CMEM_PARAMS= phys_start=0x96C00000 phys_end=0x98000000 pools=2x307200
modprobe cmemk CMEM_PARAMS
CMEM
Dir. 0 x96
C00 000
Pool 1 Búfer de entrada
Dir. 0 x98
0000 00
Búfer de salida
307200 bytes
Figura 5.1: Configuraci´on de CMEM para alojar los b´uferes del DSP
Esto define una regi´on de CMEM para esas direcciones de memoria, con un pool que tiene dos b´uferes de datos cada uno de 307200 bytes de espacio en memoria. Todos estos comandos son ejecutados por el programa de configuraci´on del ambiente de ejecuci´on que muestra la Figura 5.2. Otro de los m´odulos que se carga es syslink. syslink provee software de conectividad entre m´ultiples procesadores [22], el cual es insertado al sistema GNU/Linux embebido con el siguiente comando,
5 Configuraci´on del ambiente de ejecuci´on 41
Inicio
Definición de parámetros del controlador de memoria
Redefinición del tamaño de la partición Linux embebido
Carga de módulos CMEM y syslink al sistema Linux embebido
Fin
Cap´ıtulo 6
Resultados y An´
alisis
6.1
Factorizaci´
on de secuencia de construcci´
on
El proyecto se encarga de reordenar y agrupar la sencuencia de construcci´on de TI y pasarla a un formato aprovechable por un desarrollador del SDK. La Figura 6.1 expo-ne como el sistema de construcci´on se transforma, en la subfigura a la construcci´on de paquetes para un ambiente multiprocesador en la arquitectura DM8168 se realiza desde Codec Engine.
Este contiene software de configuraci´on denotadocfg y un sistema de construcci´onbld que permiten generar aplicaciones cliente, servidor, y codecs. Este esquema de construcci´on no utiliza el sistema de integraci´on de aplicaciones del SDK. Por lo cual, no se aprovechan los sistemas de configuraci´on y construcci´on existentes, esto hace que se subutilicen recursos del SDK para el sistema en chip DM8168 y resta din´amica al entorno de desarrollo para manipular software.
Por otro lado la subfigurab expone el redise˜no de la secuencia de construcci´on, el marco de trabajo toma las definiciones y componentes necesarios que operan bajo el pre´ambulo de TI y los traduce al formato del SDK. Los metaprogramas tambi´en forman parte del marco de trabajo. Con esto es posible generar de una manera simplificada c´odigo ejecutable y que adem´as forme parte del repositorio interno de aplicaciones del SDK y del sistema de archivos de GNU/Linux embebido.
6.2
Reducci´
on del tiempo de construcci´
on
Con la factorizaci´on, se da una reducci´on en el tiempo de construcci´on de software para la arquitectura. En la Tabla6.1se muestra un experimento en el cual se reducen los tiempos que emplea un desarrollador con conocimientos en el manejo de paquetes RTSC y el SDK. Se divide por etapas, la etapa de configuraci´on del ambiente de desarrollo requiere definir todas las rutas de paquetes y la versi´on exacta de los mismos, adem´as deben definirse
44 6.2 Reducci´on del tiempo de construcci´on
(a) Sistema de construcci´on original
(b) Sistema de construcci´on factorizado
6 Resultados y An´alisis 45
Tabla 6.1: Reducci´on de tiempo de construcci´on de software
Etapa de construcci´on
compiladores junto a sus opciones, la arquitectura para cual construir y bajo que modelo de operaci´on. El marco de trabajo contempla todas estas definiciones con la finalidad de que el desarrollador dedique su tiempo a construir e implementar c´odigo.
La construcci´on de software con el sistema original utiliza definiciones y componentes que se encuentran dispersos. Esto ocasiona que el flujo de construcci´on deba de hacer b´usqueda de utilidades de programaci´on en diferentes rutas. Con el marco de trabajo las definiciones para generar c´odigo se encuentran centralizadas.
Por medio del programa que configura el ambiente de ejecuci´on, el desarrollador define el entorno donde la aplicaci´on del filtro de im´agenes se ejecuta. Ante la ausencia del programa de configuraci´on, el desarrollador tendr´ıa que identificar las necesidades de la arquitectura para ejecutar la aplicaci´on de prueba, adem´as de ejecutar los comandos pertinentes. El cambio del sistema de construcci´on hace una mejora en el tiempo de creaci´on de aplicaciones de un 73.4%.
6.3
Detecci´
on de bordes en imagen de prueba
46 6.3 Detecci´on de bordes en imagen de prueba
(a) (b) (c)
Figura 6.2: Imagen de ejemplo con resoluci´on de 640 x 480 convertida a escala de grises y procesada por el operador Sobel
(a) Umbral=28% (b) Umbral=56% (c) Umbral=69%
(d)Umbral=82% (e) Umbral=86% (f ) Umbral=96%
Figura 6.3: Juego de imagenes filtradas por operador Sobel con diferentes niveles de umbral
que ser´ıa blanco. La Figura 6.3 expone diferentes valores de umbral que se le asignan al algoritmo para cambiar su comportamiento ante el c´alculo de la magnitud del gradiente. La figura muestra que con par´ametros de umbral bajos como el de la subfigura a, el operador Sobel tiene un comportamiento m´as inclusivo ante contrastes l´uminicos que presente la imagen. Esto ocasiona tambi´en, que ante contrastes l´uminicos poco intensos en regiones compactas, el filtro pierda claridad en la detecci´on.
6 Resultados y An´alisis 47
Tabla 6.2: Carga de procesamiento de operador Sobel ejecutado en el procesador ARM y en los procesadores ARM y DSP
Proceso local
El operador Sobel se implementa de dos formas en el SoC con el motivo de comparar la carga entre los procesadores. La carga de procesamiento cuando el operador Sobel se ejecuta ´unicamente en el procesador ARM y cuando se ejecuta en el DSP es mostrado en la Tabla 6.2. Para el caso cuando el filtro se implementa en un ´unico procesador, la cantidad de carga de trabajo que tiene el procesador ARM se debe a que este lleva a cabo operaciones aritm´eticas del filtro de im´agenes de forma recursiva por cada pixel. El procesador ARM tiene una arquitectura que es m´as aprovechable para tareas de admi-nistraci´on y supervisi´on de procesos y no para operaciones de procesamiento digital de im´agenes.
Por otra parte, se ejecuta el filtro en el DSP y se usa al procesador ARM como administra-dor. Por medio de la funci´on de Codec Engine Server getCpuLoad se hace una solicitud informaci´on de carga al sistema operativo de tiempo real BIOS6. Este atiende la solicitud y transmite la informaci´on de carga a trav´es de la interfaz. En este caso todo el algoritmo es llevado a cabo por el DSP. La aplicaci´on cliente solo maneja la lectura y escritura de archivos y el control del flujo de ejecuci´on.
6.5
Mapa de memoria resultante
48 6.5 Mapa de memoria resultante
Cap´ıtulo 7
Conclusiones
Los sistemas empotrados y el desarrollo de soluciones basadas en sistemas Linux, abarcan distintas consideraciones t´ecnicas, desde la manipulaci´on de un sistema de construcci´on para arquitecturas espec´ıficas, hasta t´ecnicas de programaci´on especiales para sistemas con limitaciones de memoria y potencia computacional.
El Kit de Desarrollo ofrece amplios recursos de software y utilidades de programaci´on. Sin embargo las formas en las que se presentan estos componentes de software son tan amplias y a veces complejas que imposibilita el aprovechamiento de todos estos medios por parte de un desarrollador en un escenario pr´actico.
Las aplicaciones de procesamiento digital de se˜nales tienden a ser de consumo alto en cuanto a carga de procesamiento, la implementaci´on de dichas t´ecnicas en un sistema em-potrado aumentan el reto de su integraci´on y su desempe˜no en un contexto de aplicaciones embebidas.
La elaboraci´on del proyecto, involucra la investigaci´on de tecnologi´as de software que forman una base te´orica que es necesaria para el dise˜no del marco de trabajo. Esto permite la incorporaci´on de nuevas t´ecnicas y recursos de programaci´on al SDK del DM8168. El uso de las interfaces de programaci´on que manipulan a los RTSC en tiempo de ejecu-ci´on, son m´etodos est´andar que utilizan un lenguaje para abstraer tareas comunes. Las interfaces facilitan el uso de diferentes recursos del SoC bajo un mismo formato. Los Componentes de Software de Tiempo Real ofrecen contenido de software que permiten a los desarrolladores generar soluciones embebidas implementables en un ambiente multi-procesador como el que ofrece el SoC DM8168.
El marco de trabajo para la ejecuci´on de procesos remotos utiliza medios y recursos del SDK que ofrecen una interfaz que habilita el desarrollo e implementaci´on de Componentes de Tiempo Real, siempre apegado al sistema de integraci´on de aplicaciones. El marco es un medio facilitador para formar una base de desarrollo de aplicaciones embebidas, este automatiza y acelera el proceso de construcci´on de paquetes de software para el DSP en un 73%, permitiendo a un desarrollador concentrarse en el dise˜no de algoritmos para
50
esta arquitectura sin la necesidad de invertir tiempo en el sistema de construcci´on de los RTSC.
Para un desarrollador que no tenga experiencia en el uso de los RTSC y ante la ausencia del marco de trabajo, a este le puede tomar aproximadamente 4 meses (que corresponde al tiempo disponible para realizar este proyecto) en construir e implementar un algoritmo para el DSP. Tomando de referencia una hora de trabajo ingeniero que corresponde a 85 dolares, para un plazo de 4 meses involucrar´ıa un costo aproximado de 54 mil dolares, este capital junto a las horas invertidas deben de ser cobradas a los clientes. Esto aumenta el precio de aplicaciones embebidas y dificulta la competividad de la empresa en el mercado de aplicaciones que utilicen t´ecnicas de PDS.
Por otro lado, la utilizaci´on del marco de trabajo y la clase del sistema de integraci´on del SDK puede reducir el tiempo de este proceso a 1 mes aproximadamente, considerando que el sistema de construcci´on es automatizado y el desarrollador dirige su tiempo de trabajo ´
unicamente a la creaci´on e implementaci´on de algoritmos de PDS.
La implementaci´on del filtro de im´agenes utilizando la interfaz IUNIVERSAL es un pun-to de comienzo para que la empresa incursione en t´ecnicas de procesamiento digital de im´agenes m´as sofisticadas y complejas en el SoC DM8168. El operador Sobel necesita de una umbralizaci´on para detectar bordes de una manera m´as inclusiva o exclusiva. Este par´ametro tiene que ser fijado de acuerdo a las particularidades de la aplicaci´on que lo implemente, de manera que el filtro sea lo suficientemente sensible a los bordes que se buscan detectar.
Utilizar al DSP como procesador esclavo libera carga de trabajo del procesador ARM, esto permite a que este se dedique a otras tareas, incluyendo la delegaci´on de m´as procesos a otras unidades esclavas. La reducci´on de la carga de procesamiento de 96% a 3% en el procesador ARM se debe a que la arquitectura se encarga ´unicamente de controlar el proceso remoto, mientras que el procesamiento de la imagen es realizado en su totalidad por el DSP.
Para que dos procesadores se transfieran datos, ambos deben de implementar correcta-mente las interfaces de programaci´on para que exista una comunicaci´on coherente entre ellos.
7 Conclusiones 51
7.1
Recomendaciones
Los Componentes de Software de Tiempo Real adem´as de ser utilizados para generar contenido ejecutable para el DSP C6748 del SoC DM8168, permiten generar c´odigo eje-cutable para el Subsistema Ducati. El Subsistema Ducati usado por la empresa tiene el limitante de ser un firmware sin c´odigo fuente distribuido. Esto restringe la utilizaci´on de t´ecnicas de codificaci´on, decodificaci´on, captura y despliegue de datos de im´agenes y video. Por ejemplo, para implementar un codificador de im´agenes JPEG en el Subsistema Ducati no se tiene un sistema de construcc´on integrado al SDK que genere c´odigo ejecu-table para el m´odulo HDVICP2. Adem´as se necesita de un codec JPEG, que implemente una interfaz xDM para que el procesador ARM (anfitri´on) lo pueda invocar por medio del Controlador de Media. Esto involucra obst´aculos t´ecnicos en cuanto a manipulaci´on y desarrollo de Componentes de Software de Tiempo Real necesarios para operar en un escenario de multiprocesamiento del SoC.
El marco de trabajo para la ejecuci´on de procesos remotos fue dise˜nado en miras a cubrir esta carencia. El marco provee una base de software para generar contenido ejecutable para el Controlador de Media (procesadores ARM Cortex M3) y los m´odulos HDVICP2 y HDVPSS. A trav´es del marco se pueden integrar nuevas t´ecnicas de procesamiento de datos multimedia en estos m´odulos.
Con base en esto, el proyecto abre el espacio a que los desarrolladores expandan las ca-pacidades del marco de trabajo. De esta manera, puede formar parte un entorno de desarrollo completo para sistemas embebidos que tengan unidades de procesamiento de-dicadas. Existen otros sistemas (como el DM8148, OMAP3530, entre otros) que tienen un sistema de desarrollo basado en RTSC, de esta forma se abre la posibilidad de usar el marco de trabajo para otros productos de Texas Instruments que la empresa utiliza. Otro punto importante, es que en el transcurso del proyecto se revelaron diferentes codecs y algoritmos que pueden ser usados por el marco de trabajo. Con esto se pueden incur-sionar en m´as t´ecnicas de procesamiento de datos multimedia en el DSP C6748. Entre los cuales resaltan;
• Codecs que ofrece Texas Instruments
TI ofrece un decodificador AAC-LC de audio, este paquete est´a construido y listo para ser integrado al DSP C6748.
• IMGLIB
La biblioteca IMGLIB contempla funciones de an´alisis, de filtrado, y de compresi´on/decompresi´on de imagenes.
IMG ycbcr422p rgb565: Para conversi´on de contenido visual de formato Y‘CbCr hacia formato RGB.
52 7.1 Recomendaciones
IMG wave horz: Este es un wavelet que genera una descomposici´on peri´odica ortogonal en una dimensi´on. Esta puede ser utilizada para compresi´on de imagenes para el formato JPEG 2000, el cual es superior al formato JPEG convencional en cuanto a desempe˜no de compresi´on y otras m´etricas. Su complemento vertical tambien se encuentra en la biblioteca [43].
![Figura 2.1: Arquitectura del sistema en chip DM8168 [25]](https://thumb-us.123doks.com/thumbv2/123dok_es/3772887.646256/28.918.122.758.346.810/figura-arquitectura-del-sistema-en-chip-dm.webp)
![Figura 2.4: Sistema de comunicaci´ on por video que se implementa en el EVM DM8168 [10]](https://thumb-us.123doks.com/thumbv2/123dok_es/3772887.646256/31.918.168.792.87.522/figura-sistema-comunicaci-por-video-que-implementa-evm.webp)
![Tabla 2.1: Bloques del mapa de memoria para la arquitectura DM8168 Segmento Longitud [MB] Direcci´ on base Uso](https://thumb-us.123doks.com/thumbv2/123dok_es/3772887.646256/34.918.103.775.115.555/tabla-bloques-mapa-memoria-arquitectura-segmento-longitud-direcci.webp)
![Figura 2.7: Imagen original de una copa junto a su imagen filtrada con operador Sobel [6]](https://thumb-us.123doks.com/thumbv2/123dok_es/3772887.646256/35.918.269.695.426.747/figura-imagen-original-junto-imagen-filtrada-operador-sobel.webp)
![Figura 2.9: Ciclo de vida de un algoritmo [42]](https://thumb-us.123doks.com/thumbv2/123dok_es/3772887.646256/38.918.236.641.600.846/figura-ciclo-de-vida-de-un-algoritmo.webp)
