La Shell DSP de Linux

por Michael Stricklen, Bob Cummings, Brandon Bonner

Traducción de Jordi Cabot

Introducción

Historia del proyecto 

El Center for Telecommunications Education and Research (CTER) de la Universidad de Alabama en Birmingham está actualmente involucrado en la investigación en el campo de las arquitecturas de sistemas de tele patología y su rendimiento. El objetivo de esta investigación es ayudar a los médicos en el diagnóstico de las enfermedades en especimenes microscópicos. Si el componente encargado de la adquisición de las imágenes en el sistema de tele patología tuviera la capacidad de obtener diagnósticos preliminares en algunos casos, podría ayudar a los médicos a completar el diagnóstico en un tiempo breve. Esta aproximación a la tele patología es la principal motivación  de la shell DSP de Linux (Bonner, 1999). Este tipo de investigación requiere una plataforma estable y robusta, que permita la adquisición de imágenes en tiempo real y un procesamiento complejo. La naturaleza de la aplicación de telemedicina también requiere el uso de subsistemas que no afecten negativamente el rendimiento global.  Por estas razones así como por razones económicas, Linux fue el entorno elegido. No obstante, las soluciones para el procesamiento de imágenes sobre Linux han sido limitadas. Esto ha sido así hasta que Wes Hosking et al., (Hosking 1998), portaron la Dipix Vision Library (XVL) a Linux. Esto hizo posible conseguir un sistema de procesamiento de imágenes en tiempo real para Linux.

A pesar de que la idea de este proyecto surge de un proyecto financiado de investigación relativo a la telemedicina, el desarrollo del prototipo de la shell DSP fue iniciado como parte de un Diseño Senior en el departamento de Ingeniería Informática y Eléctrica de la UAB. Como tal, los objetivos del diseño de estudiante eran paralelos a los del proyecto. Combinando los resultados del desarrollo de la plataforma de aplicación para Linux junto con las informaciones extraídas de la culminación de la experiencia de estudiantes universitarios en Ingeniería, esperamos exponer a los lectores interesados tanto los procesos de los estudios técnicos como las excelentes propiedades para el desarrollo que presenta el entorno Linux.

Objetivos

Los resultados deseados para la Shell DSP de Linux, fueron definidos la principio, pero al tiempo que el proyecto progresaba estos ítems flexibles tendieron a cambiar. Los objetivos actuales son los siguientes:

Decisiones de Diseño

Como se ha dicho anteriormente, este proyecto es parte de un Diseño Senior. Como tal, el tiempo disponible está muy restringido, por lo que se han tenido que hacer algunas simplificaciones al problema. Una de estas simplificaciones surge de darse cuenta que la complejidad y la naturaleza de este proyecto lleva por si mismo a una solución jerárquica. Para proporcionar al usuario un interfaz transparente, se usa un script interactivo en lugar de una shell completamente integrada. En la Shell DSP simplificada, un proceso demonio (proceso de larga vida que se ejecuta en background) controla el subsistema XPG-1000 vía las invocaciones a las funciones de la librería, y el script interactúa con el demonio a través de tuberías con nombre (named pipes, FIFOs) como se muestra en la Figura 1.


Figura 1. Diagrama de la arquitectura de la Shell DSP de Linux.

Además de ser sencillo de implementar, esta arquitectura tiene un efecto de desacoplo en la interfaz entre el usuario y el DSP. En efecto, el DSP incrustado, la solución de adquisición y la librería de procesamiento de imágenes, conforman un sistema de recursos compartidos a los que se puede acceder a través de varios mecanismos.

Desarrollo del Proyecto

Adquisición de imágenes en Linux y el Dipix XPG 1000

No hay muchas opciones para el procesamiento sofisticado de imágenes en un entorno Linux. La tabla 1 compara las opciones más potentes de hardware gráfico disponible para Linux. El hardware listado en la tabla tiene excelentes opciones para la adquisición y/o procesamiento de imágenes o vídeo. No obstante, el Dipix XPG 1000 tiene unas capacidades particulares que lo hacen mucho más potente y versátil que los otros. Las capacidades clave del XPG 1000 incluyen la capacidad de simultanear la adquisición de imágenes y el procesamiento en tiempo real, la captura de pantallas, la transferencia de datos hasta un máximo de 48 Mbytes por segundo, y un sencillo soporte para múltiples cámaras analógicas o digitales, ya sean estándares o no, y para múltiples formatos de señales de vídeo. Los módulos de adquisición por  cámara (xCM) para la interfaz  XPG interaccionan con el XPG vía un conexión "piggyback". Juntos, el XPG y el módulo de interfaz con la cámara ocupan un solo slot PCI en el ordenador servidor. La variedad de flexibles y programables módulos de adquisición por cámara permiten al XPG simultanear la interfaz con múltiples cámaras analógicas o digitales.


Tabla 1. Capturadores de pantallas, DSPs, y procesadores de imágenes en tiempo real para Linux

La librería de funciones de visión para la máquina Dipix XVL es también una consideración importante en contraste con las capacidades de varias soluciones. XVL contiene más de 200 funciones basadas en DSP para la adquisición , procesamiento y control de imágenes en tiempo real. También incluido con el paquete XVL hay un entorno interactivo de línea de comando basado en Windows, que proporciona a los usuarios acceso a la mayoría de funciones del XVL. Este entorno software permite la exploración interactiva de diferentes técnicas de imagen y proporciona resultados inmediatos. La duplicación y la robusta extensión de este entorno es el objetivo del proyecto de la Shell DSP de Linux.

Desarrollo de una interfaz apropiada para el XPG 1000

Como restricción debido a los requerimientos del proceso de diseño, la interfaz con el XPG 1000 tiene que aceptar comandos que son abstracciones de la funcionalidad del XPG 1000. Por ejemplo, el usuario no tendría que preocuparse de inicializar el hardware o de reservar memoria para  un buffer de imágenes. Los comandos tendrían que aplicarse directamente a la terminología de proceso de imágenes. Por ejemplo si el usuario quiere "capturar" una imagen con la cámara, "capturar" tendría que ser el comando elegido para conseguir este objetivo. Otros ejemplos de comandos apropiados serian "adquirir" (guardar la imagen a disco) y "filtrar" (filtrar la imagen mientras se guarda en el hardware). 

La librería de funciones del Dipix XVL es accesible a través de invocaciones des de funciones en C. Esto limita el acceso directo al XPG 1000 al uso de software linkado con las librerías XVL. Esta limitación causa problemas para mantener las funcionalidades de la shell de usuario. Hay varias soluciones a este problema. La primera de estas soluciones es el desarrollo de una shell para UNIX completamente nueva. Esta implementación permitiría acceder totalmente  a la funcionalidad del XPG 1000 como parte de la shell misma. Con esta aproximación, no seria necesario un paquete separado de software para interactuar con el XPG 1000 ya que los comandos serian entrados desde el prompt de la shell o escritos en un fichero como otros shell scripts. Esta solución seria la mejor de las alternativas, pero la implementación de esta funcionalidad implicaría la construcción de un interprete para analizar la estructura del script, etc. Por tanto, esta aproximación no es posible en el Diseño Senior debido a restricciones de tiempo. No obstante, el objetivo final para el proyecto de la Shell DSP de Linux es implementar completamente esta shell con el soporte a varias soluciones DSP además del Dipix XPG

Una segunda solución seria considerar el uso de muchos programas pequeños. Por ejemplo, si el usuario deseara filtrar una imagen, un programa llamado "filtrar" podría ser invocado desde el prompt de la shell. Esta solución permitiría mantener la modularidad y la funcionalidad de la shell. No obstante, con esta aproximación el sistema pierde eficiencia y flexibilidad, ya que la carga del servidor es demasiada grande.

Después de considerar estas y otras opciones, la solución elegida fue la creación de una interfaz intermediaria con la  librería de funciones del XVL. Esta aproximación no integra la interfaz de usuario y la interfaz XVL/XPG en un programa monolítico ni tampoco abstrae las capacidades del XPG 1000 al nivel deseado por el usuario. En su lugar, esta aproximación proporciona una interfaz con la  librería de funciones del XVL basada en la entrada/salida más que en las invocaciones de las funciones en  lenguaje C. Esto efectivamente desacopla la librería del XVL en C del nivel de aplicaciones de usuario, ya que la entrada /salida de esta interfaz puede ser redirigida a la entrada/salida de otros programas a través de una comunicación entre procesos. La comunicación entre procesos, que será discutida en detalle más adelante, se define como la comunicación entre dos o más procesos o programas. Esta solución generaliza la interfaz con el XPG 1000, por lo que otro programa o incluso un script puede acceder a la  librería de funciones del XVL. Esta aproximación permite la creación de una seudo-shell, que el usuario puede poner como una nueva capa encima de su entorno operativo sin perder funcionalidad de línea de comandos.

Creación de una ``Seudo-Shell'' con Expect

Expect es una extensión al lenguaje de scripts llamado TCL, también conocido como``Tool Command Language'' (Ousterhout, 1994). Expect fue creado por Don Libes con el objetivo de automatizar los programas interactivos (Libes, 1995). Un script Expect cumple con la automatización de los programas interactivos a través de la producción o  iniciación de un programa o proceso interactivo. Después, usando un comando "interactivo", la "seudo-shell" Expect actúa como un filtro para la entrada del proceso creado. Cuando una cadena pasa entre el usuario y el programa creado (o viceversa), es primero examinado por la seudo-shell. Si ésta reconoce un patrón en la cadena, el script ejecuta las instrucciones definidas por el autor del script. Cuando el script no reconoce un patrón, la cadena es enviada directamente al proceso producido ( o al usuario). Un ejemplo de script Expect que interactúa con la shell de usuario se muestra en la Figura 2. En este ejemplo, la interfaz original de línea de comandos es engendrada y una seudo-shell interactiva se coloca entre el usuario y la shell producida. Si el usuario entra "hello" en el prompt de la seudo-shell, la shell captura la cadena y remite la cadena "goodbye". Si el usuario entra cualquier otra cadena o comando para el que no hay ninguna acción de la seudo-shell definida, el comando pasa directamente a la shell original para su ejecución. Este método puede crear fácilmente una interfaz de usuario transparente hacia el XPG 1000 a través de la creación  de la shell original como un proceso interactivo. De esta manera, el usuario seria capaz de interactuar con la shell para los comandos normales, pero toda entrada seria primero examinada  por el script Expect de la seudo-shell. El script Expect aparecería como invisible para el usuario. Además, la funcionalidad de la shell original se mantendría ya que cualquier comando de la shell entrado por el usuario no seria reconocido por el script, y por lo tanto seria pasado a la shell. Por último, la funcionalidad del XPG 1000 parecería que existiese com parte de la shell de usuario.


Figure 2. Ejemplo Expect script which interacts with a shell.

Comunicaciones entre procesos

Hasta el momento, hemos definido una interfaz general para el XPG 1000 basada en un demonio XVL y una interfaz de usuario usando un script Expect que actúa como a "seudo-shell". Las dos interfaces utilizarán una forma de comunicación entre procesos (IPC: interprocess communication). Actualmente, el sistema usa tuberías con nombre como una forma simple de IPC, no obstante, hay varios métodos para conseguir IPC en un entorno UNIX. En el futuro la Shell Dsp de Linux se implementará usando System V IPC.

La interfaz System V IPC consiste en semáforos, colas de mensajes y segmentos compartidos de memoria. (Goldt et al., 1995;Matthew et al., 1997; Volkerding et al., 1997). Los semáforos se usan para asegurar la exclusividad mutua en un recurso compartido. Este acceso exclusivo evita desastres que pueden ocurrir cuando varios procesos están leyendo o escribiendo en un mismo lugar. Los procesos tendrán que esperar su turno hasta que su acceso sea permitido.

Las colas de mensajes proporcionan un método para enviar un bloque de datos de un proceso a otro. Con este método, la sincronización de las lecturas y las escrituras no es necesario ya que la cola de mensajes existe fuera de los procesos. No obstante, hay una limitación que depende del sistema, respecto al tamaño del bloque de datos que puede ser enviado a la cola de mensajes así como del número de bloques que pueden existir dentro de la cola en un momento dado.

La memoria compartida, como su nombre implica, permite a dos procesos compartir un mismo segmento de memoria. La memoria compartida es la forma más rápida de IPC. La memoria compartida permite a cada proceso ver inmediatamente un cambio en los datos hecho por otro proceso. No obstante, este método es asíncrono. La sincronización de la memoria compartida se deja al programador. Esta sincronización normalmente se manejan con el uso de semáforos.

Uno de los métodos más simples para implementar la IPC es el uso de tuberías. Las tuberías son comunes en el entorno UNIX. Las tuberías son tan comunes que pueden ser usadas para redireccionar la entrada y la salida de los programas ejecutados desde la línea de comandos. También pueden ser configuradas dinámicamente por un proceso. Las tuberías con nombre, o FIFOs (first-in, first-out, primero en entrar, primero en salir), fueron las escogidas como método IPC para este proyecto. El uso de FIFOs en este caso es de gran ayuda, ya que , en relación a otros métodos IPC, son sencillas de implementar y fáciles de usar. Una vez la FIFO ha sido creada, existe dentro de la estructura de archivos del sistema operativo. Como resultado, la comunicación a través de FIFOs es tan fácil como leer y escribir en archivos normales. Las FIFOs son llamadas a veces "archivos especiales" porque una vez un proceso lee los contenidos de la FIFO, estos contenidos son eliminados y la FIFO queda vacía.

Diseño del Sistema

Como se ha mencionado anteriormente, la interfaz transparente de usuario hacia el XPG 1000 se ha conseguido con el uso de Expect. Esto permite al usuario interactuar con su shell normal y simultáneamente con el XPG 1000. El script Expect comunica la interfaz intermediaria con el XPG 1000 a través del uso de FIFOs. La interfaz intermediaria es un programa especial linkado a las librerías del XVL. El demonio XVL se ejecuta como un proceso background por lo que puede ser invisible al usuario y disponible para todos los usuarios sin necesidad de una configuración o reserva de memoria. El uso del demonio permite que haya múltiples interfaces con los usuarios sin cambiar la interfaz de programación con el XVL. Dos FIFOs son usadas para la comunicación bidireccional entre el script Expect y el demonio XPG. La Figura 3 ilustra esta comunicación. Un ejemplo explicado ilustrará mejor el flujo de los comandos y los procesos en la shell DSP.

Cuando el usuario envía un comando a través del prompt de la shell, el script Expect compara este comando con las funciones de procesamiento de imágenes de alto nivel de la shell DSP. Estas funciones tienen nombres simbólicos como instantánea, adquisición o filtro. Si el comando corresponde a una de estas funciones de procesamiento de imágenes, es capturada por la seudo-shell para dividirla en comandos simples. El primero de estos comandos es escrito en la FIFO, donde el demonio XPG espera una de estas comunicaciones. Una vez el comando de bajo nivel ha sido escrito en la FIFO por el script Expect, el demonio XPG lee la FIFO. Este comando de bajo nivel puede ser incluso dividido en comandos de más bajo nivel por el demonio con el fin de invocar adecuadamente las funciones de la librería de funciones del XVL. Una vez la función XVL retorna, el demonio escribe la información referente al éxito o al fracaso de este "comando atómico"  a una segunda FIFO, donde la seudo-shell Expect está esperando la respuesta. La seudo-shell lee la información enviada por el demonio XPG. Esta información es después retransmitida al usuario para avisarle del éxito o del fracaso del proceso. Este procedimiento itera hasta que un comando de alto nivel dado por el usuario es completado, o una parte del proceso falla 


Figure 3. Linux DSP Shell system diagram.

Control a través de Shell Scripts

Esta implementación de la Shell DSP de Linux permite un intuitivo control en tiempo real de los subsistemas de procesamiento de imágenes incrustados, que pueden ser implementados a través de simples shell scripts. Los shell scripts son simplemente archivos de texto que contienen secuencias de comandos de la shell. En el entorno UNIX, uno puede automatizar funcionalidades comunes de la shell con estos shell scripts. Desde el momento que la interfaz con el XPG 1000 parece existir dentro de la shell, uno puede automatizar tareas de adquisición y procesamiento de imágenes, complejas. Esta capacidad permite un rápido desarrollo de aplicaciones de procesamiento de imágenes en tiempo real, creando la posibilidad de un testeo rápido de un algoritmo, de una forma intuitiva y flexible.

Conclusiones y recomendaciones

Para concluir, lo más importante de este proyecto es construir un entorno robusto de el desarrollo rápido de aplicaciones  para el procesamiento de imágenes y señales que actualmente no esta disponible en ninguna plataforma. Las recomendaciones para un futuro trabajo incluye la implementación completa de las capacidades del  Dipix XPG 1000. Además, el sistema tendría que estar implementado usando colas de mensajes y segmentos de memoria compartidos en lugar de FIFOs. Las colas de mensajes permitirían a los procesos separados ser más eficientes, ya que no tendrían que esperar que otros procesos les enviasen información como pasa en el caso de las simples FIFOs. La compartición de segmentos de memoria permitiría a los programas intercambiar cantidades más grandes de datos para llegar a un demonio XVL multi-usuario y multi-proceso. El objetivo actual del proyecto de la shell DSP es la funcionalidad del Dipix. El objetivo global del proyecto es ampliar la capacidad de esta shell a otras soluciones DSP disponibles para Linux. Una manera de hacer esto es abstraer las funciones DSP más ampliamente implementadas en una API común. Una vez hecho esto, cada solución DSP individual podría incluir su propio módulo de funciones propietarias. Con esta tecnología la shell DSP de Linux podría interactuar con otras tarjetas DSP a medida que estén disponibles para el entorno Linux. Una herramienta así probaría su valúa a los desarrolladores de aplicaciones de proceso de señales.

Agradecimientos

A los autores les gustaría dar las gracias a las siguientes personas: Dr. Stan McClellan (nuestro intrépido líder), Dr. Murat M. Tanik (por su visión sin fin y su sabiduría infinita), Linus Torvalds, GNU Project, Wesley Hosking, Coreco (anteriormente Dipix), la comunidad Linux, los miembros de la lista de correo de Linux Dipix, y nuestras familias y amigos.

Referencias

1
Bonner, B., Stricklen, M., McClellan, S. ``The Linux DSP Shell.'' A aparecer en
Conference Proceedings LinuxEXPO 99.
2
Goldt, S., van der Meer, S., Burckett, S., Welsh, M. The Linux Programmer's Guide. March 1995. http://linuxwww.db.erau.edu/LPG/index.html
3
Hosking, W. Atlantek. http://www.atlantek.com.au/USERS/wes/linux/frame.html
4
Libes, D. Exploring Expect. Cambridge: O'Reilly & Associates, Inc., 1995
5
Matthew, N., Stones, R. Beginning Linux Programming. Birmingham, UK: WROX Press, 1997
6
Ousterhout, J. Tcl and the Tk Toolkit. Reading, Massachusetts : Addison Wesley, 1994
7
Volkerding, P., Foster-Johnson, E., and Reichard, K. Linux Programming.New York : MIS:Press, 1997

Copyright 1999 Michael Stricklen and Brandon Bonner

Michael Stricklen es un  asistente investigador de Dr. Stan McClellan en el Center for Telecommunications Education and Research en el campus de la Universidad de Alabama en Birmingham. Actualmente está involucrado en un proyecto de investigación fundado por Bellsouth (que tiene relación con Linux, por supuesto). Cuando no está mirando fijamente al monitor le gusta practicar snowboard, golf, y otras actividades al aire libre. Se puede contactar con él  vía e-mail a goose@uab.edu

Bob Cummings trabaja como asistente investigador estudiante en el Center for Telecommunications Education and Research en la  UAB, donde actualmente es un estudiante en Ingeniería Eléctrica. Sus intereses incluyen la programación en Perl, pescar, y la percusión. Se puede contactar con él vía e-mail a bahb@uab.edu.

Brandon Bonner trabaja como asistente investigador en la Universidad de Alabama en Birmingham, donde esta trabajando para conseguir el título en Ingeniería Informática y Eléctrica. En su abundante tiempo libre disfruta saliendo al aire libre y tocando instrumentos musicales. Se puede contactar con él via e-mail a bwbonner@uab.edu.

Page hits since January 3, 2000: 23

Quiere más artículos de Crossroads acerca de las Interfaces de usuario? Vaya al índice o al  anterior.

Quiere más artículos de Crossroads acerca de Linux? Vaya al índice o al siguiente 

Last Modified: [an error occurred while processing this directive]
Location: www.acm.org/crossroads/xrds6-1/dspshell2.html