ESTUDIO Y EVALUACIÓN DEL SISTEMA OPERATIVO μclinux APLICADO A SISTEMAS EMBEBIDOS MÓVILES DE ALTA COMPLEJIDAD

Transcripción

1 ESTUDIO Y EVALUACIÓN DEL SISTEMA OPERATIVO μclinux APLICADO A SISTEMAS EMBEBIDOS MÓVILES DE ALTA COMPLEJIDAD Proyecto para optar al título de Ingeniero Electrónico ANA MARÍA FERNÁNDEZ PÉREZ LUIS GERMÁN GARCÍA MORALES Asesor Dr. JOSÉ EDINSON AEDO COBO Profesor Departamento de Electrónica UNIVERSIDAD DE ANTIOQUIA FACULTAD DE INGENIERÍA DEPARTAMENTO DE ELECTRÓNICA MEDELLÍN 2005

2 AGRADECIMIENTOS Agradezco a mi familia, a mi novia Ana María, a mis amigos, compañeros y todas las personas que han sido de gran apoyo a lo largo de este hermoso viaje al mundo electrónico. También le agradezco a los profesores David Fernández, Orlando Carrillo, Darío Olaya, Eugenio Duque y José Aedo por los valiosos conocimientos que me han brindado. L.G.G.M Agradezco a todas las personas que me apoyaron durante toda mi estancia en esta hermosa Universidad, especialmente a mi Mamá, Adiela, Juan Camilo y sobretodo a mi novio Luis Germán. También quiero agradecer a los profesores Amado Tavera, Orlando Carrillo, Eugenio Duque y José Aedo, quienes me dieron la oportunidad para demostrar mis capacidades. A.M.F.P.

3 DEDICATORIA A Dios, que me ha dado todas las herramientas necesarias para construir mi propio camino. A mi madre Rosa Inés, quien siempre deseó lo mejor para mí vivir. L.G.G.M. A mis amigos y compañeros que me han acompañado durante estos años en la carrera, y a Dios por darme vida y salud. A.M.F.P.

4

5 TABLA DE CONTENIDO Pag. LISTA DE FIGURAS... 7 LISTA DE TABLAS... 9 INTRODUCCIÓN OBJETIVOS OBJETIVO GENERAL OBJETIVOS ESPECÍFICOS CONCEPTOS BÁSICOS DE UN SISTEMA EMBEBIDO COMPONENTES DE HARDWARE Procesador Memorias Board de Evaluación Periféricos COMPONENTES DE SOFTWARE Sistema Operativo Inicio del Sistema Operativo Bootloader Aplicaciones y Sistemas de Archivos HOST Y TARGET Tipos de Hosts Tipos de Configuraciones de Desarrollo Host / Target Tipos de Configuraciones de Depuración Host / Target Tipos de Configuraciones de Arranque HERRAMIENTAS PARA LA CONSTRUCCIÓN DE UN SISTEMA EMBEBIDO... 38

6 2. SISTEMA OPERATIVO LINUX ELECCIÓN DEL SISTEMA OPERATIVO Por Qué Linux? Distribuciones de Linux Embebido µclinux, un Descendiente de Linux PRELIMINARES CARACTERÍSTICAS DEL KERNEL DE LINUX FRENTE A OTROS SISTEMAS VISIÓN GENERAL DEL KERNEL DE LINUX Versiones del Kernel de Linux Programas y Procesos Modelo Proceso/Kernel Kernel Reentrante Espacio de Direcciones de un Proceso Sincronización y Regiones Críticas ARQUITECTURA DE LINUX Gestión de Procesos Gestión de Memoria Señales y Comunicación entre Procesos Drivers de Dispositivos Sistema de Archivos Módulos Interfaz de Llamadas al Sistema FUNCIONALIDAD DE LINUX El Arranque de Linux Llamadas al Sistema Los Procesos Interrupciones y Excepciones Sincronización del Kernel Medidas de Tiempo Manejo de la Memoria del Sistema Sistema de Archivos Virtual Scheduler o Planificador de Procesos... 95

7 2.7. µclinux Historia Razones para Utilizar µclinux Diferencias entre Linux y µclinux Librerías Compartidas Librería C Usada con µclinux Distribución de µclinux TÉCNICAS DE BAJO CONSUMO DE ENERGÍA PROPIEDADES DEL DISEÑO DE BAJA POTENCIA Flujo de Diseño Modelos de Componentes CMOS DISEÑO DE BAJA POTENCIA A NIVEL DE SISTEMA Arquitectura de Hardware del Sistema Reducción de Energía en la Comunicación Sistema Operativo y Aplicaciones Periféricos COMPONENTES DE UN SISTEMA EMBEBIDO PROCESADORES Y SISTEMAS EN CHIP PARA APLICACIONES EMBEBIDAS Basados en ARM Basados en MIPS Basados en PowerPC Otras Arquitecturas DISPOSITIVOS DE ALMACENAMIENTO DISTRIBUCIÓN µclinux Organización de la Distribución Características de la Distribución µclinux Dónde se Obtiene la Distribución µclinux? SISTEMAS DE ARCHIVOS Sistemas de Archivos Journaling Sistemas de Archivos sin Disco

8 Caracterizando Sistemas de Archivos BOOTLOADER Selección del Bootloader Instalación INTERFACES GRÁFICAS DE USUARIO GUI Y NAVEGADORES WEB APLICACIONES A IMPLEMENTAR EN EL DESARROLLO HERRAMIENTAS DE DESARROLLO PARA LA IMPLEMENTACIÓN HERRAMIENTAS DE DESARROLLO INTERPLATAFORMA O TOOLCHAIN COMPONENTES DE LA TOOLCHAIN Binutils Gcc Librerías Otros Componentes VERSIONES DE LOS COMPONENTES REQUERIMIENTOS PARA LA CONSTRUCCIÓN Host Componentes Script de Automatización CONSTRUCCIÓN DE LA TOOLCHAIN Carpetas para el Proceso de Construcción Definiciones de Variables Los Componentes Configuración y Construcción de la Toolchain Uso de la Toolchain Uso de la Toolchain para Compilar el SO y las Aplicaciones HERRAMIENTAS DE DEPURACIÓN O DEBUG Depuración de Aplicaciones con Gdb Seguimiento de Aplicaciones Análisis de Desempeño

9 Depuración de Memoria DESARROLLO E IMPLEMENTACIÓN SISTEMA DE DESARROLLO Procesador Motorola DragonBall MC68VZ Memorias RAM y ROM Bootloader Otras Características IMAGEN DEL KERNEL Y DE TODO EL SISTEMA CONFIGURACIÓN DEL SISTEMA Consideraciones Generales Consideraciones sobre la Distribución Configuración y Compilación del Kernel Generación del Sistema de Archivos Raiz Configuración y Compilación de Aplicaciones Imagen Final del Sistema Configuración Usando la Distribución μclinux INSTALACIÓN DE LA IMAGEN FINAL EN EL TARGET EVALUACIÓN EVALUACIÓN DEL SISTEMA µclinux Y RESULTADOS INTRODUCCIÓN PRUEBAS A REALIZAR REALIZACIÓN DE LAS DIFERENTES PRUEBAS Y EVALUACIONES Modificaciones al Entorno de μclinux Trabajando con el Hardware ucdimm y ucevolution Redes Ethernet y Protocolos TCP/IP e ICMP Multitarea con µclinux Consumo de Potencia

10 8. ESTRATEGIAS SUGERIDAS PARA LA IMPLEMENTACIÓN DE µclinux EN SISTEMAS MÓVILES DE ALTA COMPLEJIDAD ADMINISTRACIÓN DINÁMICA DE LA POTENCIA Políticas sin Interacción Directa Administración de Potencia Controlada por el Solicitante Método Intermedio OTRAS ESTRATEGIAS Escalonamiento Dinámico de Voltaje y Frecuencia Modificaciones al Compilador C Reducción de Consumo en Memorias Sistema de Archivos Procesamiento Remoto Protocolos de Red Sacar el Máximo Provecho del Módulo ACPI de μclinux para M68k Optimización del Código Esencial del Kernel Desarrollo de un Bootloader CONCLUSIONES APÉNDICE A: Código en C del Juego Implementado en el Sistema para Corroborar la Funcionalidad de µclinux APÉNDICE B: Script para la Construcción de la Toolchain ABREVIATURAS Y DEFINICIONES BIBLIOGRAFÍA

11 LISTA DE FIGURAS Pag. figura 1. Configuración enlazada figura 2. Configuración de almacenamiento removible figura 3. Configuración independiente figura 4. Medio de almacenamiento de estado sólido figura 5. Numeración de las versiones del kernel figura 6. Arquitectura de Linux figura 7. Dependencias entre los principales componentes del sistema figura 8. Estructura de directorios del kernel Linux figura 9. Gestor de procesos figura 10. Interfaz entre drivers, kernel y dispositivos figura 11. Esquema del sistema de archivos figura 12. Estados de un proceso figura 13. Lista de procesos figura 14. Procesamiento de una interrupción figura 15. Retornos de interrupciones y excepciones figura 16. Organización de los procesos en la memoria figura 17. Fragmentación de la memoria figura 18. Representación del consumo en un sistema, usando técnicas de bajo consumo

12 figura 19. Escalonamiento en voltaje y frecuencia figura 20. Subsistema MTD figura 21. Organización del código fuente de la distribución figura 22. Sistema de archivos en flash figura 23. Directorio de descargas figura 24. Opciones de configuración del kernel figura 25. Directorios de la distribución µclinux figura 26. Menú de configuración de la distribución figura 27. Menú de configuración de aplicaciones figura 28. Pantalla de Inicio de µclinux figura 29. Mensajes del juego en el terminal figura 30. Configuración de la interfaz de red figura 31. Listado de directorios del host visualizados en el target figura 32. Visualización de una página de prueba desde un computador remoto figura 33. Estadística de procesos en ejecución figura 34. Ejemplo de modos de bajo consumo modelados con máquina de estados figura 35. Máquina de estados de potencia de dos estados figura 36. Planificación para un solo dispositivo figura 37. Planificación para varios dispositivos figura 38. Planificación sugerida

13 LISTA DE TABLAS Pag. tabla 1. Flujo de diseño general y ejemplos relacionados para reducción de energía tabla 2. Características de los sistemas de archivos tabla 3. Colección de herramientas Binutils tabla 4. Combinaciones de versiones que produjeron una toolchain correcta tabla 5. Parches necesarios para la toolchain tabla 6. Entorno de trabajo sugerido para la construcción de la toolchain tabla 7. Contenido de la carpeta ${PREFIX} tabla 8. Contenido de la carpeta ${PREFIX}/${TARGET} tabla 9. Estructura de carpetas para sistema de archivos raíz tabla 10. Archivos del directorio /dev tabla 11. Tabla de convenciones de algoritmo DPM tabla 12. Relación entre I d (τ) y I d ( τ + 1)

14 INTRODUCCIÓN En la actualidad, el uso de dispositivos de mano o portátiles se hace cada vez mayor. Estos dispositivos permiten interactuar con el usuario en una serie de aplicaciones que van desde una agenda hasta la comunicación de datos, video y sonido. Los equipos portátiles mas recientes incluyen utilidades como block de notas, agendas, reproductores de audio, video e incluso conexión a Internet. Sin embargo, estos dispositivos aún están en fase de madurez, todavía falta mucho por estudiar en este campo. Cada día se generan nuevas estrategias de diseño, arquitecturas internas, metodologías para el manejo eficiente de energía, etc. Una tendencia actual busca generar arquitecturas que utilicen dispositivos reconfigurables que reemplacen el papel de los buses de datos de las arquitecturas recientes, con el fin de eliminar el cuello de botella que representan éstas. Una tendencia moderna se basa en el uso de procesadores que tienen un nivel de procesamiento muy elevado, originando un alto consumo de energía y baja portabilidad, ya que al ser sistemas secuenciales necesitan de un flujo de datos demasiado elevado para un buen manejo de aplicaciones como video, audio, Internet, entre otros. La idea es descargar el procesador de algunas tareas complejas que se realizan de manera ineficiente y asignar estas tareas a módulos más especializados que las ejecuten en menor tiempo y con menor consumo de potencia. Otro problema que se presenta en las arquitecturas de datos, son los buses. Todo dato que se lleva como video, audio, datos, entre otros, tiene siempre que ir a la memoria principal, ser procesado por la CPU, volver a memoria y así; el ciclo se repite un número de veces moviendo casi los mismos datos. Lo anterior se puede considerar como momentos muertos en el sistema de computación y lleva a que se necesite de altas velocidades de procesamiento para hacer las tareas lo más rápido posible. Los estándares de video y audio también están en proceso de estudio. A cada momento se realizan nuevas modificaciones para mejorar características como calidad, compresión y flujo de datos. Esto lleva a que no se pueda tener un hardware definitivo que se encargue de manejar los streaming de video y audio, ya que tendremos que estarlo modificando casi permanentemente. Una solución es tener un software que se pueda modificar pero, el software actual hace uso de arquitecturas que 10

15 requieren de alto procesamiento, que no son de utilidad para equipos móviles o portátiles. Una arquitectura en hardware que pueda reconfigurarse sería una solución más efectiva, teniendo un sistema dedicado exclusivamente para una tarea específica. Las nuevas tecnologías podrían entonces ser fácilmente reconfigurables, pero, superar la flexibilidad que tiene un procesador es una misión bastante complicada. Hay que buscar lo mejor de la tecnología actual (CPUs, FPGAs, entre otros) y unirlos, escogiendo muy bien la tarea de cada uno y estructurando el sistema como una conjunción de elementos operando para un fin común y no descargando todo el procesamiento en un solo módulo. Los sistemas computarizados de hoy en día tienden a ser cada día más y más pequeños pero con una diversidad de tareas bastante amplia como se mencionó anteriormente, además de la posibilidad de ser móviles o altamente portátiles. Un sistema de mano o portátil obviamente no puede tener una alimentación estática, caso de un toma corriente o algo similar, es necesario la instalación de una batería para su movilidad. Tener un sistema que pueda tener gran versatilidad en tareas como audio, video y otros lleva a tener altos procesamientos con las arquitecturas actuales, haciendo que la batería se torne un problema. Es necesaria la implementación de una arquitectura sólida y confiable que pueda abarcar un gran número de tareas, teniendo un uso óptimo de los recursos, entre estos, el consumo de energía. Para poder realizar esto, se necesita hacer un estudio de las técnicas existentes mediante software y hardware para hacer uso óptimo de la energía. El uso eficiente de energía mediante hardware está relacionado con las tecnologías actuales, sin embargo, el manejo de energía mediante software, lleva a considerar una serie de elementos en el sistema operativo que brinden muy buen soporte a las aplicaciones y que a la vez optimice el consumo de energía. Se hace entonces necesario el estudio y evaluación de un sistema operativo para determinar la mejor forma en que debe usarse con un procesador en general y que a la vez permita aplicar técnicas de bajo consumo para todo el sistema. Muchos sistemas operativos están disponibles en el mercado, sin embargo, existen unos especializados en manejo de sistemas móviles, que son altamente portátiles y pueden ser reconfigurados. Es el caso de µclinux, un derivado del kernel 2.0 de Linux orientado a manejar 11

16 procesadores que no cuentan con MMU, que se caracterizan por ser altamente portátiles, de bajo costo y consumo. Este trabajo buscar realizar un estudio detallado del sistema operativo para entender su funcionamiento, su estructura, su modo de instalación y otras características que éste maneja, en especial, las relacionadas con técnicas de bajo consumo de energía. Enmarcados en un proyecto general para la construcción de un dispositivo móvil que haga las veces de acompañante personal, surge esta propuesta como una parte constituyente de todo el proyecto. Este tiene como uno de sus constituyentes el estudio y evaluación de un sistema operativo orientado a aplicaciones móviles embebidas complejas, donde el bajo consumo es un tema de suma importancia y que debe considerarse en la integración de todo el sistema. 12

17 OBJETIVOS OBJETIVO GENERAL Estudio y evaluación del sistema operativo μclinux para su utilización en sistemas embebidos móviles de alta complejidad. OBJETIVOS ESPECÍFICOS Estudiar el funcionamiento del sistema operativo μclinux, su forma de instalación, su operación, su kernel y las herramientas del sistema. Implementar el sistema operativo μclinux y evaluar su funcionamiento para aplicaciones en sistemas móviles digitales. Estudiar las técnicas de bajo consumo de energía apropiadas para la implementación a nivel del sistema operativo. Proponer estrategias para adaptar el sistema operativo μclinux en sistemas complejos que exijan bajo consumo de energía. Completar los requisitos para obtener el titulo como Ingenieros Electrónicos. 13

18 1. CONCEPTOS BÁSICOS DE UN SISTEMA EMBEBIDO Un sistema embebido se conforma de varias unidades funcionales para realizar eventualmente una o varias tareas muy específicas, de acuerdo si éstas están orientadas a ser estáticas o móviles. Un sistema de este tipo deberá tener una parte de hardware capaz de procesar toda la información de acuerdo a la finalidad que se le quiera dar. Habrá, memoria no volátil para guardar aplicaciones y datos, memoria volátil para el procesamiento de la información, CPU para procesar los datos tanto internos como externos al sistema, además de interfaces para manejar diferentes tipos de comunicación como USB, IrDA, Ethernet, PCMCIA, entre otros. También debe existir una parte de software encargada, junto con el hardware, de dar vida al sistema que se desea crear. Dicho software se encargará del control completo de todo el hardware. En sistemas embebidos que son complejos, una parte de software que debería estar para controlar las aplicaciones y el hardware es el sistema operativo (SO). Con un SO, las aplicaciones no tienen que preocuparse de acceder directamente al hardware, operación que en algunos casos es muy complicada y tediosa de realizar. El SO será el administrador de todo el sistema y se encargará de abstraer toda la funcionalidad del hardware para que el software de aplicación pueda sacar el máximo partido de él de una manera sencilla. Obviamente, las aplicaciones y el sistema operativo deberán estar almacenados en alguna parte, lo más conveniente en este caso, será almacenar todos los programas en memoria no volátil, como es el caso de memorias ROM, flash, CompactFlash, entre otros. Para un manejo más robusto y eficaz, los datos no pueden ser almacenados de cualquier forma, debe haber una estructura para organizar los datos que se almacenan en algún dispositivo o medio para ello. Lo anterior supone el uso de un sistema de archivos que pueda ser administrado por el sistema operativo en su totalidad y además permita que las aplicaciones puedan acceder de forma segura a los datos. Normalmente, un sistema operativo trae el soporte completo para el manejo de uno o varios sistemas de archivos. En la construcción del sistema embebido se deben tener en cuenta dos conceptos importantes: host y target. El término host se utiliza para indicar el sistema donde se realizará el desarrollo de todo el software del sistema embebido (codificación, configuración del sistema operativo, compilación, enlace, compresión, imagen del SO, construcción de las aplicaciones, entre otros). El término target hace referencia al sistema embebido propiamente. Deberá existir la forma de poder comunicar el 14

19 host con el target con el fin de poder descargar todo el software del sistema en este último, además de poder hacer depuración de las aplicaciones que se instalen. Es de notar la gran variedad de términos que se emplean en un sistema embebido complejo. Por lo tanto, para tener mejor claridad de cada parte del sistema, tanto en su construcción como en su aplicación, se realizará una breve descripción en este capítulo de todas las partes que intervienen en éste, relacionando las diferentes unidades funcionales con el sistema operativo µclinux. Varios de los conceptos que se indican en este capítulo no son necesarios si el sistema operativo a usar fuera otro distinto a Linux, o bien µclinux. En próximos capítulos se hará hincapié en los diferentes elementos o unidades disponibles que conforman un sistema embebido (hardware, software de aplicación y SO) y se explicará porque se han escogido algunos de ellos y no otros COMPONENTES DE HARDWARE Procesador Existen muchas clases de procesadores que se encargan, como su nombre lo indica, procesar la información de un programa que se aloja en algún almacenamiento. En sistemas móviles complejos, se pueden tener desde procesadores simples que necesitan diferentes módulos externos para controlar el flujo de datos que viene por una red o por una interfaz inalámbrica, manejo de LCDs, interfaces seriales, I2C, entre otras, hasta procesadores muy sofisticados que contienen todos los módulos mencionados anteriormente en el mismo, hablamos de SoC (System On Chip). Linux o µclinux, el sistema operativo a evaluar, se puede ejecutar en un gran número de arquitecturas, pero no todas estas arquitecturas realmente son usadas en sistemas embebidos. Ahora bien, Linux necesita que el procesador o la arquitectura cuente con una Unidad de Administración de Memoria o MMU, de lo contrario no podrá funcionar. µclinux, tomado del propio kernel de Linux, ha sido reescrito con el fin de poder manejar arquitecturas que no cuentan con una MMU, tal es el caso de los procesadores M68k de Motorola, ARM sin MMU, Intel i960 y otros procesadores. MMU es un componente esencial en las arquitecturas de hardware ya que controla todos los 15

20 llamados a memoria por parte del procesador. Entre las funciones están la traducción de direcciones de memoria virtual a direcciones físicas, protección, control de la memoria caché, manejo del bus y otras características. Pensando en un sistema embebido móvil, el cual podrá tener módulos externos para la realización de diferentes tareas, el procesador no tendrá que ser un elemento muy complejo o sofisticado, permitiendo escoger arquitecturas simples que no cuentan con muchas interfaces de comunicación, ni tampoco con MMU como M68k, ARM, i960, entre otros. En el capítulo 4 se mostrarán algunos de los procesadores y SoCs que se pueden utilizar para sistemas embebidos móviles. Algunos de ellos pueden trabajar directamente con Linux debido a que poseen MMU o pueden trabajar con µclinux si tienen esta unidad, pudiéndose desactivar. La descripción del procesador que se usará para evaluar µclinux en este trabajo se hará en el capítulo 6. Unidad de Administración de Memoria La Unidad de Administración de Memoria o MMU es un componente del hardware de un computador responsable del manejo de las peticiones de acceso a memoria por parte de la CPU. Entre las funciones de tales dispositivos están, la traducción de direcciones virtuales a direcciones físicas, protección de memoria, control de caché, tráfico en bus, y en arquitecturas de computador simples, especialmente de 8 bits, como conmutador de bancos [1]. Una MMU también resuelve el problema de fragmentación de memoria. Después de que bloques de memoria hayan sido reservados y liberados, la memoria libre puede volverse fragmentada (discontinua) de modo que los bloques más grandes de memoria continua pueden ser mucho más pequeños que la cantidad total. Una MMU requiere un espacio de silicio significativo y además el código necesario para manejarla también utiliza espacio de memoria, esto hace que no se justifique su uso en muchos sistemas embebidos donde la estructura de programa es simple o no hay suficientes recursos de memoria como para requerir administración. En general, para beneficiarse de una MMU se necesita estar ejecutando un sistema operativo que la pueda administrar, lo cual tomará más memoria y otros recursos, así que el costo no incluye solamente la MMU. Al comparar los precios de procesadores sin MMUs (ej. ARM7, Coldfire, etc.) con 16

21 otros que si disponen de ella (ej. ARM9, algunos ARM7, PowerPC, etc.), se observa que el costo es más elevado en estos últimos. En cuanto al desempeño, una MMU necesita interceptar los accesos a memoria y redirigirlos, esto toma tiempo que degrada el desempeño promedio. En muchos procesadores esta degradación puede estar cubierta por el pipeline, el cacheado y otros pero de nuevo esto añade complejidad y mayor costo. Los beneficios de desempeño de una MMU están más que todo en el desempeño del sistema en lugar del desempeño promedio de la memoria Memorias Un sistema embebido utiliza memoria de dos tipos: RAM y ROM. La RAM será utilizada para que los programas puedan ejecutar sus procesos, intercambio de información con el procesador y más. En el caso del sistema operativo, servirá para todo el manejo de procesos, planificación de procesos, manejo de interrupciones, intercambio de datos, entre otros. La ROM se necesita para poder almacenar el sistema operativo y las aplicaciones que se vayan a implementar. Variantes a esta memoria ROM pueden ser las memorias flash que permiten muchas lecturas y escrituras, memorias CompactFlash, que pueden retirarse o adicionarse fácilmente al sistema, entre otras. El tamaño de dichas memorias depende de la aplicación, del sistema operativo y otros factores del sistema. Una imagen del kernel de µclinux ocupa alrededor de 1 MB, con algunos comandos de shell básicos. Instalar aplicaciones de red, interfaces gráficas y otras, puede llevar a necesitar más de 2 MB de flash, incluso hasta 32 o 64 MB de memoria de programa. La memoria de datos dependerá de cuantas aplicaciones se tengan abiertas al tiempo o de lo complejas que sean. El sistema de evaluación usado en este trabajo contiene 8 MB de RAM y 2 MB de flash Board de Evaluación Un procesador por si solo no puede ser un sistema embebido, ya que este por lo general no contiene memorias de datos y de programa, interfaces de comunicación, controlador de LCD, entre otros. Un microcontrolador incluye muchos de estos módulos, con memorias y más, llevando a que un sistema embebido pueda ser conformado en su totalidad por un microcontrolador y otros elementos secundarios. Los procesadores más recientes o SoCs son muy parecidos a los microcontroladores, ya que a pesar de no contar con memorias de datos y programa contienen una serie de módulos 17

22 como memorias caché, PWM, SPI, SCI, LCD, entre otros que hace que el procesador no necesite de módulos externos para comunicarse con el mundo exterior. Un sistema de desarrollo contiene todo el hardware necesario para la conformación de un sistema embebido. Desde una CPU para el procesamiento de datos, pasando por las memorias, hasta diferentes módulos para generar PWM, comunicación con el mundo exterior y más. Además, muchos sistemas de desarrollo ya son soportados por sistemas operativos como Linux y µclinux, permitiendo que la configuración del sistema operativo sea simple y quede conforme a la configuración del sistema de desarrollo (direcciones de memoria, vectores de interrupción y más). En el capítulo 6 se hará una descripción del sistema de desarrollo utilizado Periféricos Pensando en una aplicación móvil, no basta tener una CPU con memoria e interfaces de comunicación, además de módulos para generación de PWM, A/D entre otros. Es necesario permitirle al usuario poder interactuar con el sistema, para eso se necesita de una pantalla apropiada para visualizar datos, mecanismos para entrada de datos como teclados, mouse, dispositivos señaladores, panel táctil, entre otros. También se debe permitir el almacenamiento de datos de usuario para recuperarlos más adelante o llevarlos a otro sistema como un computador de escritorio COMPONENTES DE SOFTWARE Sistema Operativo El sistema operativo es el software de sistema responsable del control directo, la administración del hardware y las operaciones básicas del sistema, también se encarga de gestionar el software de aplicación tal como programas de procesadores de texto y navegadores de red [2]. En general, el SO es la primera capa de software cargada en la memoria cuando el computador se inicia. Como primera capa, todo el otro software cargado después de este depende del suministro de varios de los servicios de núcleo (core) comunes. Estos servicios comunes incluyen: acceso al disco, administración de memoria, plantación de tareas e interfaz de usuario. Debido a que estos servicios básicos son suministrados por el SO, no hay necesidad de volver a implementar esas mismas funciones en otras partes de software que se puedan usar. En general estas interfaces que 18

23 comunican los programas con el sistema operativo, se denominan APIs (Application Programming Interfaces). El objetivo primario de un Sistema Operativo es optimizar todos los recursos del sistema para soportar los requerimientos de las aplicaciones que se van a ejecutar sobre él [3]. El sistema operativo protege y libera a los programadores de la complejidad del hardware colocándose un nivel de software por sobre el hardware para: Controlar todas las partes del sistema (puertos de E/S, memorias, discos de almacenamiento de información, entre otros) Presentar a los usuarios una interfaz o máquina virtual Las principales características de los SO son: Definir la Interfaz del usuario. Compartir el hardware entre usuarios. Permitir a los usuarios compartir los datos entre ellos. Planificar recursos entre usuarios. Facilitar la entrada / salida. El SO puede ser de tarea única o multitarea. Los de tarea única o primitivos solo pueden ejecutar un proceso a la vez, por ejemplo, si se imprime un documento, habrá que esperar a que este termine para poder ejecutar otro proceso o tarea. Un sistema operativo más moderno tiene la habilidad de ejecutar varios procesos al mismo tiempo. Si se tiene una sola unidad de procesamiento, el SO hace uso de la multitarea por segmentación de tiempo, donde cada aplicación se ejecutará individualmente en un periodo de tiempo. Si el proceso no termina su ejecución en el tiempo asignado, ésta se suspende y se pasa a ejecutar otro proceso. Habrá un momento en que se reanudará el proceso que se había suspendido anteriormente. A este intercambio de procesos se le denomina cambio de contexto. Será el sistema operativo el que se encargue de controlar el estado de los procesos suspendidos. También existe en el SO un elemento crucial para la multitarea llamado planificador, el cual se encarga de cederle la CPU al siguiente proceso que se va a ejecutar de acuerdo a determinada política de planificación. En un sistema embebido, el SO debe estar pensado para manejar dispositivos que están limitados 19