ESCUELA TCNICA SUPERIOR DE INGENIER A DE TELECOMUNICACIN UNIVERSIDAD DE MLAG A

PROYECTO FIN DE CARRERA

HERRAMIENTAS LIBRES PARA LA IMPLEMENTACIN DE SISTEMAS DE CONTROL EN TIEMPO REAL CON MICROCONTROLADORES ARM7

INGENIERA TCNICA DE TELECOMUNICACIN SISTEMAS ELECTRNICOS

MLAGA, 2010

ANTONIO JIMENEZ BELLIDO

ESCUELA TCNICA SUPERIOR DE INGENIER A DE TELECOMUNICACIN UNIVERSIDAD DE MLAG A

Titulacin: Ingeniera Tcnica de Telecomunicacin Sistemas Electrnicos Reunido el tribunal examinador en el da de la fecha, constituido por: D./D. ________________________________________________________ D./D. ________________________________________________________ D./D. ________________________________________________________ para juzgar el Proyecto Fin de Carrera titulado:

HERRAMIENTAS LIBRES PARA LA IMPLEMENTACIN DE SISTEMAS DE CONTROL EN TIEMPO REAL CON MICROCONTROLADORES ARM7
del alumno/a D. Antonio Jimnez Bellido dirigido por D. Jos Manuel Cano Garca

ACORD POR ______________________________________ OTORGAR LA CALIFICACIN DE _______________________________________________ Y, para que conste, se extiende firmada por los componentes del tribunal, la presente diligencia

Mlaga, a ______ de __________________ de _________

El/La Presidente/a

El/La Vocal

El/La Secretario/a

Fdo.: _________________ Fdo.: _________________ Fdo.: _________________

ESCUELA TCNICA SUPERIOR DE INGENIER A DE TELECOMUNICACIN UNIVERSIDAD DE MLAG A

HERRAMIENTAS LIBRES PARA LA IMPLEMENTACIN DE SISTEMAS DE CONTROL EN TIEMPO REAL CON MICROCONTROLADORES ARM7

REALIZADO POR: Antonio Jimnez Bellido DIRIGIDO POR: Jos Manuel Cano Garca

DEPARTAMENTO DE: Tecnologa Electrnica TITULACIN: Ingeniera Tcnica de Telecomunicacin Sistemas Electrnicos PALABRAS CLAVE: Microcontroladores, ARM, Sistemas de control, Hardware in the loop, Sistemas en tiempo real, FreeRTOS.

RESUMEN: En este proyecto se estudia el conjunto de herramientas libres disponibles para el desarrollo de aplicaciones de control en tiempo real para la plataforma ARM7. Este estudio incluye un anlisis de la arquitectura ARM7 y el microcontrolador NXP LPC2148, as como una introduccin al sistema operativo FreeRTOS. Adicionalmente se realizado la implementacin de un autopiloto para un vehculo areo no tripulado y se ha validado mediante pruebas tipo hardware in the loop.

Mlaga, Septiembre de 2010

CONTENIDO

Contenido .......................................................................................................................... I Tabla de acrnimos ........................................................................................................ VII 1 Introduccin ............................................................................................................. 1 1.1 Estado del arte y tendencias .............................................................................. 2 ARM ............................................................................................................ 2

1.1.1 1.2 1.3 2

Objetivos del proyecto ....................................................................................... 4 Organizacin de la memoria .............................................................................. 4

Arquitectura ARM7 ................................................................................................... 7 2.1 2.2 2.3 2.4 2.5 2.6 2.7 Introduccin ....................................................................................................... 7 Introduccin a ARM7 ......................................................................................... 7 Caractersticas ms notables ............................................................................. 8 El pipeline........................................................................................................... 8 Acceso a memoria.............................................................................................. 9 Registros........................................................................................................... 10 Modos de operacin y excepciones ................................................................ 11 Interrupciones software ........................................................................... 14

2.7.1 2.8

Conjuntos de instrucciones.............................................................................. 14 Conjunto de instrucciones ARM ............................................................... 15 Instrucciones de salto ............................................................................... 15 Instrucciones de procesado de datos ....................................................... 16 Instrucciones de transferencia de datos .................................................. 17 Operaciones sobre los registros y los bancos de registros ...................... 18 Conjunto de instrucciones THUMB .......................................................... 18

2.8.1 2.8.2 2.8.3 2.8.4 2.8.5 2.8.6 3

Microcontrolador NXP LPC2148 ............................................................................. 21

3.1 3.2 3.3 3.4 3.5 3.6 3.7 3.8 3.9

Introduccin ..................................................................................................... 21 Memoria Flash integrada ................................................................................. 22 Memoria SRAM integrada ............................................................................... 22 Mapa de memoria............................................................................................ 22 Diagrama de bloques ....................................................................................... 24 Modulo de aceleracin de memoria (MAM) ................................................... 25 Sistema de interrupciones de la familia LPC2000............................................ 26 Gestin de la energa ....................................................................................... 28 Perifricos de usuario ...................................................................................... 28 E/S de propsito general .......................................................................... 29 TimerS ....................................................................................................... 29 UART ......................................................................................................... 31 Convertidor analgico a digital................................................................. 32 Convertidor digital a analgico................................................................. 33 Modulador PWM ...................................................................................... 33 Watchdog timer ........................................................................................ 35 Hardware de debug ...................................................................................... 36 Conclusiones................................................................................................. 36

3.9.1 3.9.2 3.9.3 3.9.4 3.9.5 3.9.6 3.9.7 3.10 3.11 4

Entorno y herramientas de desarrollo ................................................................... 37 4.1 4.2 Introduccin ..................................................................................................... 37 El entorno de desarrollo .................................................................................. 38 Ubuntu Linux ............................................................................................ 38

4.2.1 4.3

Herramientas de desarrollo ............................................................................. 38 CodeSourcery G++ Lite ............................................................................. 38 Eclipse IDE ................................................................................................. 39 OpenOCD .................................................................................................. 39 II

4.3.1 4.3.2 4.3.3

4.3.4 4.3.5 4.3.6 4.4 5

Placa de desarrollo Olimex LPC-P2148 ..................................................... 41 Interfaz JTAG Olimex ARM-USB-OCD ....................................................... 42 High IntegRity Staviewer Pluggin.............................................................. 43

Conclusiones .................................................................................................... 47

Sistemas operativos en tiempo real ....................................................................... 49 5.1 5.2 5.3 5.4 Introduccin ..................................................................................................... 49 Multitarea ........................................................................................................ 49 Multarea y concurrencia .................................................................................. 50 El planificador .................................................................................................. 50 Aplicaciones de tiempo real ..................................................................... 51

5.4.1 6

Free RTOS ............................................................................................................... 55 6.1 Introduccin a FreeRTOS. ................................................................................ 55 Multiprocesamiento en sistemas embebidos pequeos. ........................ 55

6.1.1 6.2

El planificador .................................................................................................. 57 Gestin de procesos ................................................................................. 57 Creacin y destruccin de tareas ............................................................. 61

6.2.1 6.2.2 6.3 6.4 6.5 6.6

Gestin del montculo...................................................................................... 62 Uso de la pila .................................................................................................... 63 Mecanismos de comunicacin entre procesos (IPC) ....................................... 64 Rutinas de interrupcin. .................................................................................. 65 Abstraccin de hardware mediante drivers. ............................................ 67

6.6.1 6.7

Estructura y componentes de un proyecto con FreeRTOS. ............................. 68 Estructura del cdigo fuente de FreeRTOS .............................................. 68 Estructura de un proyecto con FreeRTOS ................................................ 71

6.7.1 6.7.2 6.8

Configuracin y optimizacin. ......................................................................... 73 Macros de traza ........................................................................................ 74 III

6.8.1

6.9 7

Conclusiones .................................................................................................... 75

Ejemplo de sistema de control en tiempo real: autopiloto para UAV ................... 77 7.1 7.2 Introduccin ..................................................................................................... 77 Diseo basado en modelos .............................................................................. 77 Introduccin ............................................................................................. 77 Esbozo sobre estabilidad y control de la aeronave .................................. 79 Estabilidad y control longitudinal ............................................................. 79 Estabilidad y control lateral-direccional ................................................... 80 Esbozo del diseo del controlador del viewer ......................................... 81

7.2.1 7.2.2 7.2.3 7.2.4 7.2.5 7.3

Modelado del sistema de control .................................................................... 82 Modelo de la aeronave............................................................................. 83 Bloque de generacin de referencias (Hight Level) ................................. 87 Controlador de bajo nivel ......................................................................... 96

7.3.1 7.3.2 7.3.3 7.4

Verificacin del diseo mediante pruebas hardware in the loop (HIL) ........ 103 Metodologa empleada .......................................................................... 104

7.4.1

7.5 Implementacin del controlador en un microcontrolador NXP LPC2148 con FreeRTOS .................................................................................................................. 107 7.5.1 7.5.2 7.5.3 7.5.4 7.5.5 7.5.6 7.6 8 9 Arquitectura software ............................................................................ 107 Implementacin de los controladores ................................................... 109 Driver UART ............................................................................................ 116 Comunicaciones con Simulink ................................................................ 117 Configuracin de FreeRTOS .................................................................... 118 Estructura del cdigo fuente .................................................................. 119

Resultados obtenidos .................................................................................... 121

CONCLUSIN ........................................................................................................ 125 Lneas futuras ....................................................................................................... 127

IV

Bibliografa .................................................................................................................... 129 Referencias WEB........................................................................................................... 131 ANEXO A: Familias soportadas por FreeRTOS .............................................................. 133 Anexo B: Cdigo para el clculo de referencias de trayectorias .................................. 135

VI

TABLA DE ACRNIMOS

API: Application programming interface. ARM: Advanced Risc Machines. ASIC: Application specific integrated circuit. ASSP: Application specific standard product. CAN: Controller area network. CPU: Central processing unit. CPSR: Current program status register. CVS: Concurrent versions system. DSP: Digital signal proccesor. FPGA: Field programable gate array. GCC: GNU compiller collection. GNU: GNU is Not Unix. Proyecto de software libre. GPIO: General purpose input/output. HIL: Hardware in the loop. I2C: Inter integrated circuit. I2S: Integrated interchip sound. IRQ:Interrupt request. IP: Iternet protocol. IPC: Inter process comunication ISR: Interrupt service routine MCU: Microcontroller unit MIPS: Million instructions per second. NED: North, East, Down. Sistema de referencia. RTOS: Real time operating system. SIMD: Single instruction multiple data. VII

SOC: System in chip. SPI: Serial port interface. SPSR: Saved program status register. UAV: Unmanned aerial vehicle. USB: Universal serial bus. VIC: Vectorized interrupt controller.

VIII

INTRODUCCIN

Actualmente nos encontramos en un contexto tecnolgico en el que la proliferacin de los sistemas embebidos supone uno de los mercados de ms rpida expansin. La exigencia de los consumidores en cuanto a funcionalidad y prestaciones de los dispositivos electrnicos que usan a diario ha propiciado un gran impulso para el mercado de los microcontroladores. Existen en el mercado multitud de arquitecturas y familias que cubren todo el espectro de aplicaciones, desde pequeos microcontroladores, de coste muy reducido, hasta SOCs (system on chip) con funciones hasta hace poco reservadas a los ordenadores personales. En este contexto, el objetivo del presente trabajo es introducir la arquitectura ARM, una de las ms extendidas en los ltimos aos y de la que existen variantes para todo tipo de aplicaciones, desde pequeos sistemas de control y automatizacin, procesadores de aplicacin, ncleos sintetizables en lgica programable, hasta procesadores multincleo. Dentro de esta arquitectura nos centraremos en la familia ARM7, que representa el segmento medio de la arquitectura. Est formado por microcontroladores RISC de 32 bits, con capacidades de clculo de hasta 130 MIPS, y memorias Flash de hasta 1 Mbyte. Una de las ventajas de esta familia subyace en el hecho de ser una tecnologa licenciada a mltiples fabricantes, por lo que la oferta de dispositivos disponibles es muy amplia. Actualmente ms de cuarenta compaas1 fabrican implementaciones de ARM7, disponindose de dispositivos con todos los perifricos usados en la industria, incluyendo controladores Ethernet, CAN, Flexray, SPI, I2C, I2S, USB, y un largo etctera. Uno de los objetivos de este proyecto es analizar las capacidades de esta familia para la implementacin de sistemas en tiempo real con unos requisitos computacionales medios, como suele ser el caso en muchos sistemas de control. Desarrollaremos como ejemplo la implementacin de un sistema de control a partir de un diseo previo basado en modelos con la herramienta Simulink. As mismo, como objetivo adicional, analizaremos las caractersticas de la familia como plataforma para la docencia, estudiando los entornos de desarrollo y herramientas disponibles, en concreto, configuraremos un entorno de desarrollo basado en aplicaciones libres y gratuitas en entorno Linux.

http://www.arm.com/community/partners/company_list.php 1

1.1 ESTADO DEL ARTE Y TENDENCIAS 1.1.1 ARM

ARM se encuentra entre las empresas lderes de la industria en cuanto a microprocesadores embebidos de 32 bits, representando el 6% del mercado global de microcontroladores, y con una amplia implantacin en algunos segmentos, como el 85% en smartphones, el 90% en cmaras digitales, el 75% en reproductores multimedia, 65% en controladores para discos duros y el 30% en TV digitales2. Hasta la fecha se han fabricado ms de 15000 millones de procesadores ARM, de hecho segn ARM Ltd. en la actualidad se fabrican unos diez millones al da. La siguiente figura recoge las familias de procesadores ARM disponibles actualmente:

Figura 1 Familia de procesadores ARM

En la figura se diferencia tres tipos de procesadores en funcin de tipo de aplicaciones a las que van destinadas.

ARM anual report 2009: http://media.corporateir.net/media_files/IROL/19/197211/ARM_Annual_Report_2009.pdf 2

Los procesadores ARM Cortex-A estn principalmente orientados a su integracin en SOC de alto rendimiento, destinados a dispositivos de comunicaciones y multimedia, como Netbooks, Smartphones, televisiones, routers, telefona IP etc. Dentro de esta familia encontramos: Cortex-A9: con implementaciones multincleo3 entre 800MHz y 2GHz. Cortex-A8: procesadores de un solo ncleo hasta 1GHz. Cortex-A5: procesadores hasta 800MHz para aplicaciones de bajo coste.

Las series Cortex-M y Cortex-R estn destinadas a aplicaciones de tiempo real en las que se necesitan tiempos de ejecucin determinsticos y alto rendimiento. Especialmente la serie Cortex-R cuenta con instrucciones SIMD en punto flotante y versiones con hardware redundante para aplicaciones crticas, como por ejemplo los Texas Instruments TMS570LS con CPU dual sincronizada. Dentro de la familia Cortex-M encontramos los dispositivos: Cortex-M4: orientados sistemas de control y procesado digital de seal para sistemas de bajo consumo energtico. Cortex-M3: orientado a aplicaciones en tiempo real, especialmente sistemas de control y networking. Cortex-M1: es un procesador sintetizable destinado a su implementacin en FPGAs. Cortex-M0: es un procesador bajo costo y alta eficiencia energtica, destinado a aplicaciones de muy bajo coste.

Los procesadores englobados como Classic ARM Processors incluyen las familias ARM11, ARM9 y ARM7, y representan las tecnologas ms maduras. Son procesadores de propsito general y alta eficiencia, especialmente indicados para aplicaciones de bajo coste. Encontramos los siguientes dispositivos: ARM11: procesadores con frecuencias de reloj hasta 1 GHz, de propsito general. Principalmente empleados a aplicaciones en telefona mvil, PDAs, videojuegos. ARM9: procesadores de propsito general con extensiones SIMD y DSP. Es la familia ms popular.

Hasta cuatro ncleos. 3

ARM7: microcontroladores de propsito general y bajo coste. Esta familia est siendo actualmente reemplazada por los nuevos dispositivos Cortex-M3 y Cortex-M0. Sin embargo presenta un elevado nivel de madurez, y las implementaciones disponibles son muy robustas, lo que hace que aun sea la familia de microcontroladores ARM ms extendida, representando el 55% de todos los microcontroladores ARM vendidos en 20094.

1.2 OBJETIVOS DEL PROYECTO

Los objetivos del presente proyecto son: Estudiar las caractersticas de la familia ARM7 y su aplicabilidad en sistemas de control. Analizar las caractersticas y funcionalidad de FreeRTOS como sistema operativo en tiempo real e implementar como caso prctico el controlador de un autopiloto para un UAV. Analizar la viabilidad de la utilizacin de herramientas libres y gratuitas para la configuracin de un entorno de desarrollo verstil y robusto para microcontroladores ARM.

1.3 ORGANIZACIN DE LA MEMORIA

El presente trabajo presenta de manera progresiva los distintos conceptos que finalmente permitirn la implementacin de un sistema de control en tiempo real con FreeRTOS en un microcontrolador basado en una CPU ARM7. El contenido de los captulos que lo componen es el siguiente: En el captulo dos se introducen las caractersticas y arquitectura de la CPU ARM7. En el captulo tres se estudia el microcontrolador NXP LPC2148, basado en dicha CPU. En el captulo cuatro se exponen las distintas herramientas y configuracin de un entorno de desarrollo basado en herramientas libres bajo entorno Linux. En el captulo cinco se introducen algunos aspectos bsicos de los sistemas en tiempo real.

ARM annual report 2009: http://media.corporateir.net/media_files/IROL/19/197211/ARM_Annual_Report_2009.pdf 4

En el captulo seis se estudia FreeRTOS como sistema operativo en tiempo real y se introducen los aspectos fundamentales de su API. En el captulo siete se realiza la implementacin con FreeRTOS en una placa de desarrollo basada en un microcontrolador LPC2148 de un sistema de control existente. Posteriormente a la implementacin, se comparan los resultados obtenidos mediante simulacin en Simulink con los resultados obtenidos en una simulacin tipo hardware in the loop, en la que el algoritmo de control se ejecuta en el hardware real.

ARQUITECTURA ARM7

2.1 INTRODUCCIN

Como se ha comentado anteriormente, poder contar con una plataforma ampliamente extendida presenta evidentes ventajas en muchos aspectos. Por esa razn se ha elegido la familia ARM7 como objeto de estudio. Representa una tecnologa madura, con herramientas de desarrollo libres y muy depuradas, proporcionando a la vez una elevada flexibilidad y rendimiento con unos costes, tanto de las herramientas como de los dispositivos, muy bajos. En el desarrollo de este proyecto utilizaremos un microcontrolador NXP LPC2148. Para poder afrontar un desarrollo con el mismo, estudiaremos los aspectos generales de la familia ARM7, y posteriormente nos centraremos en las caractersticas concretas del LPC2148.

2.2 INTRODUCCIN A ARM7

La familia ARM7 est compuesta por un conjunto de ncleos RISC de 32 bits basados en las arquitecturas ARMv4T y ARMv5TEJ, optimizados para mantener unos requerimientos de consumo bajos y coste reducido. La idea clave en la que se basa la familia es la simplicidad del diseo. El ncleo RISC tiene un conjunto de instrucciones muy reducido y consecuentemente tambin un nmero de puertas bajo, esto permite un rendimiento alto consumiendo poca rea de silicio. Esto lo hace muy adecuado para sistemas embebidos en los cuales el coste y el consumo energtico sean aspectos fundamentales en el diseo. La familia est compuesta por varios ncleos, ofreciendo una potencia de clculo de hasta 130 MIPS5 : ARM7TDMI (ARMv4T): es el ncleo ms bsico. Dispone de una ALU entera y pipeline de tres etapas. ARM7TDMI-S (ARMv4T): es una versin sintetizable del ARM7TDMI. ARM7EJ-S (ARMv5TEJ): es una versin sintetizable mejorada con una unidad de procesamiento DSP y una unidad de aceleracin de ejecucin de aplicaciones Java (ARM Jazelle DBX technology).

5,2

Fuente ARM. www.arm.com 7

ARM720T (ARMv4T): es una versin que incorpora un controlador de memoria (MMU) y una cache de 8 KB, lo que le permite conectarle una memoria RAM externa y ejecutar sistemas operativos con requerimientos elevados de memoria como Windows CE, Linux, Symbian OS, Palm OS. Actualmente ms de cuarenta compaas2 ofrecen microprocesadores, microcontroladores, SOCs, ASICs, y ASSPs basados en ARM7, y sus aplicaciones cubren desde cmaras de fotografa digital a sistemas de videojuegos. En adelante nos centraremos en el estudio del ncleo ARM7TDMI, por ser esta implementacin la ms extendida.

2.3 CARACTERSTICAS MS NOTABLES

Una de las caractersticas ms notable de la familia ARM es la implementacin de dos conjuntos de instrucciones, uno de 32 bits denominado ARM y otro de 16 bits denominado THUMB. Este conjunto de instrucciones de 16 bit permite doblar la densidad de cdigo, y al ser posible cambiar de modo dinmicamente en tiempo de ejecucin, puntualmente podemos operar con el conjunto de instrucciones ARM en caso de ser necesario. Tambin es destacable que todas las instrucciones son de ejecucin condicionada, esto es as para tratar de obtener un mejor aprovechamiento del pipeline. Profundizaremos en esta caracterstica ms adelante.
2.4 EL PIPELINE

El ARM7TDMI-S utiliza un pipeline de tres etapas. Este es el tipo de pipeline ms simple posible y no tiene los riesgos de pipelines de ms largos, como de lectura antes de escritura. Cada una de las etapas del pipeline es ejecutada por un hardware independiente, lo que permite ejecutar una instruccin mientras se decodifica una segunda y se carga una tercera, de esta forma la mayor parte de las instrucciones se ejecutan en un nico ciclo de reloj.

Modo Modo 1 ARM THUMB CARGA PC PC PC-2 PC-4 -

DECODIFICACIN PC-4 EJECUCIN PC-8

Figura 2 Diagrama de carga del pipeline

Etapa de carga: la instruccin es cargada de la memoria. Etapa de decodificacin: la instruccin es decodificada. Etapa de ejecucin: los registros son ledos del banco de registros. Se ejecutan las operaciones de la ALU y del registro de desplazamiento y los registros son escritos con los resultados.

Es importante tener presente que en modo ARM el PC va adelantado ocho bytes con respecto a la instruccin en ejecucin, y en modo THUMB va adelantado cuatro bytes. Como es usual, el pipeline es ms efectivo con cdigo lineal, ya que en caso de que se produzca un salto, todo el pipeline es vaciado y es necesario que se vuelva a cargar completamente antes de recuperar la mxima eficiencia en velocidad de ejecucin. Como veremos ms adelante, el conjunto de instrucciones ARM posee algunas caractersticas que nos permitirn optimizar el uso del pipeline para saltos pequeos.

2.5 ACCESO A MEMORIA

El ncleo ARM7TDMI tiene una arquitectura tipo Von Neumann, con un bus de datos de 32 bits, en la que las direcciones de memoria son lineales y numeradas ascendentemente desde cero. El ncleo puede configurarse para trabajar en formatos Big-endian o Little-endian indistintamente. Los datos pueden ser: 8 bit (byte) 16 bits (half word) 32 bits (word) 9

La alineacin de datos debe ser de 4 bytes para los words, de 2 bytes para half Word, y de un byte para byte.
2.6 REGISTROS

El ARM7 posee una arquitectura de tipo carga y almacena (load-and-store), por tanto, cualquier instruccin que procese datos necesita que estos se copien primero en un conjunto de registros. Tras ejecutarse la operacin, los resultados se guardan en memoria. El banco de registros de datos lo componen diecisis registros (R0-R15) de 32 bits, de los cuales: R0-R12 son de propsito general. R13 es usado como puntero de pila. R14, registro de enlace (Link Register). Cuando se llama a una funcin, la direccin de retorno se almacena en este registro. Esto permite la entrada y salida rpida en funciones que no llamen a ninguna otra funcin (a leaf function). En otro caso el registro de enlace debe ser almacenado en la pila. R15, es contador de programa.

Curiosamente, algunas instrucciones pueden utilizar los registros R13-R15 como registros de propsito general. El registro de estado CPSR (Current Program Status Register) es otro registro de 32bits que contiene flags que indican es estado de la CPU.
31 30 29 28 27 N Z C V 8 7 6 5 4 3 2 1 0 I F T M4 M3 M2 M1 M0
Tabla 1 Registro de estado

Los cuatro bits de ms peso son manejados directamente por la CPU e indican las condiciones de estado de los resultados de las operaciones de procesamiento de datos. Los ocho bits de menos peso pueden ser controlados desde la aplicacin. Los flags `F e `I sirven para habilitar las dos fuentes de interrupcin externas a la CPU. Como veremos en el captulo siguiente, todos los perifricos del LPC2148 estn conectados a estas dos lneas mediante un controlador de interrupciones vectorizadas. El flag `T sirve para controlar que conjunto de instrucciones se est ejecutando. Como se ha comentado anteriormente, el ARM7 es capaz de ejecutar dos conjuntos de instrucciones, denominados ARM y THUMB y de 32 y 16 bits respectivamente. Ms 10

adelante se ver que para cambiar de modo de ejecucin, el procedimiento adecuado no es manipular directamente este bit, si no ejecutar una instruccin de salto con cambio (BX, BLX) al cdigo THUMB. Los cuatro bits de menos peso indican el modo de operacin de la CPU. En el siguiente punto veremos los distintos modos en los que puede operar la CPU ARM7.

2.7 MODOS DE OPERACIN Y EXCEPCIONES

En este punto veremos los distintos modos de operacin de la CPU ARM7 y sus principales aplicaciones. Tambin introduciremos el manejo de excepciones y su relacin con los modos de operacin de la CPU. Los modos de operacin se dividen en dos categoras: privilegiados y no privilegiados. Los modos privilegiados se utilizan para prestar servicio a interrupciones, excepciones y para acceder a recursos protegidos. Segn el modo de operacin tendremos acceso a un conjunto de registros especfico. En la siguiente tabla se muestran los registros asociados a cada modo de operacin:
System & User R0 R1 R2 R3 R4 R5 R6 R7 R8 R9 R10 R11 R12 R13 R14 R15(PC) CPSR FIQ R0 R1 R2 R3 R4 R5 R6 R7_fiq R8_fiq R9_fiq R10_fiq R11_fiq R12_fiq R13_fiq R14_fiq R15(PC) CPSR SPSR_fic Supervisor R0 R1 R2 R3 R4 R5 R6 R7 R8 R9 R10 R11 R12 R13_svc R14_svc R15(PC) CPSR SPSR_svc Abort R0 R1 R2 R3 R4 R5 R6 R7 R8 R9 R10 R11 R12 R13_abt R14_abt R15(PC) CPSR SPSR_abt IRQ R0 R1 R2 R3 R4 R5 R6 R7 R8 R9 R10 R11 R12 R13_irq R14_irq R15(PC) CPSR SPSR_irq Undefined R0 R1 R2 R3 R4 R5 R6 R7 R8 R9 R10 R11 R12 R13_und R14_und R15(PC) CPSR SPSR_und

Tabla 2 Bancos de registros

11

Usualmente, al producirse una excepcin es necesario guardar el contexto de ejecucin de la aplicacin, formado por el conjunto de registros, para poder restaurarlo una vez concluido el tratamiento de la excepcin. Para facilitar y acelerar este proceso, en los modos Supervisor, Abort, IRQ y Undefined, los registros R13 y R14 son reemplazados por un nuevo par de registros propios para modo, de esta forma podemos tener unos punteros de pila y de enlace especficos para este modo. Tambin tenemos acceso a un registro adicional llamado SPSR (saved program status register), en el que en el momento de la ocurrencia de la interrupcin se copia el contenido del CPSR, una vez atendida la excepcin, al volver al modo usuario el CPSR es restaurado con los contenidos del SPSR. El modo FIQ adicionalmente proporciona un conjunto registros propios que sustituyen a R7-R12, de forma que no es necesario copiar el banco de registros en la pila, lo que permite reducir el tiempo de repuesta ante una interrupcin.

Las funciones de los modos de excepcin son las siguientes: User (modo usuario): es el nico modo no privilegiado. Este modo el estado de ejecucin usual, en el que se ejecutan normalmente las aplicaciones. En este modo tenemos acceso a los registros R0-R15 y al registro de estado CPSR. Supervisor: es un estado protegido, normalmente usado por los sistemas operativos. La CPU se inicia siempre en este modo despus de un reset. Tambin se puede cambiar a este modo mediante una SWI (interrupcin software). System: es un estado protegido, normalmente usado por los sistemas operativos. A este estado solo se puede acceder desde otro modo privilegiado. Interrupt (IRQ): este modo protegido se utiliza para el manejo de interrupciones. La CPU cambia a este modo ante la ocurrencia de una interrupcin. Fast interrupt (FIQ): este modo protegido puede usarse para efectuar una respuesta rpida ante una interrupcin. Veremos su funcionamiento ms adelante. . La CPU cambia a este modo ante la ocurrencia de una interrupcin. Ms adelante veremos cmo podemos mapear las fuentes de interrupcin a los vectores FIQ o IRQ. Abort mode: la CPU pasa a este modo cuando ocurren un error de datos o de precarga de instruccin. Undefined mode: la CPU pasa a este modo cuando se intenta ejecutar una instruccin no definida.

Como hemos comentado anteriormente, cuando se produce una excepcin, la CPU cambiar de modo de operacin. 12

Las siguientes tablas muestran los vectores asociados a cada modo de operacin y el orden de prioridad de las excepciones.
Excepcin Reset Instruccin no definida Interrupcin software (SWI) Aborto de precarga Aborto de datos IRQ(interrupcin) FIQ(interrupcin rpida) Modo Supervisor Undefined Supervisor Abort Abort IRQ FIQ
Tabla 3 Vectores de interrupcin

Direccin del vector 0x00000000 0x00000004 0x00000008 0x0000000C 0x00000010 0x00000018 0x0000001C

Prioridad 1 (La ms alta) 2 3 4 5 6 (La menor)

Excepcin Reset Data abort FIQ IRQ Prefetch abort Undefined instruccin / SWI
Tabla 4 Prioridades de las interrupciones

Ante una excepcin ocurre lo siguiente: -La direccin de la siguiente instruccin a ejecutar (PC +4 en modo ARM) se guarda en el registro de enlace -El CPSR se copia al SPSR correspondiente a la excepcin producida. -El PC se carga con la direccin del vector de interrupcin correspondiente. Simultneamente se cambia de modo, reemplazndose los registros R13 y R14 por los correspondientes. Al entrar en un modo de excepcin el flag I del CPSR es activado, deshabilitando as las interrupciones. Si necesitamos poder atender interrupciones anidadas, debemos desactivar el flag I manualmente para habilitar las interrupciones y meter el contenido del LR en la pila. Lo primero que deber hacer nuestra rutina de tratamiento de interrupcin ser guardar el contenido de los registros R0-R12 (R0-R7 en el caso del modo FIQ) para poder restablecerlos inmediatamente antes de salir de la RTI. La CPU ARM7 facilita esta tarea mediante las instrucciones STM y LDM, que permiten copiar el banco de registros completo, o un subconjunto de l a memoria y viceversa mediante una nica instruccin. 13

Una particularidad de la familia ARM es que no existe una instruccin especfica para salir de una interrupcin; para salir de la excepcin es suficiente con copiar el contenido del LR al PC mediante una variante especfica de la instruccin MOV: MOVS R15, R14; Mueve el contenido del LR al PC y cambia de modo

En caso de pasar a modo FIQ o IRQ, la instruccin que se est ejecutando en ese momento es abortada y descartada, as que en estos casos hay que tener en cuenta que la direccin almacenada en el LR es la de la instruccin descartada mas cuatro (en modo ARM), as que al salir de la RTI tendremos que asegurarnos de cargar en el PC la direccin adecuada (LR-4 en modo ARM). Esto podemos hacerlo con una solo instruccin variacin de la instruccin SUB especfica para este propsito: SUBS R15, R14, #4 En el caso de pasar a modo data abort, la excepcin ocurrir una instruccin despus de la ejecucin de la instruccin que causo la excepcin. En este caso, supuestamente, nuestra RTI solucionar el problema que causo la interrupcin, y al salir lo que pretendemos es volver a ejecutarla. En este caso tendremos que mover hacia atrs el PC dos instrucciones. Adicionalmente al ejecutar MOVS o SUBS la CPU cambiar a modo usuario y restaurar el contenido del CSPR.
2.7.1 INTERRUPCIONES SOFTWARE

Hay disponible una instruccin capaz de generar una excepcin, forzando un cambio a modo supervisor y provocando un salto al vector de interrupcin correspondiente. Al igual que todas las instrucciones ARM, la ejecucin de esta instruccin es condicional. Los 23 bits de menor peso pueden usarse para almacenar un valor que puede pasarse como parmetro.
31 Condicin 28 1111 27 Valor 24 23

Tabla 5 Parmetro de interrupcin software

2.8 CONJUNTOS DE INSTRUCCIONES

Como se ha comentado anteriormente, el ARM7 posee dos conjuntos de instrucciones, el conjunto ARM, de instrucciones de 32 bits, y el conjunto THUMB, de instrucciones de 16 bits. Para evitar confusiones, en adelante nos referiremos a la CPU como ARM7, y al conjunto de instrucciones como ARM.

14

2.8.1 CONJUNTO DE INSTRUCCIONES ARM

Una de las caractersticas ms interesantes del conjunto de instrucciones ARM es que todas las instrucciones son ejecutadas condicionalmente dependiendo del resultado de la anterior. Los cuatro bits de ms peso del cdigo de operacin son comparados con los bits de estado del CPSR. Para que la instruccin se ejecute deben coincidir, en otro caso la instruccin es ejecutada como NOP. Podemos controlar la ejecucin condicional de cualquier instruccin aadiendo los siguientes prefijos:
Prefijo EQ NE PL MI HI CS CC LS GE LT GT LE VS VC AL Flags comparados Z=1 Z=0 N=0 N=1 C=1yZ=0 C=1 C=0 C=0yZ=1 N=V N != V Z=0yN=V Z = 1 y N!=V V=1 V=0 Todos ignorados Significado Igual Distinto Positivo o cero Negativo Mayor (sin signo) Mayor o Igual (sin signo) Menor (sin signo) Menor o Igual (sin signo) Mayor o igual Menor Mayor Menor o igual Overflow No overflow Ejecutar siempre

Tabla 6 Prefijos de ejecucin condicional

Esta caracterstica permite una implementacin muy eficiente de de cdigo con pequeos saltos.
2.8.2 INSTRUCCIONES DE SALTO

Instrucciones de Salto B BL BX BLX

Salto Salto con enlace Salto con cambio Salto con enlace y cambio
Tabla 7 Instrucciones de salto

La instruccin bsica de salto B permite saltos de hasta 32MB. La versin modificada BL, adicionalmente almacena la direccin de la siguiente instruccin a ejecutar (PC+4) en el registro de enlace. 15

Las instrucciones BX y BLX adems cambian modo de ejecucin de AMR a THUMB y viceversa. Este es el nico mtodo que debemos usar para cambiar el modo de ejecucin, nunca tratemos de modificar directamente el flag T del CPSR. Agregando los prefijos de ejecucin condicional podemos codificar saltos condicionales y llamadas condicionales a funciones en una sola instruccin.

2.8.3 INSTRUCCIONES DE PROCESADO DE DATOS

Instrucciones de procesado de datos AND EOR SUB RSB ADD ADC SBC RSC TST TEQ CMP CMN ORR MOV BIC MVN

AND lgico XOR lgico Resta Resta inversa Suma Suma con acarreo Resta con acarreo Resta inversa con acarreo Test Comprueba igualdad Comparacin Comparacin inversa OR lgico Mover Limpiar bit Mover inversa

Tabla 8 Instrucciones de procesado de datos

Las instrucciones de procesado de datos permiten, al igual que todas las dems, su ejecucin condicional, adems permiten realizar un desplazamiento lgico de hasta 32 bits al segundo operando, todo en un nico ciclo. El formato es el siguiente:
Prefijo de ejecucin condicional COND Cdigo de operacin Flag para habilitar los cdigos de condicin S Operandos Desplazamiento

OP

R1,R2,R3

xx

Tabla 9 Formato de las instrucciones de procesado de datos

16

Estas caractersticas bien aprovechadas (ms bien con un buen compilador) permiten ejecutar muy eficientemente ciertas operaciones, por ejemplo: if(Z==1) { R1 = R2+(R3*8); } Adicionalmente la CPU dispone de una unidad MAC (multipy accumulate unit), que permite la multiplicacin de enteros de 16 y 32 bits con acumulacin.
Instrucciones de la unidad MAC MUL MULA UMULL UMLAL SMULL SMLAL Multiplicacin, operandos de 16 bit Multiplicacin y acumulacin, operandos de 16 bit Multiplicacin sin signo, operandos de 32 bit Multiplicacin y acumulacin sin signo, operandos de 32 bit Multiplicacin con signo, operandos de 32 bit Multiplicacin y acumulacin con signo, operandos de 32 bit
Tabla 10 Instrucciones de la unidad MAC

2.8.4 INSTRUCCIONES DE TRANSFERENCIA DE DATOS

La CPU ARM7 posee un conjunto de instrucciones para copiar distintos tipos de datos desde memoria hacia los registros e inversamente desde los registros hacia la memoria.
Instrucciones de transferencia de datos LDR LDRH LDRSH LDRB LDRSB STR STRH SRHSH STRB STRSB Load Word Load half Word Load signed half Word Load byte Load signed byte Store Word Store half Word Store signed half Word Store byte Store signed half byte

Tabla 11 Instrucciones de transferencia de datos

17

2.8.5 OPERACIONES SOBRE LOS REGISTROS Y LOS BANCOS DE REGISTROS

El ncleo ARM posee dos instrucciones capaces de cargar o guardar el banco de registros completo con una sola instruccin.
Carga y almacenamiento del banco de registros STM Guarda el banco de registro en la memoria a partir de la direccin base indicada LDM Carga el contenido de la memoria desde la direccin base indicada en el banco de registros.
Tabla 12 Operaciones sobre los bancos de registros

Adicionalmente, la CPU posee una instruccin atmica que permite intercambiar el valor de dos registros. Esto permite la implementacin eficiente de semforos. Mediante la operacin SWP es posible intercambiar el valor de dos registros de forma atmica, por lo que est operacin est protegida frete a interrupciones.
2.8.5.1 MODIFICACIN DEL REGISTRO DE ESTADO (CPSR)

Como se ha indicado en la seccin Registros, los registros CPSR y SPSR no forman parte del banco de registros. Mediante las funciones MSR y MRS podemos copiar el contenido de estos registros a cualquier registro del banco de registros y viceversa. Hay que notar que estas funciones no estn disponibles en el modo usuario, por lo que slo son accesibles desde los modos privilegiados, esto implica que el modo USER no puede abandonarse salvo a travs de la ocurrencia de una excepcin.
2.8.6 CONJUNTO DE INSTRUCCIONES THUMB

Tal y como se ha comentado anteriormente, la CPU ARM7 posee un modo de ejecucin alternativo que permite la ejecucin de un conjunto de instrucciones de 16 bits. El propsito de este modo de ejecucin y este conjunto de instrucciones, es poder obtener una mayor densidad de cdigo. La utilizacin del modo THUMB debe ser analizada por el desarrollador, ya que aunque permite un ahorro de espacio del 30%, el cdigo en modo ARM es un 40% ms rpido, especialmente en algoritmos de clculo matemtico. Por esta prdida de rendimiento, en general, la utilizacin de este modo no es apropiada para su uso en sistemas de control, por lo que slo haremos una breve introduccin de sus caractersticas ms relevantes. El conjunto de instrucciones THUMB nicamente puede establecerse desde el modo usuario, modificndose el modo de ejecucin a ARM al cambiar la CPU a cualquiera de los modos privilegiados. El cambio a modo THUMB se efecta mediante las

18

instrucciones BX o BXL, que efectan un salto de memoria y un cambio de modo de ejecucin. Este conjunto de instrucciones THUMB carece de algunas caractersticas del conjunto ARM, como es la ejecucin condicional de todas las instrucciones. Tambin se ve reducido el nmero de operandos de las instrucciones, que se ve reducido a dos. Aunque desde este modo tenemos acceso al banco de registros del modo usuario, slo podemos operar con los registros R0 a R7, y con algunas instrucciones al resto de registros. As mismo, carece de instrucciones para modificar directamente los registros CPSR y SPSR, por lo que si se necesita modificar explcitamente uno de estos registros, ser necesario cambiar a modo ARM.

19

20

MICROCONTROLADOR NXP LPC2148

3.1 INTRODUCCIN

Como se comento en la introduccin, nos centraremos en el estudio de este microcontrolador a lo largo del presente trabajo. En esta seccin se mostrarn los datos y caractersticas ms relevantes del LPC2148, para ms detalles podemos consultar el datasheet del dispositivo. Las caractersticas tcnicas de este dispositivo son las siguientes: Microcontrolador ARM7TDMI-S. Encapsulado LQFP64. Entradas y salidas tolerantes a 5V. Frecuencia de reloj mxima de 60 MHz Oscilador integrado con capacidad de operar desde 1 a 30 MHz Diversos modos de bajo consumo, incluyendo habilitacin de los relojes de cada perifrico. 40 KB de memoria SRAM, 512 KB de memoria flash integrada. Macroclula EmbeddedICE RT y Embedded Trace para depuracin en tiempo real integrada. Controlador USB 2.0 Full Speed con 2kB de memoria SRAM dedicada y 8 KB adicionales accesible mediante DMA. Dos conversares A/D de 10 bits, multiplexados desde 14 entradas analgicas. Un conversor D/A. Dos timers con cuatro mdulos de captura y otros cuatro de comparacin cada uno. Reloj de tiempo real con oscilador dedicado. Dos UARTS tipo 16C550 Dos controladores I2C de 400 kbits/s Controlador SPI Controlador SSP Controlador de interrupciones vectorizadas. Nueve entradas de interrupcin externas.

Las aplicaciones tpicas de este microcontrolador son: Control industrial Gateway de comunicaciones Sistemas de control de accesos Sistemas mdicos. Sistemas de propsito general 21

3.2 MEMORIA FLASH INTEGRADA

El LPC2148 integra 512 KB de memoria Flash. Esta memoria puede ser usada indistintamente para almacenamiento de cdigo y datos. La memoria puede escribirse mediante el la interfaz JTAG integrada o a travs de la UART0 mediante la funcionalidad In System Programing, o desde una aplicacin en ejecucin, por ejemplo, un boot loader. Esta memoria proporciona un mnimo de cien mil ciclos de borrado/escritura, y un retencin de datos de veinte aos.
3.3 MEMORIA SRAM INTEGRADA

El LPC2148 proporciona 32 KB de SRAM, que puede ser accedida como datos de 8, 16 y 32 bits. La memoria est diseada para ser accedida como memoria direccionada en bytes. Los accesos a datos de media palabra y una palabra se hacen a las direcciones alineadas, en concreto, para las medias palabras se ignora el bit 0 de la direccin, y para palabras completas se ignoran los bits 0 y 1.
3.4 MAPA DE MEMORIA

Independiente del nmero de buses presentes en el LPC2148, este microcontrolador posee un mapa de memoria completamente lineal, tal y como se puede apreciar en la siguiente figura:

22

Figura 3 Mapa de memoria del LPC 2148

Como se puede observar, la memoria Flash integrada se encuentra ubicada a partir de la direccin 0x00000000, y la memoria SRAM se encuentra ubicada a partir de la direccin 0x40000000. El microcontrolador cuenta con un software de depuracin (ARM real monitor) y otro carga (Flash boot loader), preprogramados de fbrica en el rango 0x7FFFFFFF a 0x80000000. Los perifricos conectados al bus VPB estn mapeados en el intervalo de direcciones 0xE0000000 a 0xE0200000. Dentro de este rango, para cada perifrico se reserva un espacio de 16K. La unidad de control de interrupciones vectorizadas se encuentra a partir de la direccin 0xFFFFF000. Adicionalmente, la regin comprendida entre 0x8000000 y 0xE000000 est reservada en todos los dispositivos de la familia LPC2xxx para memoria externa. Aunque el

23

LPC2148 no cuenta con un bus de memoria externa, otros dispositivos de la familia, como los LPC22xx, si cuentan con dicho bus.
3.5 DIAGRAMA DE BLOQUES

Aunque para el programador, todos los perifricos estn en un rango continuo de 32 bits, internamente el dispositivo est compuesto por un conjunto de buses, tal como puede apreciarse en el siguiente diagrama de bloques del dispositivo.

Figura 4 Diagrama de bloques del LPC2148

24

El ncleo ARM7 est conectado al bus AHB6. A este bus est conectado el controlador de interrupciones y un puente al bus VPB7. El resto de perifricos est conectado directamente al bus VPB. Este bus VPB posee un divisor de reloj de forma que puede funciona a una velocidad inferior a la del ncleo, esto permite por un lado establecer mecanismos de ahorro de energa, y por otro, poder conectar perifricos lentos sin que suponga un cuello de botella para el bus AHB. Para conectar la CPU a la memoria Flash y SRAM existe un tercer bus dedicado.
3.6 MODULO DE ACELERACIN DE MEMORIA (MAM)

Este mdulo es fundamental para conseguir una elevada velocidad de ejecucin, ya que la memoria Flash es ms lenta que la CPU, con un tiempo de acceso de 50ns, lo que limitara la velocidad de ejecucin a 20MHz. Para acelerar la ejecucin, la memoria Flash est dividida en dos bancos con una anchura palabra de 128 bits cada uno, accesibles de forma independiente, esto permite cargar cuatro instrucciones ARM u ocho instrucciones THUMB en una sola operacin. Estos bancos estn entrelazados de forma que mientras se ejecuta el cdigo cargado desde un banco, se efecta la carga del siguiente. Este mtodo funciona muy bien con las instrucciones ARM, que permiten suavizar pequeos saltos mediante los cdigos de condicin vistos en el captulo anterior. Adicionalmente, el mdulo MAM cuenta con buffers para los saltos y bucles, de forma que no tengan que efectuarse operaciones de carga para instrucciones ejecutadas recientemente. El mdulo MAM se programa mediante dos registros: el registro de temporizacin (timing register), y el registro de control (control register). Mediante el registro de temporizacin podemos establecer la relacin entre el reloj de la CPU y el tiempo de acceso a flash, en el podemos fijar el nmeros de ciclos de reloj necesarios para acceder a la Flash. Como nuestra CPU trabaja a 60 MHz, y la frecuencia mxima de acceso a la Flash es de 20Mhz, el numero de ciclos de reloj requeridos ser de tres, de forma que por cada tres ciclos de reloj podemos cargar cuatro instrucciones, con lo que el MAM siempre tendr instrucciones disponibles para la ejecucin.

6 7

Advanced High performance Bus, definido por ARM. VLSI Peripheral Bus. 25

El registro de configuracin del MAM sirve para establecer el modo de operacin del mdulo. Hay tres modos posibles:

Figura 5 Modos de operacin del MAM

Despus de un reset, el MAM est deshabilitado, y todos los accesos sern directos a Flash. Tambin es posible habilitar solo parcialmente el MAM, pero haciendo que los saltos y los accesos a datos en Flash se hagan directamente. Finalmente, podemos habilitar completamente el MAM, de forma que todos los accesos a Flash se hagan a travs del MAM. La razn de estos es poder permitir un modo de ejecucin perfectamente determinista, ya que el uso del MAM implica tiempos de ejecucin no determinsticos. En cualquier caso, es posible mediante herramientas de depuracin, determinar el tiempo de ejecucin del cdigo. El MAM cuenta con una serie de registros que recogen estadsticas sobre los accesos a Flash y a los bferes del MAM. Estas medidas nos proporcionan informacin sobre la eficacia del MAM en nuestra aplicacin. En este punto, es importante observar que s es posible obtener una ejecucin determinstica a la mxima velocidad de CPU si cargamos el cdigo de programa en memoria SRAM, con el inconveniente de que la cantidad de esta es ms limitada que de Flash.
3.7 SISTEMA DE INTERRUPCIONES DE LA FAMILIA LPC2000

En este punto trataremos el hardware implicado en el manejo de interrupciones externas a la CPU ARM7, englobando tanto los perifricos integrados en el LPC2148 como las fuentes de interrupcin externas. La CPU ARM7 posee dos lneas para interrupciones externas, una para interrupciones rpidas (FIQ), y otra para interrupciones generales (IRQ). Para poder conectar mltiples perifricos a estas dos nicas lneas, el LPC2148 (y toda la familia LPC2000) integra un modulo controlador de interrupciones vectorial (VIC). 26

Figura 6 Controlador de interrupciones

El VIC permite conectar todas las fuentes de interrupcin a la CPU de tres formas: como interrupcin FIQ, como interrupcin IRQ vectorizada, y como interrupcin IRQ no vectorizada. Como se ha comentado, cualquier fuente de interrupcin puede asignarse como FIQ, aunque hay que tener en cuenta que es conveniente no tener ms de una interrupcin de este tipo, ya que en ese caso tendramos que inspeccionar cual es la fuente de la interrupcin, lo que aumentara el tiempo de atencin a la misma. Ante la ocurrencia de una interrupcin FIQ, el procesador cambiar a modo FIQ y saltar al vector FIQ. A diferencia que las interrupciones FIQ, las interrupciones IRQ pueden vectorizarse. El VIC tiene una tabla con 16 slots para los vectores, cada slot se compone de un registro de direccin y un registro de control, mediante el cual podemos asignar el vector a una fuente de interrupcin. Cuando se genere una interrupcin, el VIC cargara la direccin correspondiente a esa fuente de interrupcin en el registro de vector de direccin (Vector Address Register), simultneamente la CPU pasar a modo IRQ y saltar al vector de interrupcin IRQ, en el cual se deber cargar el valor del VIC en el PC para entrar en el cdigo de tratamiento de interrupcin correspondiente. Como hemos comentado anteriormente, el VIC es capaz de gestionar hasta 16 fuentes de interrupcin como interrupciones vectorizadas y al menos una como interrupcin FIQ. Si tuvisemos ms de 17 fuentes de interrupcin, podramos tratar el resto como interrupciones no vectorizadas. En este caso se saltar a un vector de interrupcin por defecto en el que se deber comprobar cul es la fuente de interrupcin y ejecutar el cdigo adecuado.

27

3.8 GESTIN DE LA ENERGA

El LPC2148 provee varios mecanismos de ahorro energtico. Mediante un uso adecuado del divisor del VPB podemos reducir el consumo de energa global del microcontrolador. Adicionalmente, el LPC2148 posee algunas caractersticas de ahorro energtico adicionales. La CPU ARM7 tiene dos modos de apagado que pueden controlarse desde el registro PCON. As, podemos detener la CPU completamente pero dejar los perifricos funcionando normalmente, de forma que cuando se produzca una interrupcin la CPU se active. El otro modo de apagado detiene tanto la CPU como los perifricos. En este modo la ejecucin solo podr ser reanudada mediante una fuente de interrupcin externa. Adicionalmente es posible controlar cada perifrico integrado individualmente, de forma que solo estn en funcionamiento los necesarios para la aplicacin. Hay que tener en cuenta que no es posible depurar el dispositivo cuando entra en algn modo de ahorro de energa.

3.9 PERIFRICOS DE USUARIO

En las prximas secciones comentaremos los perifricos de usuario de uso ms comn presentes en el LPC2148. Como se ha comentado anteriormente, el objeto de este documento no es sustituir al manual de usuario del LPC2148, por lo que solo se introducirn los aspectos fundamentales de algunos de los perifricos del microcontrolador. Antes de abordar los distintos perifricos, hay que tener muy en cuenta que en el LPC2148 todos los pines de E/S pueden estar conectados internamente mediante un bloque multiplexor a varios perifricos. Este bloque multiplexor, llamado pin select block permite configurar un pin del dispositivo como GPIO o rutearlo a uno de otros tres perifricos, por lo que puede darse la situacin de que no puedan usarse dos perifricos simultneamente. Esta configuracin se hace mediante los registros PINSELn.

28

Figura 7 Pin select block

3.9.1 E/S DE PROPSITO GENERAL

Despus de un reset, el pin connect block configura todos los pines del LPC2148 como entradas de propsito general (GPIO). Podemos acceder a los puerto de E/S de propsito general del LPC2148 a travs de un conjunto de registros conectados directamente al bus local de la CPU, por lo que es posible manipularlos a la velocidad de la CPU. Es posible controlar la direccin de cada bit de los puertos. La lectura de los puertos, independientemente del estado, se hace a travs de los registros IOPIN. La escritura se hace a travs de los registros IOSET y IOCLR, y la configuracin como entrada o salida se hace en los registros IODIR.
3.9.2 TIMERS

El LPC2148 incluye dos timers de 32 bit. Estos timers son idnticos, y pueden funcionar como timers o como con contadores. Cada timer cuenta ciclos del reloj PCLK del bus VLSI (funcionando como timer) o de un reloj externo (funcionando como contador) tras dividirlo mediante un divisor programable de 32 bits (PC, prescale counter).

29

Figura 8 Diagrama de bloques de los timers.

El valor del PC se incrementar con cada ciclo de PCLK hasta alcanzar el valor almacenado en el registro de pre escalado PR, en ese momento el valor del contador se incrementar y el PC se resetear a cero. Cada timer cuenta con cuatro registros de captura (CR), en los cuales podemos almacenar al valor del timer ante la ocurrencia de una transicin en una seal de entrada externa. Esto puede ser til por ejemplo para demodular seales PWM, medir frecuencias, etc. Cada uno de estos registros de captura tiene un pin de entrada asociado que puede habilitarse mediante el pin connect block, y puede configurarse mediante el registro TnCCR para ser sensible a flancos de subida y/o de bajada y opcionalmente generar una interrupcin.

30

Cada timer tambin cuenta con cuatro registros de comparacin (MR), mediante los cuales podemos disparar acciones, como generar una interrupcin (configurable en el registro TnMCR) o modificar un pin de salida (configurable en el registro TnEMR).

3.9.3 UART

El LPC2148 integra dos UARTs conformes con el estndar 550, tanto en funcionamiento como en el orden de los registros. Estas dos UARTs son idnticas, salvo que la UART1 posee lneas adicionales para control de MODEMs. La siguiente figura muestra el diagrama de bloques de la UART1 y su conexin al bus VPB. La UART0 es exactamente igual, salvo por que no incluye el bloque etiquetado como MODEM:

Figura 9 Diagrama de bloques de la UART 1

La UART incluye un buffer de recepcin y de transmisin de 16 bytes, siendo el de recepcin configurable para producir interrupciones tras la recepcin de 1, 4, 8 y 14 31

bytes. Como en el resto de perifricos, para la utilizacin de las UARTs ser necesario configurar correctamente el pin connect block. Los parmetros de transmisin de las UARTs se configuran en registro LCR (line control register). El baud rate generator de las UARTs consiste en un divisor de 16 bits conectado al reloj de perifricos (PCLK). Tendremos que configurar este divisor para obtener una frecuencia 16 veces superior a la que queramos tener en la lnea de transmisin. El valor de este divisor se almacena en dos registros de 8 bits, DLM (divisor latch MSB) y DLL (divisor latch LSB). La operacin de las FIFOs es transparente para el programador. Una vez configurado su tamao, la escritura en el THR (transmit holding register) o la lectura en el RBR (receive buffer register), insertaran o extraern un byte en la FIFO. Aunque las UARTs poseen un canal dedicado en el VIC, stas a su vez pueden generar tres tipos de interrupcin diferentes, por lo que en la RTI habr que determinar la causa de la interrupcin. Estas causas pueden ser, un error en la transmisin, que puede ser de diversos tipos, la transmisin de todos los bytes de la FIFO de transmisin, o la recepcin de un nmero de bytes configurable.

3.9.4 CONVERTIDOR ANALGICO A DIGITAL

El LPC2148 integra un convertidor A/D de 10 bits de aproximaciones sucesivas con ocho entradas analgicas multiplexadas. Como en el resto de perifricos, el reloj del convertidor deriva de PCLK, teniendo en cuenta las restricciones temporales del convertidor, tendremos que configurar el registro CLKDIV de forma que la frecuencia del reloj del convertidor no sea mayor que 4.5MHz. Podemos seleccionar la resolucin de la conversin entre 3 y 10 bits, modificndose por tanto el tiempo de conversin. El convertidor puede operar en dos modos: un modo individual, en el que se realiza una conversin sobre el canal seleccionado, y un modo rfaga, en la que se realizan conversiones sobre todos los canales configurados. En ambos casos, al terminar el proceso puede generarse una interrupcin. Tambin puede configurarse para que las conversiones se realicen de forma continua, sin necesidad de iniciar el proceso tras cada interrupcin, pudiendo conseguirse de este modo alcanzar la mxima tasa de conversin.

32

3.9.5 CONVERTIDOR DIGITAL A ANALGICO

El convertidor digital analgico es el perifrico ms sencillo del LPC2148, ya que consta de un nico registro (DACR) en el que podemos escribir directamente el valor a convertir. Este conversor es de 10 bits y como los otros perifricos es necesario configurar el registro PINSELn correspondiente para conectarlo a su pin de salida asociado. Como nica particularidad, este conversor puede operar en dos modos: un de bajo fan out (350 A) y alta velocidad de conversin (1s), y otro de alto fan out (700 A) pero ms lento (2.5 s). Este modo se configura con el bit 15 del registro DACR.

3.9.6 MODULADOR PWM

El modulador PWM del LPC2148 es similar a los timers de propsito general, con hardware adicional que le permite generar seis seales PWM con modulacin de un flanco o tres de dos flancos, de hecho el modulo PWM puede utilizarse como un timer adicional si no se habilita el modo PWM. La principal diferencia en cuanto al comportamiento, con respecto a los timers de propsito general funcionando como contadores, es que en los timers, cuando se escribe un valor nuevo en el registro de comparacin, este valor se hace efectivo inmediatamente y adems eso ocurre para cada registro de comparacin, lo que puede provocar glitches y una desincronizacin de las seales PWM entre los distintos canales. Para evitar esto, el modulador PWM implementa un mecanismo de registros sombra que permite que todos los valores se actualicen simultneamente y al comienzo de un nuevo ciclo, con lo que puede generarse la seal PWM de forma correcta. Este perifrico cuenta con siete registros de comparacin, cada uno de los cuales est conectado a una salida. Puede programarse para poner la salida a uno, cero o no hacer nada cuando se alcance el valor del registro de comparacin. Como puede apreciarse en la figura, las salidas de estos registros de comparacin estn conectadas a registros S/R, en los cuales la entrada S es seleccionable entre la salida match del registro de comparacin 0 y la salida del registro de comparacin en cuestin. De este modo se puede implementar la modulacin de dos flancos o de un solo flanco.

33

Figura 10 Diagrama de bloques del mdulo PWM

En el caso de modular solo un flanco, con el registro de comparacin 0 podemos controlar el periodo total del ciclo, y con el resto de registros de comparacin, controlamos el ciclo de trabajo. En este modo la seal Match0 est conectada a la entrada S de todos los biestables, con lo que al final de cada ciclo se pondrn a 1. Para la modulacin de dos flancos, el registro de comparacin 0 solo se utiliza para controlar el periodo de la seal. En este caso las seales conectadas a los biestables son las correspondientes a los registros de comparacin 1 a 6, de forma que podemos controlar la conmutacin de los flancos de bajado y de subida.

34

3.9.7 WATCHDOG TIMER

Es comn en los microcontroladores contar con un mecanismo de seguridad que permita al sistema autoresetearse ante un fallo. Este mecanismo es habitualmente, y en el LPC2148, usar un timer que provocar un reset global en caso de desbordamiento, por lo que en nuestro software insertaremos una rutina de reseto que se ejecutara peridicamente. El watchdog timer (WDT) se controla a travs de cuatro registros. El timeout se programa en el registro WDTC. La siguiente figura muestra su diagrama de bloques:

Figura 11 Diagrama de bloques del WDT

El watchdog puede configurarse mediante el registro WDMOD para generar una interrupcin o bien un reset. En caso de generar un reset, activar un flag indicando que se ha producido un timeout, de forma que despus del reset, el programa puede determinar si se est iniciando despus de un reset debido a un fallo.

35

Tanto para iniciar el watchdog como para resetearlo peridicamente, tenemos que realizar una secuencia de inicio, consistente en escribir consecutivamente 0xAA y 0x55 en el registro WDFEED. En cualquier momento podemos leer el valor de la cuenta del watchdog timer en el registro WDTV.

3.10

HARDWARE DE DEBUG

El LPC2148 incluye varios mecanismos hardware para permitir la depuracin en circuito. El chip incluye un puerto JTAG, mediante el cual podemos efectuar una depuracin bsica, controlando la ejecucin, insertando breakpoints e inspeccionado la memoria, y un macroclula ARM embedded trace module, que permite una depuracin ms avanzada, que permite trazar cdigo en tiempo real, hacer anlisis de cobertura de cdigo y de rendimiento, pero que requieren hardware adicional a la interfaz JTAG, y que por tanto no cubriremos en el presente trabajo.

3.11

CONCLUSIONES

Como hemos visto a lo largo del presente captulo, el LPC2148 tiene unas caractersticas adecuadas para su uso como microcontrolador de propsito general, as como suficiente capacidad de clculo y de E/S como para poder utilizarse en sistemas de control. Tambin es muy interesante la integracin del puerto JTAG para depuracin, ya que otras familias, la depuracin en circuito solo puede llevarse a cabo con costosos emuladores adicionales.

36

ENTORNO Y HERRAMIENTAS DE DESARROLLO

4.1 INTRODUCCIN

A la hora de elegir una plataforma hardware para realizar un desarrollo, independientemente de la capacidad computacional y de E/S de la misma, es muy importante tener en cuenta otras consideraciones que pueden afectar sensiblemente al proceso de desarrollo con dicha plataforma. Uno de los elementos ms importante a considerar son el entorno y las herramientas de desarrollo disponibles. A la hora de elegir una herramienta de desarrollo, podemos tener en cuenta los siguientes requisitos: Adecuacin al proceso de desarrollo que vamos a aplicar: o Debemos elegir una herramienta coherente con el proceso de desarrollo que queramos seguir. Existen multitud de herramientas, basadas en lenguajes de programacin convencionales, programacin grfica, diseo basado en modelos, etc. Capacidad de depuracin y traza de cdigo: o Si bien en cualquier entorno la capacidad de depuracin y traza de cdigo es una funcionalidad obligada, en los sistemas en tiempo real cobra un valor especial, ya que posiblemente necesitemos calcular tiempos de ejecucin y monitorizar el uso de la CPU de forma precisa. Disponibilidad de hardware para depuracin: o Relacionado con el punto anterior, es interesante poder contar con una variada oferta de herramientas hardware para depuracin compatibles con el entorno de desarrollo, de manera que no dependamos de un solo fabricante. Existencia de una amplia base de usuarios: o Es quizs unos de los puntos ms importantes, ya que las plataformas con muchos usuarios suelen estar muy documentadas no solo por los fabricantes, si no por las comunidades de usuarios, existiendo foros en los que se intercambia conocimiento tcnico y se puede obtener ayuda de forma gratuita. Tambin es interesante ya que las plataformas ampliamente extendidas suelen estar ms depuradas y optimizadas simplemente por el hecho de que son utilizadas por un gran nmero de usuarios, lo que implica que es utilizada en multitud escenarios distintos. Coste de las herramientas: o Ms que un requisito es una limitacin. Con toda seguridad, a la hora de elegir el entorno de desarrollo tendremos una limitacin

37

presupuestaria. Como veremos ms adelante, y como suele ocurrir en otros mbitos, no siempre la mejor herramienta es la ms cara. Existen nmeros compiladores y entornos de desarrollo tanto libres como propietarios para microcontroladores y microprocesadores ARM. En el presente trabajo, se ha optado por usar nicamente herramientas libres disponibles de forma gratuita y con licencia GNU GPL u otras similares. Para facilitar la redistribucin del entorno de desarrollo, se empleara un sistema operativo virtualizado, de forma que no sea necesario hacer ningn tipo de configuracin al instalar el entorno de trabajo en una mquina nueva, a la vez que se hace completamente portable. Como sistema operativo virtualizado se ha utilizado la distribucin de Linux Ubuntu 10.4 LTS (Long Term Support), que una versin con soporte a largo plazo (tres aos). Como se ha comentado anteriormente, el entorno completo de desarrollo se facilita como una imagen de mquina virtual para VMWare, de forma que no haya que realizar el largo proceso de instalacin y configuracin en las mquinas de desarrollo. En cualquier caso, en los siguientes punto explicaremos es proceso de instalacin de todas las herramientas necesarias.

4.2 EL ENTORNO DE DESARROLLO 4.2.1 UBUNTU LINUX

Como sistema operativo se ha optado por la distribucin Ubuntu de Linux, debido a su probada solidez y amplia implantacin entre los usuarios. Se ha elegido una versin LTS para asegurar la operatividad del entorno a medio plazo. La instalacin de Ubuntu es un proceso sencillo, en el que nos limitaremos a seguir el asistente de instalacin.

4.3 HERRAMIENTAS DE DESARROLLO 4.3.1 CODESOURCERY G++ LITE

Codesourcery G++ Lite es una distribucin libre del toolchain GNU. Es ofrecido por la compaa Codesourcery, que adems comercializa versiones de pago que integran un IDE basado en Eclipse, muy similar al que instalaremos nosotros posteriormente, y opciones de soporte. 38

Est disponible para varias familias de procesadores, obviamente nosotros instalaremos la versin para ARM. La versin Lite solo incluye las GCC:8 los compiladores de C y C++, ensamblador, linker, las libreras estndar y debugger. La eleccin de usar las GCC se debe bsicamente al hecho de que las herramientas son gratuitas y de que disponen de un amplio soporte. El rendimiento de estas herramientas es muy bueno, comparable a cualquier herramienta propietaria, obtenindose resultados en cuanto tamao del cdigo generado y velocidad de ejecucin muy parecidos. Existen mltiples comparativas de rendimiento en la red, siendo una de las ms completas la realizada por Raisonance9. Por otra parte, el depurador GDB se integra bien en nuestro entorno de desarrollo, permitindonos depurar cdigo en el microcontrolador usndolo de forma conjunta con OpenOCD y una interfaz JTAG, tal y como veremos ms adelante.
4.3.2 ECLIPSE IDE

Eclipse es un popular entorno de desarrollo (IDE) gratuito y de fuentes abiertas. Aunque inicialmente el fue un proyecto iniciado por IBM, en la actualidad es desarrollado y soportado por la Eclipse Foundation, que es una fundacin sin nimo de lucro financiada por sus miembros estratgicos, entre los que se encuentra compaas como IBM, NOKIA, SAP, ORACLE, CISCO, Motorola o BlackBerry. Este IDE es neutral, extensible a mltiples lenguajes de programacin y herramientas (compiladores, debuggers, etc.). En este proyecto usaremos la versin Eclipse CDT10. Esta versin proporciona un entorno de desarrollo para C y C++, que integraremos con nuestro compilador.

4.3.3 OPENOCD

OpenOCD es una utilidad software que permite interfasear el depurador GPB con la interfaz JTAG para poder programar y depurar el microcontrolador. GDB establece una

8 9

GNU Compiler Collection http://www.raisonance.com/arm_benchmark.html C/C++ Development Tooling 39

10

conexin TCP/IP con OpenOCD, y ste, en base a una serie de archivos de configuracin, se comunicara con la interfaz JTAG que controlar el estado de ejecucin del microcontrolador a travs del TAP (Test Access Port) del mismo. Esta herramienta es muy flexible, ya que incluye un intrprete de lenguaje Tcl, lo que le permite ejecutar scripts muy complejos. En el caso del LPC2148 como en otras muchas plataformas, no tendremos que escribir los scripts de configuracin, ya que con la distribucin de la herramienta se incluyen diversos scripts para multitud de plataformas, que adems nos pueden servir como punto de partida para crear scripts ms personalizados, como haremos ms adelante. Estos scripts se encuentran en el directorio scripts (normalmente en /usr/share/openocd/scripts). Hay tres tipos de scripts, contenidos en sus correspondientes subcarpetas: Interface: para cada tipo de adaptador JTAG soportado Board: para distintas placas de desarrollo Target: especficos para cada CPU

Normalmente solo tendremos que hacer referencia a dos scripts, el de configuracin de interfaz y el de la placa que estemos utilizando. En el contexto de este proyecto configuraremos la ejecucin OpenOCD desde eclipse como herramienta externa, para lo cual definiremos dos configuraciones de ejecucin en el men External tools configuration. La primera configuracin ser para la utilizacin de OpenOCD para depuracin. La siguiente captura de pantalla refleja la configuracin necesaria:

Figura 12 Configuracin de OpenOCD

40

Se puede observar que ejecutamos los scripts de configuracin de la interfaz JTAG y del microcontrolador. Para iniciar una sesin de depuracin tendremos siempre que ejecutar esta configuracin desde Eclipse. Adicionalmente, necesitaremos configurar la depuracin en eclipse. Para ello aadiremos una configuracin de depuracin de tipo Zylin embedded debug. Tendremos que establecer como debugger arm-none-eabi-gdb, y configurar los comandos de inicializacin de tal y como estn definido en cualquiera de los proyectos de ejemplo incluidos en el DVD adjunto. La segunda configuracin es especfica para flashear el microcontrolador:

Figura 13 Flasheo del micro con OpenOCD

En esta configuracin adems ejecutamos un script especfico para flashear el micro. Cuando generemos una nueva versin de un programa, debemos cargarla en la flash del microcontrolador usando este script. Este script se adjunta en el DVD que acompaa al presente documento.

4.3.4 PLACA DE DESARROLLO OLIMEX LPC-P2148

Para el desarrollo del sistema de control emplearemos esta placa de desarrollo, basada en un microcontrolador LPC2148.

41

Figura 14 Olimex LPC-P2148

Esta placa proporciona un puerto JTAG para depuracin, as como el hardware adaptador de nivel para dos puertos RS232 y USB. Tambin incluye un socket para tarjetas SD, botn de reset, dos botones de usuario, un buzzer, dos LEDs y un potencimetro conectado a un canal del conversor A/D. Esta placa incorpora un rectificador de tensin, por lo que puede alimentarse a 6V DC. Tambin puede alimentarse a travs del puerto USB.
4.3.5 INTERFAZ JTAG OLIMEX ARM-USB-OCD

Para depurar y programar el microcontrolador LPC2148 usaremos una interfaz JTAG. Se ha seleccionado la interfaz Olimex JTAG USB por su bajo costo, compatibilidad con el resto de herramientas, y versatilidad, ya que adems de servirnos como interfaz JTAG incluye un regulador de DC que puede proporcionar una tensin seleccionable de 5,9 o 12 voltios, lo que permite utilizar la placa de desarrollo sin necesidad de emplear una fuente de alimentacin adicional. En cualquier caso tendremos que tener en cuenta que para algunas aplicaciones este regulador no podr proporcionarnos la potencia necesario, ya que la corriente mxima que entrega es de 200mA a 5V, adems de no ofrecer una regulacin muy buena, por lo que para aplicaciones sensibles a la tensin de alimentacin ser necesario usar una fuente de alimentacin convenientemente regulada. Adicionalmente esta interfaz proporciona un puerto serie RS232, muy conveniente, ya que los PCs actuales no suelen incorporarlo. 42

Figura 15 Interfaz JTAG

Esta interfaz JTAG de esta basada en el chip FTDI FT223211, que est especficamente soportado por OpenOCD.
4.3.6 HIGH INTEGRITY STAVIEWER PLUGGIN

Este plugin, desarrollado por High Integrity Systems, que es la compaa que ofrece soporte comercial y versiones certificables de FreeRTOS, permite inspeccionar durante la depuracin el estado de las tareas, colas de mensajes y semforos de nuestra aplicacin. La instalacin de este plugin en Eclipse bajo Linux no est directamente soportada por el fabricante, por lo que para hacerlo hay que seguir un procedimiento especial. El paquete de distribucin de este plugin es un instalador para Windows, sin embargo, el plugin en s mismo es una aplicacin Java. Para poder instalarlo en Eclipse bajo Linux, primero tendremos que ejecutar el instalador bajo Windows, que crear una carpeta de instalacin en la que tendremos acceso al manual y a los mdulos Java que componen el plugin. Dentro de la ruta de instalacin en Windows, en la carpeta plugins, encontramos el modulo Java en cuestin:

11

http://www.ftdichip.com 43

Figura 16 Instalacin de STATEVIEWER

Procedemos a copiar toda la carpeta de instalacin de Windows a nuestra mquina Linux. Para instalar el plugin, en el men Help de Eclipse seleccionamos Install New Software, y en el cuadro de dilogo que aparece presionamos el botn Add. Nos mostrar un nuevo cuadro de dilogo en el que debemos introducir el nombre del plugin y la ruta de la carpeta que previamente hemos copiado. En este momento nos listar el plugin como disponible para su instalacin:

Figura 17 Instalacin de plgin en Eclipse

44

A partir de este momento solo tenemos que seguir el asistente de instalacin y reiniciar Eclipse al final del proceso. A partir de este momento, tendremos dos nuevas vistas disponibles en el men Window->ShowView->Other:

Figura 18 Seleccin de las vista de depuracin del FreeRTOS

Como se puede observar, tras la instalacin disponemos de dos vistas nuevas: Queue table y Task table. Queue table mostrar informacin sobre las colas de mensajes y semforos que usemos en la aplicacin. Es una vista tabular con las siguientes columnas: Name: nombre de la cola o semforo Address: direccin de la estructura que mantiene la cola o semforo. Max Length: mximo nmero de elementos que puede alojar la cola. Item size: tamao de cada elemento de la cola en bytes. Current Length: nmero de elementos almacenados actualmente en la cola. #Waiting Tx: nmero de tareas que hay bloqueadas esperando que la cola est disponible para escritura. #Waiting Rx: nmero de tareas que hay bloqueadas esperando mensajes de la cola.

45

Figura 19 Tabla de colas de mensajes

Task table es otra vista tabular, pero esta, como su nombre indica, mostrar informacin sobre el estado de ejecucin de las tareas. Est compuesta por las siguientes columnas: Task Name: el nombre de la tarea. Task Number: ID nico asignado por el kernel a la tarea. Priority/actual: prioridad efectiva que posee actualmente la tarea. Esta puede ser distinta que la prioridad base debido al mecanismo de herencia de prioridad. Priority/base: prioridad base de la tarea. Start of stack: direccin base del stack asignado a la tarea. Top of stack: direccin de la ltima insercin en el stack. State: estado de ejecucin de la tarea. Event object: nombre o direccin del objeto de sincronizacin que est bloqueando la tarea. Min free stack: esta columna permite calcular la High water mark que es el mnimo nmero de bytes que ha habido libres en el stack durante la ejecucin. Esta funcin es muy til para dimensionar y optimizar el tamao del stack asignado a cada tarea, aunque no es conveniente tenerla siempre activa ya que relentiza bastante la ejecucin.

Figura 20 Tabla de tareas

46

4.4 CONCLUSIONES

Como se ha visto, es posible configurar un entorno completo de desarrollo para la plataforma ARM usando software libre. El resultado es un entorno de desarrollo de alta calidad, con todas las funciones que pueda ofrecer cualquier herramienta comercial, y al estar virtualizado, fcilmente distribuible, facilitando las tareas de mantenimiento de los puestos de desarrollo. En las prximas secciones utilizaremos este entorno para desarrollar las aplicaciones para el microcontrolador.

47

48

SISTEMAS OPERATIVOS EN TIEMPO REAL

5.1 INTRODUCCIN

Los sistemas de control modernos son generalmente sistemas complejos en los cuales intervienen diversos mdulos que cooperan entre s para realizar la accin de control. Estos mdulos suelen tener restricciones temporales en su ejecucin, as como fuertes relaciones con los dems mdulos del sistema. Si bien existen tcnicas clsicas para la implementacin de sistemas de control en tiempo real, el uso de un sistema operativo dedicado a tal efecto simplifica en buena medida el proceso de implementacin, limitando las dependencias con el hardware y proporcionando mecanismos de temporizacin, comunicaciones y sincronizacin de procesos que permiten al desarrollador centrarse en la funcionalidad y no tener que preocuparse por implementar el mismo de forma correcta esos mecanismos. Algunas caractersticas deseables para un sistema operativo en tiempo real son: Determinismo temporal en la ejecucin de procesos. Baja latencia en la atencin a interrupciones. Baja latencia en la conmutacin de procesos.

En el contexto de los sistemas basados en microcontrolador, a los requisitos usuales de los sistemas operativos en tiempo real hay que aadir algunos especficos debido a la limitacin de recursos de estos sistemas, en concreto por la carencia de unidad de gestin de memoria (MMU) y especialmente por la escasez de memoria RAM. En los apartados siguientes revisaremos algunos conceptos fundamentales en los sistemas operativos de tiempo real.

5.2 MULTITAREA

El kernel es el mdulo fundamental en un sistema operativo; en los sistemas operativos multitarea, se encarga de la gestin de las tareas en ejecucin. El kernel proporciona mecanismos para la ejecucin de mltiples tareas simultneamente y para la sincronizacin y comunicacin entre ellas. El uso de un sistema operativo multitarea puede facilitar la implementacin de sistemas complejos: Actividades complejas pueden descomponerse en tareas ms simples.

49

Los mecanismos de temporizacin son gestionados por el sistema operativo. El particionado en procesos puede hacer ms fciles las pruebas del software.

5.3 MULTAREA Y CONCURRENCIA

Los procesadores con un solo ncleo nicamente pueden ejecutar una tarea en un instante de tiempo determinado, pero si conmutamos las tereas en ejecucin rpidamente, podemos hacer que se comporte como si realmente se ejecutaran de forma concurrente. En un microcontrolador con un solo ncleo, solo podr ejecutarse una nica tarea. El kernel decide que tarea debe ejecutarse comprobando la prioridad de cada tarea. En microcontroladores con varios ncleos, como las familias Renesas SH72x5l o la familia Propeller de Paralax, podemos conseguir la ejecucin concurrente real (multiprocesamiento simtrico) de tantos procesos como CPUs integre el microcontrolador.

5.4 EL PLANIFICADOR

El planificador es el componente del kernel que decide que tarea se ejecuta en cada instante de tiempo. La decisin de que tarea es la que se ejecuta se hace conforme a la poltica de planificacin usada por el planificador. Una tarea puede ser suspendida por el kernel, pero tambin puede suspenderse a s misma, por ejemplo si quiere esperar un determinado tiempo o esperar que un recurso est disponible. Una tarea suspendida no requiere tiempo de procesamiento, con lo que el planificador puede poner en ejecucin otra tarea. Cuando una tarea est en ejecucin, utiliza los registros de la CPU y accede a la RAM como cualquier programa. Estos recursos representan el contexto de ejecucin de una tarea. Cuando el kernel suspende una tarea, es necesario que se guarde este contexto de ejecucin, ya que cuando se vuelva a ejecutar la misma tarea, este contexto debe ser restaurado al estado inmediatamente anterior a la suspensin. Al proceso de guardar el contexto de una tarea y restaurar el contexto de una tarea que pase a ejecutarse se le llama cambio de contexto. 50

5.4.1 APLICACIONES DE TIEMPO REAL

Los sistemas operativos de tiempo real se basan fundamentalmente en los principio comentados anteriormente, pero con el objetivo concreto de hacer que los sistemas tengan un tiempo de respuesta predecible ante determinados eventos. Normalmente cuando se afronta el diseo de un sistema en tiempo real que debe responder a eventos externos, se presenta una limitacin en el tiempo de respuesta a los eventos, de forma que el sistema debe responder antes de dicho lmite de tiempo, llamado deadline, para que el resultado sea vlido.

Figura 21 Deadline de procesamiento

La respuesta al estmulo puede ser sncrona o asncrona, pero en cualquier caso, debemos asegurar la respuesta dentro del deadline. La siguiente figura ilustra el comportamiento de una tarea sncrona o peridica:

Figura 22 Ejecucin sncrona

Esta aproximacin permite efectuar el procesamiento requerido con una periodicidad fija, de forma que en el peor caso aseguramos la atencin a la ocurrencia de un evento en un tiempo igual a dos periodos. La siguiente figura muestra el comportamiento de una terea asncrona:

51

Figura 23 Ejecucin asncrona

Esta aproximacin puede usarse si el proceso est estrictamente vinculado al tiempo en el que ocurre el evento, de esta forma podemos asegurar el procesamiento ante un evento dentro de un deadline a partir de la ocurrencia del mismo. Para alcanzar este objetivo, el desarrollador debe asignar prioridades a las distintas tareas, de forma que se asegure la ejecucin prioritaria de las tareas con mayores restricciones temporales. Consideremos el siguiente ejemplo: Se est implementando un ecualizador de audio. El sistema realiza el filtrado de una seal muestreada en funcin de los controles manipulables por el operador del equipo. La lectura de los controles la realiza la siguiente funcin:
void vTareaLeerControles(void *pvParameters) { for(;;) { [esperar 1/100 segundos] [leer controles] [calcular coeficientes de los filtros] } } El filtrado lo realiza la siguiente funcin: void vTareaFiltrado(void *pvParameters) { for(;;) { [esperar 1/44100 segundos] [tomar muestra] [filtrar] [escribir muestra en CDA] } }

Listado 1 Procesado de audio en tiempo real

52

El sistema tiene la siguiente restriccin: El procesado de ninguna muestra puede retrasarse ms de 1/44100 segundos, ya que provocara un efecto audible. Para asignar prioridades a las tareas tendremos en cuanta lo siguiente: El deadline de la tarea de filtrado es ms estricto que la de control de usuario. Las consecuencias de la prdida del deadline de la tarea de filtrado no es tolerable.

Por tanto se asignar una mayor prioridad a la tarea de filtrado.

53

54

FREE RTOS

6.1 INTRODUCCIN A FREERTOS.

FreeRTOS es un Kernel de tiempo real gratuito y de fuentes abiertas. Esta desarrollado y soportado por la compaa High Integrity Systems, que ofrece soporte y versiones comerciales y certificables (OpenRTOS y SafeRTOS12) del mismo, de las cuales Texas Instruments comercializa un dispositivo con SafeRTOS pregrabado en ROM. Adicionalmente, est soportado por una amplia comunidad de desarrolladores, siendo quizs el sistema operativo de tiempo real ms ampliamente usado de su categora. Este SO se ha portado a mltiples arquitecturas y herramientas de desarrollo. El SO se puede considerar de tipo microkernel, ya que no ofrece ms que un planificador y una API de comunicacin entre procesos. No obstante, proporciona mecanismos suficientes para poder implementar mecanismos de abstraccin de hardware, como drivers de dispositivos, que en el caso de FreeRTOS no son ms que un proceso convencional dedicado a tal propsito y quizs las rutinas de interrupcin vinculadas al hardware a abstraer.

FreeRTOS es especialmente apropiado para ser usado en sistemas embebidos basados en microcontroladores con recursos limitados, en la que otras opciones como QNX, Integrity o VxWorks no son viables. Aade un overhead de procesamiento mnimo, as como un consumo de memoria muy bajo; el kernel solo requiere entre 4 y 9 KB segn la configuracin. El planificador puede configurarse para funcionar de forma expropiativa, cooperativa e hibrida, as mismo permite el uso de procesos, corrutinas o ambos mecanismos a la vez. Tambin proporciona mecanismos de traza de ejecucin y optimizacin.
6.1.1 MULTIPROCESAMIENTO EN SISTEMAS EMBEBIDOS PEQUEOS.

Existen mtodos altamente efectivos para disear software para sistemas embebidos sin necesidad de usar un RTOS, como puede ser mediante la implementacin de mquinas de estados. Para los sistemas ms sencillos prescindir de un RTOS puede

Precertificado IEC61508 SIL3, FDA510(k) Class III y EN62304, cualificable para DO178B. 55

12

resultar la mejor opcin, sin embargo, segn aumenta la complejidad del sistema a implementar, las ventajas de usar un RTOS se hacen evidentes. Como se ha comentado anteriormente, la priorizacin de tareas puede ayudar a conseguir que la aplicacin cumpla con los deadlines, pero el uso de un kernel proporciona otros beneficios que aunque inicialmente no son tan obvios, presentan enormes ventajas frente a la no utilizacin de un RTOS: Abstraccin del comportamiento temporal: El kernel es responsable de la temporizacin y proporciona una API para este propsito. Mantenibilidad / Extensibilidad: Al abstraer los detalles de temporizacin resulta en una reduccin de las dependencias entre distintos mdulos, lo que permite aumentar el aislamiento de cada componente software. As mismo, al encargarse el SO de la temporizacin, conseguimos abstraer las dependencias temporales con respecto al hardware empleado, lo que mejora la portabilidad de la solucin. Modularidad: Por definicin, cada tarea es independiente. Esto tambin implica una facilidad aadida para el desarrollo en equipo y las pruebas. Reutilizabilidad del cdigo: Debido a la modularidad e independencia de cada tarea, puede ser sencillo reutilizarlas en otras aplicaciones. Mejora de la eficiencia: En aplicaciones complejas, resulta realmente difcil hacerlas dirigidas por eventos de una forma eficiente, as como eliminar por completo las esperas activas y pollings. FreeRTOS proporciona todos los servicios necesarios para que los procesos sean completamente dirigidos por eventos, el precio a pagar es un ligero impacto al tenerse que ejecutar el cdigo del kernel.

56

Gestin del tiempo improductivo: Mediante la tarea Idle, podemos usar el tiempo en el que no se est ejecutando ninguna tarea para diversos, como por ejemplo, poner el microcontrolador en modo de bajo consumo.

Manejo de interrupciones ms flexible: Pueden mantenerse los tiempos de atencin a interrupciones muy bajos haciendo que el procesamiento se haga mediante una tarea designada, fuera de la propia RTI.

Acceso a los perifricos seguro y simplificado: Es posible codificar tareas encargadas de la gestin y acceso a los perifricos, de forma similar a un driver. Estos drivers son fcilmente reutilizables en otros proyectos.

6.2 EL PLANIFICADOR

En FreeRTOS los procesos se implementan mediante funciones en C. Para que una funcin pueda ser manejada como un proceso debe tener el siguiente prototipo: Void NombreDelProceso(void *pvParametros) Un proceso no debe salir de su funcin de implementacin nunca, es decir, nunca contendrn una funcin return. Para la destruccin de procesos siempre han de usarse las funciones para tal propsito de la API de FreeRTOS. Cada proceso podemos considerarlo como un programa independiente, cuyo punto de entrada es la funcin que implementa el proceso. Es posible ejecutar varias instancias del mismo proceso, en ese caso, cada instancia posee su propio contexto de ejecucin.
6.2.1 GESTIN DE PROCESOS

En un sistema con un solo procesador, como es el caso del LPC2148, solamente una tarea podr ejecutarse en un determinado instante de tiempo. El conjunto de tareas que componen el sistema podrn estar en dos estados principales: en ejecucin o no en ejecucin. Las tareas que no estn en ejecucin, a su vez pueden estar en distintos estados: suspendida, bloqueada o preparada.

57

Una tarea prepara est lista para proseguir su ejecucin. Estas tareas estn a la espera de que el planificador les asigne la CPU. Una tarea bloqueada est a la espera de algn evento, como puede ser que un semforo se libera, la recepcin de un mensaje desde una cola de mensajes o a la espera de que pase un determinado tiempo. Una tarea suspendida no es tenida en cuenta por el planificador, pero podra continuarse su ejecucin ya que la tarea sigue existiendo, as como su stack y su ltimo contexto de ejecucin. En FreeRTOS la suspensin de tareas tiene que ser explcita, as como su continuacin. En el siguiente diagrama pueden observarse los diferentes estado en los que pueden estar las tareas en FreeRTOS(), as como las condiciones o funciones que provocan las transiciones entre estados:

Figura 24 Estados de los procesos

6.2.1.1 ALGORITMO DE PLANIFICACIN DE FREERTOS

FreeRTOS utiliza un algoritmo de planificacin expropiativa de prioridad fija. Con prioridad fija nos referimos a que la prioridad de cada proceso nunca es modificada por el planificador. Es expropiativa ya que un proceso que este en estado Preparado 58

siempre expropiara la ejecucin si el proceso en ejecucin tiene una prioridad inferior a l. Los procesos pueden esperar en el estado bloqueado a que ocurra un evento, en ese momento pasaran a estado Preparado. Cuando varios procesos con la misma prioridad estn en estado preparado, su ejecucin ser tipo round robbin, asignado a cada proceso slice de un tamao igual a un tick del sistema. En el siguiente diagrama se ilustra el comportamiento de una aplicacin: Proceso 1 Proceso 2 Proceso 3 Idle T1 T2 T 3 T4 T5 T6 T 7 T 8 T9 T10

Figura 25 Ejemplo de planificacin de procesos

Proceso 1: prioridad alta, espera evento Proceso 2: prioridad media, ejecucin peridica Proceso 3: prioridad baja, espera evento Idle: proceso de ms baja prioridad, se ejecuta de forma continua En T1 este es el estado de ejecucin: Proceso 1: bloqueado, espera la ocurrencia de un evento. Proceso 2: en ejecucin. Proceso 3: bloqueado, espera la ocurrencia de un evento. Idle: no est en ejecucin ya que el Proceso 2 tiene mayor prioridad. En T2 Proceso 2 completa su ejecucin y pasa a bloqueado, los procesos 1 y 3 siguen bloqueados, Idle pasa a ejecutarse. En T3 se produce el evento que espera el proceso 3, con lo que pasa a preparado e inmediatamente expropia la ejecucin a Idle.

59

En T4 el proceso 3 termina su ejecucin, como los procesos 2 y 3 siguen bloqueados, por lo que Idle pasa a ejecutarse. En T5 se produce otra vez el evento que espera el proceso 3, pasando a preparado e inmediatamente expropiando la ejecucin a Idle. En T6 expira el periodo de ejecucin del proceso 2, pasando este a preparado. Al tener mayor prioridad que proceso 3, pasa a ejecucin, quedando el proceso 3 en preparado. En T7 ocurre el evento que espera T1, con lo que pasa a preparado, y al tener mayor prioridad que el proceso 2, pasa a ejecucin, quedando este en estado preparado. En T8 el proceso 1 termina su ejecucin, pasando a bloqueado a la espera de un nuevo evento. El proceso 2 pasa a ejecucin, al ser el de mayor prioridad de los procesos preparados. En T9 el proceso 2 termina su ejecucin, pasando a bloqueado. El proceso 3 es planificado al poseer mayor prioridad que Idle. En T10 el proceso 3 termina su ejecucin, pasando a bloqueado a la espera de un nuevo evento. Al no haber ningn otro proceso preparado, Idle pasa a ejecucin.
6.2.1.2 PLANIFICACIN COOPERATIVA

FreeRTOS puede configurarse para implementar una planificacin cooperativa. En un sistema operativo con planificacin cooperativa, los cambios de contexto solo ocurren cuando una tarea se bloquea a s misma, o llama al planificador para que reasigne la ejecucin (median la funcin taskYIELD()). En este contexto, un proceso nunca es expropiado de la ejecucin por otros procesos. Tampoco se comparte el tiempo de ejecucin con procesos con la misma prioridad. Aunque FreeRTOS puede configurarse para hacer una planificacin cooperativa, en el presente trabajo no se usar esta posibilidad. Una planificacin cooperativa puede resultar en una mayor eficiencia, pero requiere un diseo muy cuidado de la aplicacin, as como pruebas exhaustivas, ya que cualquier proceso podra bloquear todo el sistema.
6.2.1.3 EL TICK DEL SISTEMA. GESTIN DEL TIEMPO

El kernel de FreeRTOS mide el tiempo usando una variable para contar ticks. Para implementar tal mecanismo FreeRTOS utiliza un timer que genera una interrupcin en la que se incrementa dicho contador. La frecuencia de este temporizador es configurable, y no permite ajustar con precisin la granularidad temporal del sistema. 60

Gracias a este mecanismo las funciones temporizadas de la API pueden hacer esperas pasivas y timeouts, siempre en tiempos mltiplos del periodo del tick del sistema. Cada vez que se incrementa el contador de ticks, el planificador comprueba si debe desbloquear alguna tarea, lo que adems puede provocar un cambio de contexto. Obviamente este mecanismo nos obliga a prescindir de uno de los timers de propsito general del microcontrolador, ya que debe ser para uso exclusivo del sistema operativo.
6.2.1.4 CAMBIO DE CONTEXTO

Como sabemos, el contexto de ejecucin de una tarea est compuesto por el conjunto de registros que utiliza y su montculo. Al ser suspendida una tarea y planificado otra, es imprescindible almacenar este contexto de ejecucin para poder restaurarlo en el momento en que se vuelva a ejecutar la tarea suspendida. En FreeRTOS, al usar un mecanismo de planificacin expropiativa, las tareas pueden ser suspendidas en cualquier momento, por lo que al ser imprevisible por la propia tarea, el cambio de contexto lo realiza el sistema operativo. En la CPU ARM7 el contexto de ejecucin consiste en los registros R0-R15 y el CPSR. Como veremos ms adelante, FreeRTOS implementa un mecanismo de gestin de memoria para poder gestionar los montculos de los distintos procesos. El planificador almacenar en el montculo de cada tarea su contexto de ejecucin con el fin de restaurarlo al proseguir la ejecucin. Tambin encontraremos la necesidad de salvaguardar el contexto de ejecucin de las tareas cuando se ejecute una rutina de interrupcin que pueda llevar a cabo un cambio de contexto, ya sea directamente o al usar la API de IPC, lo que podra forzar al planificador a cambiar de proceso en ejecucin. Veremos este mecanismo en un apartado dedicado.
6.2.2 CREACIN Y DESTRUCCIN DE TAREAS

En este apartado veremos el proceso de declaracin, creacin y ejecucin de una tarea. Para que una tarea pueda ser panificable por FreeRTOS, esta debe ser implementada en una funcin en C que implemente el siguiente prototipo: void Tarea(void *pvParameters) Cada tarea podremos considerarla como un programa en s misma, independiente del resto de tareas en ejecucin.

61

Adems de declarar la tarea, para que pueda ser planificable por el kernel, es necesario que la creemos mediante la funcin de la API xTaskCreate, normalmente esto se har en la funcin main() del sistema o en otra tarea. Normalmente una tarea incluye un bucle infinito, donde se lleva a cabo el procesamiento. En este sentido, si bien una tarea no tiene porque ejecutarse de forma indefinida, si hay que tener en cuenta que nunca debe retornar, es decir, nunca intentar suspender su ejecucin mediante un return. Si se desea terminar una tarea, hay que destruirla especficamente con la funcin xTaskDelete() de la API de FreeRTOS, esto puede hacerse desde la propia tarea o desde otra tarea. Por ltimo, tendremos que inicial el planificador, que gestionar la ejecucin de las tareas creadas. En el ejemplo Proyecto Bsico incluido en el DVD adjunto puede verse un ejemplo de este proceso.

6.3 GESTIN DEL MONTCULO

Como se ha comentado anteriormente, FreeRTOS necesita reservar memoria para almacenar el contexto de ejecucin de los distintos procesos, as como para almacenar las estructuras usadas por semforos y colas de mensajes. Para ello implementa tres esquemas de gestin de memoria, que se adaptan a distintos requisitos que podamos tener en nuestra aplicacin.
ESQUEMA 1

Implementado en heap_1.c Es el esquema ms restrictivo. No permite liberar memoria, lo que restringe la reserva de memoria dinmicamente. El algoritmo asigna memoria del montculo, dimensionado estticamente en el archivo de configuracin de FreeRTOS mediante la definicin configTOTAL_HEAP_SIZE. Este esquema solo es usable si no destruimos tareas, semforos ni colas de mensajes. Presenta la ventaja de que su ejecucin es determinstica.
ESQUEMA 2

Implementado en heap_2.c Es un poco menos restrictivo que el anterior, en cuanto a que permite la liberacin de bloques de memoria, pero no reordena la memoria, lo que puede dar lugar a la 62

fragmentacin del montculo, por lo que solo debe usarse cuando los bloques de memoria a crear y eliminar sean del mismo tamao, es decir, tareas con el mismo tamao de pila y colas de mensajes del mismo tamao. Otro inconveniente que presenta este esquema es que su ejecucin no es determinstica.
ESQUEMA 3

Es el menos restrictivo, simplemente es un envoltorio que hace uso de las funciones malloc() y free() encapsulndolas en una seccin critica para protegerlas ante eventuales cambios de contexto. En este esquema la ejecucin es no determinstica.

En este proyecto incluiremos el esquema de gestin de memoria que mejor se adapte a nuestras necesidades, pero en el contexto de microcontroladores con escasos recursos de memoria RAM, en general suele ser ms conveniente y seguro emplear el esquema 1 siempre que la aplicacin lo permita, as como hacer el software completamente esttico, prescindiendo del uso de memoria dinmica.

6.4 USO DE LA PILA

Como se coment anteriormente, cada tarea posee su propia pila. La memoria usada por la pila de cada tarea se reserva automticamente al crear la tarea con la dimensin especificada. Averiguar el tamao ptimo de la pila no es un proceso sencillo, pero FreeRTOS proporciona varios mecanismos para poder llevar a cavo esta tarea. El ms sencillo puede ser utilizar el Stateviewer plugin para ver el espacio mnimo disponible, e ir aumentando el tamao del stack si llegamos a quedarnos sin memoria. Tambin podemos comprobar en tiempo de ejecucin si ocurre un desbordamiento de pila mediante la definicin de configuracin configCHECK_FOR_STACK_OVERFLOW. Mediante esta configuracin podemos definir una funcin gancho con el siguiente prototipo: void vApplicationStackOverflowHook( xTaskHandle *pxTask, signed portCHAR *pcTaskName ); Esta funcin ser ejecutada cuando se desborde la pila. El parmetro pxTask es un puntero al manejador de la tarea que ha causado el desbordamiento, y pcTaskName es el nombre de dicha tarea. 63

Internamente, FreeRTOS puede implementar dos mtodos para detectar el desbordamiento de la pila:
MTODO 1

FreeRTOS al quitar de ejecucin a una tarea, que supone que es el momento en que la pila est ms ocupada al contener todo el contexto de ejecucin del proceso, comprueba si el puntero de pila est dentro del rango permitido. Para usar este mtodo hay que definir la configuracin a 1.

MTODO 2

En este mtodo es complementario al 1 y lo que se hace es escribir todo el stack con un valor conocido y fijo. Ahora lo que se comprueba tras el cambio de contexto es el valor de los 16 ltimos valores de la memoria reservada al stack para ver si se han sobrescrito. Para usar este mtodo, definiremos la configuracin a 2.

6.5 MECANISMOS DE COMUNICACIN ENTRE PROCESOS (IPC)

FreeRTOS implementa una API de IPC bsica, que incluye los siguientes mecanismos de comunicacin entre procesos y sincronizacin: Colas de mensajes. Semforos binarios. Semforos contadores. Mutex. Mutex recursivos.

Semforos binarios. Su aplicacin tpica es la de sincronizacin de procesos. La implementacin de FreeRTOS de los semforos binarios tiene las siguientes caractersticas: No implementa herencia de prioridad. Implementa un mecanismo de timeout de espera.

Hay que notar, que hay la API consta de mtodos para la manipulacin de semforos diferenciados de si la operacin se hace o no desde una interrupcin. 64

SEMFOROS CONTADORES.

Su aplicacin tpica es la cuenta de eventos y la gestin de recursos. Los semforos contadores tambin implementan un mecanismo de timeout, y al igual que los semforos binarios, cuenta con funciones especficas para su manipulacin desde rutinas de interrupcin.
MUTEX.

Son bsicamente una implementacin de los semforos binarios con un mecanismo de herencia de prioridad. Este mecanismo hace que si una tarea de baja prioridad T1 est ocupando un recurso, y una tarea de mayor prioridad T2 intenta acceder a este, la prioridad de T1 se eleva a la de T2, con el fin de que el recurso se libere lo antes posible para que est disponible para T2.
MUTEX RECURSIVOS.

No es ms que un mutex que se puede tomar varias veces por el propietario del recurso. El propietario tambin deber liberarlo tantas veces como lo haya tomado previamente. Hay que tener en cuenta que no es posible usar ningn tipo de mutex desde una rutina de interrupcin.
COLAS DE MENSAJES.

El comportamiento de las colas de mensajes en FreeRTOS es tipo FIFO, y pueden contener elementos de cualquier tipo de tamao fijo, que son insertados por copia en la cola, por lo que habr que tener cuidado en la eleccin de los tipos para los mensajes. De igual forma que los otros mecanismos de IPC, las colas de mensajes implementan un timeout para las operaciones. Tambin existen un conjunto de funciones especficas para su manejo desde rutinas de interrupcin.

6.6 RUTINAS DE INTERRUPCIN.

FreeRTOS no impone ninguna estrategia en cuanto al procesado de interrupciones, en este sentido, podemos elegir entre hacer el procesamiento desde dentro de la propia rutina de interrupcin o desde un proceso externo delegado, al que indicaremos la ocurrencia del evento mediante un semforo o una cola de mensajes.

65

Si hay que tener muy presente que dentro de una rutina de interrupcin solo podemos llamar a las funciones de la API y macros que terminan en FromISR o en FROM_ISR. Aunque como hemos comentado antes, FreeRTOS no impone ninguna estrategia en la atencin a las interrupciones, es recomendable, siempre que las restricciones temporales lo permitan, usar un proceso delegado, para intentar tener tiempos de ejecucin de las rutinas de interrupcin lo ms bajos posibles. La tcnica consiste en hacer el mnimo procesado dentro de la interrupcin, por ejemplo guardar el valor de una lectura del conversor A/D, o un byte recibido en una UART (puede verse un ejemplo de esto en la implementacin del driver de la UART), y avisar mediante algn mecanismo de IPC, como pueda ser una cola de mensajes o un semforo, a un proceso encargado de efectuar el procesamiento adicional. Es importante tener en cuenta algunos detalles a la hora de codificar una rutina de interrupcin que pueda provocar un cambio de contexto. Siempre que usemos las funciones de IPC dentro de una rutina de interrupcin tendremos que insertar las macros portENTER_SWITCHING_ISR y portEXIT_SWITCHING_ISR al principio y al final de la rutina de interrupcin. La macro portENTER_SWITCHING_ISR fuerzan la salvaguarda del contexto de ejecucin de la tarea interrumpida, y portEXIT_SWITCHING_ISR hace que se cambi de contexto a una nueva tarea si el planificador as lo requiere por las operaciones efectuadas dentro de la RTI. As mismo, el mecanismo de codificacin de rutinas de interrupcin exige seguir un patrn concreto para evitar problemas con distintas versiones de GCC y opciones de compilacin. La entrada a la rutina de interrupcin se hace a travs de una funcin adaptadora que permite implementar una interfaz compatible con el compilador. El siguiente listado ilustra el proceso:
//Declaramos la funcin envoltorio con el atributo naked void ISR_Wrapper( void ) __attribute__ ((naked)); /* * La funcin envoltorio es el punto de entrada de la RTI * Salva el contexto de ejecucin de la tarea interrumpida * Llama a la funcin donde se implementa el cdigo de tratamiento de la interrupcin * Finalmente restaura el contexto de ejecucin apropiado */ void ISR_Wrapper( void ) { portENTER_SWITCHING_ISR (); portBASE_TYPE xTaskWoken = pdFALSE;

66

xTaskWoken=ISR(); portEXIT_SWITCHING_ISR (xTaskWoken); }

/* * Esta ser la funcin que efecte el tratamiento de la interrupcin * devolver pdTRUE si algn proceso a pasado a preparado dentro de la rutina * pdFALSE en otro caso */ portBASE_TYPE ISR (void) { portBASE_TYPE xTaskWoken; //cdigo de la RTI return(xTaskWoken); }
Listado 2 Codificacin de rutina de interrupcin

6.6.1 ABSTRACCIN DE HARDWARE MEDIANTE DRIVERS.

Un mecanismo que simplifica las operaciones de E/S, mejora el desacoplamiento entre mdulos, y adems fcilmente reutilizable, es la abstraccin del los perifricos mediante drivers. Aunque el concepto de driver no existe en FreeRTOS, dentro de la comunidad de desarrolladores se utiliza este trmino para referirse a un conjunto de rutinas y estructuras que permiten la abstraccin de un determinado perifrico. En FreeRTOS no hay una API o interfaz definida para los drivers, pero en general la implementacin suele hacerse de la siguiente forma: Se define algn mecanismo de IPC para indicar la ocurrencia de un evento, generalmente una cola de mensajes si el perifrico genera datos, como por ejemplo la recepcin de un byte por parte de la UART o la captura de una muestra en el conversor AD. Normalmente, el proceso que espera un dato de un perifrico se bloquear esperando datos de la cola de mensajes recibida. Se define algn mecanismo IPC para efectuar operaciones de salida, generalmente una cola de mensajes, como por ejemplo, el ciclo de trabajo del modulador PWM, un byte a transmitir por la UART, etc. Cuando una tarea quiere escribir datos en un perifrico, solo tiene que enviar el tipo de datos adecuado por la cola del perifrico. Normalmente, si se dimensiona bien el tamao de las colas y el perifrico es relativamente rpido, esta operacin no bloquear a la tarea.

67

Se implementa la RTI del perifrico, en la que se generan los mensajes IPC correspondientes ante la disponibilidad de datos nuevos y se procesan las colas de salidas.

En el captulo 7 puede verse como ejemplo la implementacin de un driver para las UARTs.

6.7 ESTRUCTURA Y COMPONENTES DE UN PROYECTO CON FREERTOS.

En este punto veremos cmo est estructurado el cdigo fuente de FreeRTOS y los proyectos de ejemplos que lo acompaan. Ms adelante veremos la estructura tpica de un proyecto de Eclipse con FreeRTOS.
6.7.1 ESTRUCTURA DEL CDIGO FUENTE DE FREERTOS

El archivo de distribucin de FreeRTOS contiene el cdigo fuente del SO, incluyendo archivos especficos para todas las plataformas soportadas, tambin incluye aplicaciones de demostracin para muchas de estas plataformas as como una carpeta adicional con los ports correspondientes a plataformas no soportadas oficialmente, si no que son contribuciones de usuarios de FreeRTOS. Partiendo del directorio raz de FreeRTOS encontramos tres carpetas principales: License: incluye la documentacin de la licencia de FreeRTOS. Source: esta carpeta contiene el cdigo fuente de FreeRTOS Demo: aqu se incluyen las demos para las distintas plataformas as como el cdigo fuente de las demos y ports no soportadas oficialmente.

68

Figura 26 Directorio de FreeRTOS

Como hemos comentado, la carpeta Source contiene todo el cdigo fuente de FreeRTOS. Su contenido se muestra en la siguiente captura de pantalla:

Figura 27 Carpeta Source de FreeRTOS

El cdigo fuente de FreeRTOS consta de dos partes, una comn a todas las plataformas, y que constituye la mayor parte del ncleo del SO, compuesta por los archivos task.c, list.c y qeue.c, contenidos en la misma carpeta Source. La otra parte es cdigo especfico para cada compilador y cada plataforma soportada, contenida en el directorio portable.

69

El cdigo portable consta bsicamente de las funciones de ms bajo nivel requeridas por el SO para llevar a cavo tareas como salvar el contexto de ejecucin y detalles de la implementacin de los mecanismos de IPC y secciones crticas. La siguiente captura muestra el contenido de la carpeta portable, en la que hay una carpeta por cada compilador soportado:

Figura 28 Carpeta portable de FreeRTOS

Como ejemplo, en la siguiente figura se muestra el contenido de la carpeta GCC, en la que se puede observar que existe una carpeta por cada arquitectura soportada:

Figura 29 Carpeta GCC de FreeRTOS

70

En nuestro caso, el cdigo especfico correspondiente al LPC2148 est contenido en la carpeta ARM7_LPC2000:

Figura 30 Port para LPC2xxx

Como se puede observar, el cdigo especfico se limita a los archivos port.c, portISR.c y portmacro.h.

6.7.2 ESTRUCTURA DE UN PROYECTO CON FREERTOS

Un proyecto con FreeRTOS constara de uno o varios procesos y opcionalmente de algunos drivers para perifricos. Es conveniente siempre codificar cada proceso en archivos independientes, de esta forma no solo aumentamos la legibilidad de la aplicacin, sino que facilitamos la reutilizabilidad de los procesos y/o drivers. El siguiente diagrama recoge los mdulos, dependencias y responsabilidades de un hipottico sistema con un solo proceso y un driver:

71

Figura 31 Diagrama de sistema con FreeRTOS

En este punto veremos los pasos a seguir para crear un proyecto nuevo en Eclipse con FreeRTOS. Aunque existe la posibilidad de crear un proyecto administrado, en el que el makefile se gestiona automticamente, resulta ms prctico y menos propenso a errores utilizar proyectos no administrados y modificar los makefiles manualmente. El primer paso ser crear un nuevo proyecto vaco no administrado de C en Eclipse. Crearemos un makefile para el proyecto, o mejor, reutilizaremos convenientemente modificado uno que ya tengamos de otro proyecto. Importaremos una copia del archivo FreeRTOSConfig.h, que posteriormente personalizaremos para el proyecto. Configuraremos el makefile para incluir la carpeta ./FreeRTOS/Source/include, as como la propia carpeta del proyecto. Aadimos los siguientes archivos en el makefile: task.c queue.c list.c port.c 72

En cada uno de nuestros archivos de cdigo que use la API de FreeRTOS, tendremos que incluir el archivo FreeRTOS.h, y adems el archivo de cabecera que contenga los prototipos de la API que usemos: task.h: funciones de manipulacin de procesos y depuracin. queue.h: funciones de manejo de colas de mensajes. semphr.h: funciones de manejo de semforos y mutes.

Adicionalmente, tendremos que incluir los archivos con las definiciones de registros del LPC2148. En DVD adjunto se incluye un proyecto bsico de Eclipse con FreeRTOS que puede utilizarse como punto de partida para otros proyectos.

6.7.2.1 ESTRUCTURA DE LA FUNCIN MAIN. BUCLE DEL SISTEMA.

En un proyecto con FreeRTOS, normalmente la funcin main() es responsable de las siguientes acciones: Inicializar el hardware. Inicializar y configurar los drivers. Inicializar las estructuras de datos usadas por las tareas, como semforos, colas de mensajes, memoria compartida, etc. Crear las tareas. Inicializar el planificador.

Es notable la no existencia de un bucle del sistema, ya que est funcin la desempaa el planificador. Ser en cada una de las tareas donde se ubicar este bucle. En el CD que adjunto a este documento, puede encontrarse como ejemplo un proyecto mnimo en es que se ilustra este proceso.

6.8 CONFIGURACIN Y OPTIMIZACIN.

Como se ha comentado en puntos anteriores, FreeRTOS permite configurar un conjunto de parmetros para optimizar el sistema operativo al contexto de nuestra aplicacin. El nmero de parmetros es una lista larga, que est bien documentada, por lo que nos limitaremos a comentar los ms importantes.

73

Esta parametrizacin se hace en el archivo FreeRTOSConfig.h, .que generalmente situaremos junto a nuestro cdigo fuente, ya que debe ser especfico para cada proyecto. En este archivo, cada parmetro de controla mediante una definicin. Aunque conviene conocer al detalle toda la lista de parmetros, los ms importantes son: #define configUSE_PREEMPTION: definiendo a 1 este parmetro configuramos el planificador para efectuar planificacin expropiativa. #define configUSE_CO_ROUTINES: definiendo a 1 este parmetro habilitaremos la API de corrutinas. #define configTICK_RATE_HZ: en este parmetro indicamos la frecuencia del tick del sistema. Este parmetro define la granularidad de ejecucin del planificador, y debe ser elegido con sumo cuidado porque todas las funciones temporizadas, como esperas y timeouts de funciones, toman el tick del sistema como tiempo base, y solo pueden efectuarse esperas de mltiplos enteros de este tiempo. #define configTOTAL_HEAP_SIZE: es el tamao de memoria disponible para el kernel para el montculo. #define configUSE_TRACE_FACILITY: definiendo a 1 este parmetro podemos utilizar las macros gancho para trazar la ejecucin de FreeRTOS. Este se ver con ms detalle en el siguiente apartado. #define configCHECK_FOR_STACK_OVERFLOW: este parmetro permite implementar un mecanismo para detector desbordamientos de la pila. Se explica detalladamente en el punto 7.4.

6.8.1 MACROS DE TRAZA

Mediante las macros de traza podemos monitorizar la ejecucin de FreeRTOS. El mecanismo se basa en una serie de macros, inicialmente vacas, en el cdigo de FreeRTOS. Mediante la definicin de ests macros, podemos llevar a cabo alguna accin ante muchos eventos y/o cambios de estados del kernel y/o colas y semforos. Como ejemplo, podemos insertar cdigo en las macros para enviar informacin por un puerto serie (por ejemplo, el evento que ha ocurrido), establecer determinados valores en el conversor DA o en las salidas digitales (por ejemplo para indicar que proceso est en ejecucin).

74

La lista de macros gancho es amplia, hay macros definidas para todos los eventos y cambios de estado de FreeRTOS. La lista completa de macros est documentada en el sitio web de FreeRTOS. Para la definicin de macros de traza solo hay que tener en cuenta un par de consideraciones: Las macros en ocasiones pueden ejecutarse desde una RTI, por lo que deben ser muy rpidas para tener el menor impacto posible en el rendimiento de la aplicacin. La definicin de las macros debe hacerse antes de la inclusin de FreeRTOS.h, siendo recomendable hacerlo en un archivo .h que posteriormente se incluir al final de FreeRTOSConfig.h.

6.9 CONCLUSIONES

Tras estudiar las caractersticas y API de FreeRTOS, podemos concluir que este sistema operativo proporciona todas las funciones necesarias para el desarrollo de sistemas en tiempo real, contando con una API sencilla y reducida. El soporte de mltiples arquitecturas, as como la existencia de versiones comerciales y certificables, representan una clara ventaja frente a otros sistemas operativos, vinculados a plataformas o a herramientas de desarrollo completas. Tambin proporciona herramientas suficientes para la depuracin y optimizacin de las aplicaciones, as como una buena flexibilidad en su configuracin. El hecho de ser de cdigo abierto favorece la implementacin ports para nuevos dispositivos y arquitecturas.

75

76

EJEMPLO DE SISTEMA DE CONTROL EN TIEMPO REAL: AUTOPILOTO PARA UAV

7.1 INTRODUCCIN

En esta seccin veremos la implementacin de un sistema de control medianamente complejo partiendo de un diseo basado en modelos. Analizaremos los requisitos temporales del controlador y mostraremos un mtodo para la verificacin de la implementacin mediante la insercin de sistema real en el lazo de control simulado. A esta tcnica se le suele llamar Hardware in the loop o de forma abreviada HIL. Est tcnica presenta algunas ventajas que hace que este imponindose en los proceso de desarrollo de sistemas, ya que mediante ella se simplifica considerablemente el proceso de validacin y pruebas, ya que en general podremos reutilizar de forma directa las pruebas realizadas sobre los modelos en el entorno de simulacin.
7.2 DISEO BASADO EN MODELOS 7.2.1 INTRODUCCIN

Una de las capacidades fundamentales de todo avin es que ste pueda moverse siguiendo las rdenes de un piloto o un sistema que se encargan de generar las consignas que se desean seguir. El sistema de control del avin sobre sus tres ejes fue una de las contribuciones de los hermanos Wright, y ya entonces, su Flyer dispona de timn de profundidad, timn de direccin y de un sistema de torsin de las alas que produca el alabeo. Las superficies de mando y control modifican la aerodinmica del avin provocando un desequilibrio de fuerzas permitiendo que una o ms de ellas cambien de magnitud. Este desequilibrio, es lo que hace que el avin se mueva sobre uno o ms de sus ejes, incremente la sustentacin, o aumente la resistencia. En la figura se pueden observar los tres ejes de un avin y los movimientos sobre ellos.

77

Figura 32 Ejes cuerpo de una aeronave

Las superficies de control son principalmente tres: alerones, timn de profundidad (elevador) y timn de direccin (rudder). A partir de estas superficies se pueden hacer combinaciones de ellas, como por ejemplo los elevons que seran la combinacin del elevador y los alerones. En la siguiente figura se representa el esquema general del sistema. Podemos observar Podemos un generador de referencias, ste es el encargado de indicar el modo de vuelo que se indicar quiera realizar y la referencia que quiere alcanzarse en l, estas consignan se trasladarn al control de bajo nivel el cual tendr como misin modificar las superficies de control y el motor para llevar al avin al estado dese deseado.

Figura 33 Diagrama de control de una aeronave

Los controladores se han diseado especficamente para el UAV Viewer Se trata de un Viewer. sistema areo de supervisin robusto, ligero y de fcil transporte, diseado para istema labores de Inteligencia, Observa Observacin y Reconocimiento. El Viewer destaca por su gran capacidad de carga de pago (2Kg) frente a su peso (8 Kg), manteniendo una propulsin 78

elctrica tipo brushless de 1200 W de potencia con bajo impacto sonoro. Puede realizar misiones de ms de 1 hora de vuelo (autonoma de 75 a 90 minutos) con un radio de accin de 45 km. Su altura operacional es de 300 metros y puede alcanzar hasta 1500, su velocidad de operacin est comprendida entre los 40 y los 110 km/h.
7.2.2 ESBOZO SOBRE ESTABILIDAD Y CONTROL DE LA AERONAVE

La estabilidad estudia el comportamiento del avin cuando una perturbacin o entrada de control lo separa de las condiciones de equilibrio. Dentro de la estabilidad podemos encontrar la estabilidad esttica, la cual es el anlisis del sentido o signo del momento aerodinmico total que desarrolla el avin despus de separarse de las condiciones de equilibrio y que segn la respuesta podr ser: -Estable: el avin por si mismo desarrolla los momentos aerodinmicos necesarios para retornar a la situacin primitiva de equilibrio. -Inestable: los momentos desarrollados tienden a separar al avin de la condicin de equilibrio. -Neutro: el avin estar en equilibrio en esta nueva situacin. Otro tipo de estabilidad es la dinmica, sta estudia el tipo de movimiento oscilatorio a que darn lugar a lo largo del tiempo los momentos desarrollados por el avin. Cuando el avin se separa del equilibrio y es estticamente estable, oscilar sobre la situacin inicial, aunque esto no es suficiente para que vuelva al equilibrio ya que segn el efecto final existirn tres tipos de estabilidad dinmicas: convergente, divergente e indiferente.
7.2.3 ESTABILIDAD Y CONTROL LONGITUDINAL

Se refiere al comportamiento del avin en sus movimientos de cabeceo (pitch) alrededor del eje OY. Para que exista estabilidad esttica se deben desarrollar los momentos que lleven al avin al punto de compensacin, entendindose ste como el ngulo para el cual el coeficiente del centro de gravedad es nulo. Por ejemplo, si el aire levantara el morro del avin, se debera desarrollar un momento de picado que contrarrestara esto. En cuanto a la estabilidad dinmica nos encontramos con dos posibles modos de oscilacin, siendo estos los autovalores de la matriz dinmica del avin: -Phugoid Mode: es la pareja de polos complejos conjugados que tiene baja frecuencia y consiste en una oscilacin del orden de medio minuto y un tiempo de amortiguacin grande (minutos). En este tiempo el ngulo de ataque permanece constante y se 79

intercambia peridicamente energa cintica (velocidad) por energa potencial (altitud). -Short Period Mode: es la pareja de polos complejos conjugados con alta frecuencia y consiste en un movimiento oscilatorio fuertemente amortiguado. En la ilustracin se puede ver un ejemplo de estos modos:

Figura 34 Modos de oscilacin longitudinal

En lo referente al control, la actitud del avin en el cabeceo se consigue haciendo aumentar o disminuir la sustentacin que proporciona el conjunto horizontal de cola, en este caso el elevador. Por ejemplo, cuando el elevador se desplaza hacia abajo se genera sustentacin hacia arriba subiendo la cola y transmitiendo un momento de picado del avin.

7.2.4

ESTABILIDAD Y CONTROL LATERAL-DIRECCIONAL

Trata el comportamiento del avin en sus movimientos de alabeo y de guiada. Debido a que existe acoplamiento entre ambos se estudian conjuntamente y se puede encontrar los siguientes modos: -Divergencia espiral: este modo es muy rpido e inestable. Sucede cuando la estabilidad direccional es mucho mayor que la lateral, el avin tiende a entrar en un picado horizontal cada vez ms pronunciado.

80

-Dutch Roll Mode (Balanceo del holands): Este es modo con una gran oscilacin en el que todas las variables de la dinmica lateral oscilarn. En este caso predomina la estabilidad lateral sobre la direccional, cualquier perturbacin inicial de balanceo o guiada pone en juego una oscilacin latero-direccional. Ambas frecuencias de las oscilaciones son similares pero tienen un pequeo desfase en el que precede la lateral a la direccional. Existen otros modos pero no son tan comunes y estos dos son los ms necesarios de controlar. La actitud perseguida se conseguir mediante la deflexin asimtrica de los alerones. Partiendo de la situacin de crucero, si se alabea hacia la derecha se deben deflectar los alerones para que baje el de la semiala izquierda, as aumenta su sustentacin y, al subir el del semiala derecha y bajar la sustentacin de sta, generar el momento deseado.
7.2.5 ESBOZO DEL DISEO DEL CONTROLADOR DEL VIEWER

El proceso a travs del cual se disearon los controladores del Viewer es el siguiente: 1) Se buscaron matemticamente, mediante el estudio del lugar de las races en Matlab, los parmetros adecuados para que el modelo lineal tenga un comportamiento deseado. 2) Se refinaron estos controladores, matemticamente obtenidos, a travs de simulaciones del modelo no lineal mediante Simulink. 3) Una vez obtenidos los controladores en tiempo continuo, se discretizaron y volvieron a refinarse de nuevo en Simulink. 4) Como ltimo paso se prueban en el sistema real y terminan de ajustarse.

81

7.3 MODELADO DEL SISTEMA DE CONTROL

Para el diseo del sistema de control se modelo el sistema completo.

Figura 35 Diagrama de alto nivel del sistema

Dicho modelo consta de tres bloques principales: Modelo de la aeronave Generacin de referencias Controladores

82

7.3.1 MODELO DE LA AERONAVE

El modelo de aeronave modela las caractersticas dinmicas de UAV Viewer. Para el diseo de este modelo se han usado los bloques proporcionados por Aerosim.

Figura 36 Modelo de la aeronave

En la siguiente figura podemos ver el contenido de este subsistema:

Figura 37 Detalle del modelo de la aeronave

83

El bloque Aerodinamics calcula los momentos y fuerzas aerodinmicos. Este bloque pertenece al Aerosim toolset, y ha sido parametrizado segn los coeficientes dinmicos a partir de las derivadas d estabilidad del Viewer. de

Figura 38 Modelo de clculo aerodinmico

El bloque Propulsin model calcula la fuerza y el momento de empuje producido por el ropulsin sistema de propulsin, compuesto por el motor elctrico y la hlice.

84

Figura 39 Modelo del sistema de propulsin

El bloque Aircraft Inertia recoge la matriz de inercia del avin. Esta matriz solo depende la geometra del cuerpo. El bloque Equations of Motion implementa las ecuaciones que permiten tr transformar las fuerzas y momentos a las variables especificadas en los puertos de salida que aparecen a la derecha de la figura.

Figura 40 Ecuaciones del movimiento

El bloque Earth es un modelo de la Tierra. Para obtener una simulacin de las variables acin que afectan al avin es necesario tener en cuenta los cambios producidos en stas por el modelo de la Tierra. De esta forma y ya que la Tierra no es esfrica sino que se modela como un elipsoide, se tendr que dependiendo de la posicin en la cual se posicin 85

encuentre el avin se tendr un determinado campo magntico, radio local, gravedad y nivel del mar sobre el que medir la altitud. Para calcular el campo magntico tambin se usar la posicin del avin y el modelo del campo magntico terrestre.

Figura 41 Modelo de la tierra

El bloque Atmosphere calcula una estimacin de los parmetros del aire y calcula los efectos del viento. La atmsfera estndar vendr representada por la presin esttica, la temperatura, la densidad del aire y la velocidad del sonido, todo ello puede ser medido a partir de la altitud sobre el nivel del mar. Para el viento se aplicar una transformacin desde el plano inercial al de ejes cuerpo, se computan tambin las derivadas en el tiempo del vector velocidad y de esta manera tiempo se pueden capturar los efectos variantes con el tiempo del viento.

86

Figura 42 Modelo de la atmosfera

Finalmente, indicar que todos los parmetro del modelo se cargan de el archivo viewerconfig.mat el cual contiene las caractersticas aerodinmicas, caractersticas de la hlice y el motor y la matriz de inercia de la aeronave, de esta forma podemos modificar fcilmente los parmetros del modelo.

7.3.2

BLOQUE DE GENERACIN DE REFERENCIAS (HIGHT LEVEL)

Una de las partes ms importantes de todo vehculo areo es la que corresponde a la generacin de las referencias que ste deber seguir para conseguir alcanzar un comportamiento determinado. Por ello, debe de existir un mdulo que permita traducir el plan a seguir del avin a las variables sobre las que los controladores de bajo nivel actuarn para proporcionar en las superficies deflectoras del vehculo la posicin que permita llegar al objetivo.
7.3.2.1 ENVOLVENTE DE VUELO Y GENERACIN DE REFERENCIAS

La envolvente de vuelo la conforman el conjunto de actitudes crticas que un avin nunca debera sobrepasar puesto que podra perderse el control de ste y acabar en desastre. Generalmente en el diseo de esta envolvente se deja un margen entre el rango mximo que no se debe superar y los valores crticos de las variables, de esta o forma si en algn momento se sobrepasaran, quedara alguna posibilidad de llevar de nuevo al avin a una actitud segura. En el diseo del sistema de control de un vehculo areo no tripulado (UAV), se habr tripulado de tener en cuenta que al crear las referencias para alcanzar un objetivo determinado, no deberan superarse las condiciones crticas del vehculo. Por ejemplo, deber de buscarse que est siempre entre la velocidad mxima y mnima, que los ngulos de mnima, 87

viraje no sean excesivos, que el ngulo de pitch no sea tal que haga entrar en prdida al avin, etc. En la ilustracin aparecen las principales variables a tener en consideracin para no sobrepasar la envolvente de vuelo.

Figura 43 Envolvente de vuelo

No slo es importante respetar estos valores, sino que es conveniente que al generar las referencias stas no se generen de una manera brusca, un ejemplo de esto sera la introduccin de un escaln de gran amplitud en relacin con la magnitud de la variable amplitud a controlar. Esto se debe a que si introducimos un salto en la referencia, el servo lo seguir dando un cambio muy brusco en la superficie deflectora y por tanto haciendo que las variables de estado cambien sbitamente, provocando oscilaciones y por tanto un comportamiento indeseado que podra llegar a ser incontrolable. Para evitar esto, en la generacin de referencias se ha implantado un pequeo bloque que se encargue de incrementar o decrementar la referencia de una forma lineal y por referencia otra parte se ocupa de que jams se sobrepase la envolvente de vuelo. En la figura se observa un ejemplo de cmo se ha implementado en Simulink este bloque:

Figura 44 Limitacin de referencias

lustracin La ilustracin muestra como se genera la referencia de altitud para los controladores de bajo nivel a partir de la altura que se quiere alcanzar: Por una parte se tiene como 88

entradas la altitud que se quiere alcanzar y la altitud del UAV en ese momento, se calcula la diferencia entre ambos y se satura a una diferencia mxima, la cual se suma a la altitud actual. De esta manera cuando existan grandes escalones entre la posicin actual del avin y la deseada, la referencia a seguir por los controladores ir variando a medida que el UAV vaya realizando la maniobra, de esta forma los errores con los que trabajan los PIDS de los controladores, no sern excesivos y por lo tanto no provocarn acciones bruscas en los servos que mueven las superficies de navegacin. Por otra parte, se puede observar tambin en la figura 4 como antes de entregar finalmente la referencia deseada, sta pasa por un saturador que ser el encargado de que esta referencia est dentro de los lmites permisibles dentro de la envolvente de vuelo. Con este sencillo mtodo se consigue que el avin quede siempre dentro de las condiciones estables de vuelo y que se puedan alcanzar a las actitudes deseadas de una forma suave.
7.3.2.2 MODO DE VUELO

En todo sistema de guiado es imprescindible que exista la oportunidad de seguir una ruta determinada, en este caso la ruta ser indicada mediante waypoints, los cuales podrn estar dados por: -Sistema NED: Est dado en metros y el origen de referencia es fijado en la superficie de la tierra, preferiblemente en el lugar desde el que el UAV comienza el movimiento. En l, el eje Y apunta al norte, el eje X apunta al este y el Z hacia abajo. -Latitud, longitud y altitud. El UAV mediante una ley de seguimiento de trayectorias, que ser vista en el siguiente apartado, tratar de alcanzar el siguiente waypoint. Se generarn referencias para que los controladores de la dinmica lateral puedan hacer que el UAV alcance los puntos deseados en el eje XY. A la vez el controlador longitudinal (elevador) tratar de alcanzar la altitud especificada para dichos puntos. Por otra parte cabr la posibilidad de especificar la velocidad a la que se desea realizar esta ruta, el encargado de que esto sea posible ser el motor, por lo que es a ste al que le llegar la referencia de velocidad. En el modelo creado en Simulink llamado High_Level.mdl se encuentra el bloque que permite configurar esta ruta y sus caractersticas y cuadro de dilogo se muestran en la figura.

89

Figura 45 Configuracin de waypoints y velocidad

En este caso se desea que cuando el UAV llegue al ltimo punto de su ruta vuelva al primero.
7.3.2.3 SEGUIMIENTO DE TRAYECTORIAS

En este apartado se explicar la ley que se ha implementado para generar un yaw rate que permita llegar al siguiente waypoint. Tambin se mostrar el mdulo que especifica cuando se ha alcanzado el objetivo y en qu momento se ha de ir al siguiente.
LEY DE CONTROL

La ley que se ha implementado trata de llevar al UAV al siguiente Waypoint (Wp2) a lo largo de la lnea que une al Wp1 y el Wp2. La posicin y velocidad del vehculo pueden estar dadas, como se especific anteriormente, tanto en un plano de referencia <Norte, Este> como en coordenadas latitud y longitud. La nomenclatura utilizada ser la mostrada en la siguiente tabla.

90

Nomenclatura. Xtrack Ytrack Xtrack=Xtrack/t Ytrack=Ytrack/t U W rCMD

= (U,YNORTH) w = (W ,YNORTH)
12 = (Wp1 ,Wp 2 , YNORTH )

Significado. Mdulo de la distancia entre Wp1 y Wp2 (m). Distancia lateral a lnea que une los waypoints(m).(Cross track) Velocidad en ejes track (m/s). Velocidad Cross-track (m/s). Vector velocidad del UAV (m/s). Vector viento (m/s). Yaw-rate requerido (rad/s). Heading (rad). Direccin del viento (rad). Heading de la lnea de la trayectoria (rad).

Tabla 13 Variables para el clculo de trayectorias

La matriz de rotacin que permitir transportar la posicin del avin al sistema de ejes <Xtrack,Ytrack> ser la siguiente :
cos( 12 / 2) sin( 12 / 2) T = sin( / 2) cos( / 2) 12 12

Por lo tanto es posible obtener el siguiente resultado:

r r r r Utrack = TU y Wtrack = TW de esta manera el modelo cinemtico del UAV puede

ser expresado mediante las siguientes ecuaciones no lineales:

& X track = U cos( (t ) 12 ) + W cos( w 12 ) & Ytrack = U sin( (t ) 12 ) W sin( w 12 )

& (t) = rCMD(t)

La estrategia de control consistir en apuntar el vector Velocidad (Ground Speed) en la direccin de la lnea que une los waypoints para interceptar a sta en el punto C. Este punto est determinado por el parmetro k, donde la distancia desde el Wp2 hasta el punto C es en todo momento (1-k)Xtrack. Esta estrategia est basada en el establecimiento de la posicin y la velocidad mediante la siguiente relacin:
& & X track Ytrack & & = donde el error vendr dado por e = X track Ytrack kX track Ytrack y debe kX track Ytrack

ser conducido a 0, para ello se genera un yaw rate proporcional a este error y se satura 91

a (+0.25, -0.25) rad/s ya que velocidades angulares mayores a este valor podran ser crticas para el UAV al comandar un giro demasiado rpido. Aparte se ha introducido un filtro para contrarrestar la dinmica lenta del vehculo y tras ste se ha transformado el yaw rate a una referencia en roll la cual ser seguida por los controladores de bajo nivel. En el UAV implementado el parmetro K se ha puesto a 1 ya que es el que ofrece las respuestas ms suaves al no obligar al vehculo a alinearse con la lnea de trayectoria cortando esta en el punto especificado por C, sino que en todo momento lo que se apuntar es al Waypoint destino y se tratar de pasar por l. Sin embargo sera tambin muy factible el escoger otros valores para K, por ejemplo para distancias largas podran usarse K=0.5, por lo que se tratara de alcanzar un error lateral igual a 0 a mitad de camino y hace que el UAV siguiera la lnea que une ambos waypoints. Para la ganancia proporcional al error que genera el yaw rate ocurre lo siguiente: Las ganancias para distancias cortas (del orden de 102m) han de ser mayores que las que pertenecen a distancias ms largas (orden 103 m), ya que si se usase la misma, al existir errores grandes en Xtrack o Ytrack, se generara un yaw rate tan grande que terminara por ser saturado y el avin comenzara a dar vueltas. Por este motivo se ha utilizado una ganancia dinmica, que depender del mdulo de la distancia entre los waypoints inicial y destino, de esta manera el UAV realizar la maniobra de una manera ptima independientemente de la distancia que halla entre los puntos de su ruta.
BLOQUE DE GENERACIN DE TRAYECTORIA.

Para poder aplicar la ley de control expuesta en el anterior subapartado, existe un mdulo que indica en todo momento entre qu waypoints se encuentra el UAV, cundo debe girar y la ganancia que corresponde a dicho tramo. Para ello se ha creado una funcin en Matlab denominada Track que podr encontrarse en el apndice 1 de una forma ntegra para comprender de una forma mejor cmo funciona. Aqu se esbozar un resumen de su funcionamiento. 1-Recibe el vector con la posicin del UAV y todos los waypoints. 2-Calcula el error de posicin y cuando ste es menor que una determinada ley (sta depende de la magnitud del giro a realizar para el siguiente waypoint y el Xtrack del tramo actual) entonces comienza el giro. De esta manera se suavizan las trayectorias realizadas por el UAV. Si se ha llegado al ltimo waypoint se volver al primero. 3-Calcula la constante proporcional que multiplicar al error dado por la ley de control. 4-Genera las salidas siguientes: Coordenadas de los waypoints entre los que se encuentra el avin, altura a seguir en este tramo y la constante proporcional para el yaw rate. 92

EJEMPLO DE SEGUIMIENTO DE RUTA.

A continuacin se expondr un ejemplo de cmo seguira una ruta en la que se alternan distancias largas y cortas entre waypoints para comprobar cmo efectivamente la ley de control y el generador de trayectorias funcionan correctamente. Los Waypoints a seguir son: Vector de Xe: [0, 400, 800, 2600, 2000, -3000,-1200] Vector de Ye: [0, 0, 500, 700, 1500, 4000, 1000] Vector de Alturas: [1000,1000, 1000, 1050, 1050, 1100, 1100] En este ejemplo se comienza a una altura de 1000 metros desde el punto (0,0), a una velocidad de 23 m/s (durante el trayecto el UAV ir a 24 m/s), y se ha decidido que gire antes de llegar a los waypoints de tal manera que mientras mayor sea el giro a realizar para el siguiente destino, antes se realizar dicho giro. Esta es una ley que podr cambiarse simplemente modificando las constantes del cdigo para el cambio de waypoints. La ilustracin muestra los waypoints y el recorrido del UAV.

4000

3500

3000

2500 Ynorte(m)

2000

1500

1000

500

-500 -4000

-3000

-2000

-1000 Xeste (m)

1000

2000

3000

Como es posible de observar el UAV sigue la ruta pasando por todos los waypoints excepto el que se encuentra en (-3000, 4000), esto no es un error sino que al ser un giro muy grande el UAV por la ley introducida para el cambio de waypoints comenzar 93

su giro antes. Esto, como se ha expresado hace un momento, puede cambiarse e incluso anularse. A continuacin se mostrar en las cmo se alcanzan las alturas y el cambio en la constante que multiplicar al error para la generacin del yaw rate deseado.

1120

1100

1080

1060 Altitud(m)

1040

1020

1000

980

100

200

300

400 Tiempo (s)

500

600

700

800

Figura 46 Altura

x 10

-3

-0.5

-1 Ganancia (k) -1.5 -2 -2.5 0

100

200

300

400 Tiempo (s)

500

600

700

800

Figura 47 Ganancia dinmica

94

Como es posible observar, la altura se sigue perfectamente y la ganancia proporcional es mayor en valor absoluto para distancias cortas que para las largas, lo que permite seguir los waypoints de una manera correcta.
7.3.2.4 IMPLEMENTACIN EN SIMULINK

Figura 48 Modelo de alto nivel de generacin de referencias

En el subsistema Modo 1 se generan y limitan las referencias de alto nivel (waypoints y velocidad). Todos los clculos sern tratados por el mdulo Guidance, que estar formado por: Bloque High level 1-4: en su interior se implementan las operaciones para calcular las referencias de bajo nivel. Salidas: entrega al sistema de bajo nivel (control de actuadores) las referencias. 95

De estos bloques el que ms elaboracin conlleva es el que trata los modos de vuelo 1, se ilustra en la siguiente figura:

Figura 49 Bloque Guidance

7.3.3 CONTROLADOR DE BAJO NIVEL

En el bloque Control System1 se implementan los controladores de bajo nivel para el Viewer.

Figura 50 Controlador

Este es el mdulo que implementaremos en el microcontrolador. Las entradas de este subsistema son las siguientes: States: el controlador utiliza como entradas las medidas dinmicas del estado de la aeronave. En un sistema inercial estas medidas las proporciona una unidad de medida inercial y un GPS. Normalmente los datos generados por estos sensores suelen procesarse median un filtro de Kalman que nos proporcionar una estimacin de la posicin y actitud mejor que la que pueden 96

proporcionar ambos sensores por separado, especialmente si se utilizan girscopos y acelermetro de baja precisin, como pueden ser los dispositivos basados en sensores MEMS, que por su reducido tamao y peso, son los nicos que pueden montarse en un AUV de las dimensiones del Viewer. Lat Ref: referencias de latitud y longitud, si se utilizan ejes GWS, o metros en los ejes X e Y si se utiliza un sistema de referencia local. Th Ref: referencia de velocidad. Elev ref: referencia de altitud.

Dentro del subsistema estas entradas se formatean para pasarlas a bloque AP/AT, donde se implementan los controladores.

Figura 51 Modelo de alto nivel del controlador

El contenido del subsistema AP/AT se muestra en la siguiente figura:

Figura 52 Detalle del subsistema AP/AT

97

Como se puede observar, tenemos tres controladores de alto nivel: Throttle: este controlador regual la potencia aplicada al motor para conseguir alcanzar o mantener la referencia de velocidad de entrada. Autopilot: este controlador regulla la altura de la aeronave. Se ha llamado autopilot ya que clsicamente la nica funcin de los autopilotos era la de mantener la altitud. Lateral: controla la dinmica lateral de la aeronave. En los siguientes apartados veremos la implementacin de cada uno de los controladores.
7.3.3.1 SUBSISTEMA THROTTLE

Como se ha comentado anteriormente, este controlador acta sobre el motor para intentar mantener la referencia de velocidad proporcionada por el subsistema hight level.

Figura 53 Subsistema Throttle

La salida de este subsistema est saturada para intentar mantener la aeronave dentro de su envolvente de vuelo segura. La implementacin se ha hecho mediante un controlador PID:

98

Figura 54 Controlador de Throttle

Las entradas de este controlador son: Velocidad de referencia: proporcionada por el modulo higth level. Velocidad de la aeronave: proporcionada por el modelo de la aeronave.

7.3.3.2 SUBSISTEMA AUTOPILOT

Este controlador mantendr la altitud de la aeronave segn la referencia proporcionada por el modulo higth level. La salida de este sistema actuara sobre el elevador del avin. Est compuesto por dos subsistemas: Altitude to pitch: generara un pitch para alcanzar la altura necesaria. Pitch hold Attitude & SAS: implementa un controlador para mantener el pitch y un sistema de aumento de la estabilidad.

Figura 55 Subsistema Autopilot

99

La implementacin del subsistema altitude to pitch es la siguiente:

Figura 56 Modelo de de Altitude to Pitch

El subsistema Pitch Hold Attitude & SAS est compuesto a su vez por dos subsistemas: Pitch attitude hold: encargado de mantener el pitch de referencia SAS: es un control proporcional de aumento de la estabilidad que bsicamente lo que hace es corregir la salida del elevador en funcin de la medida instantnea de pitch rate para tratar de compensar pequeas perturbaciones en el pitch debidas a turbulencias.

Figura 57 Subsistema Pitch hold attitude & SAS

La implementacin del controlador Pitch attitude hold es la siguiente:

100

Figura 58 Pitch attitude hold

El objetivo de este controlador ser hacer llevar el pitch al valor de la referencia tratando que la oscilacin de la respuesta mnima, tratando que el error en rgimen permanente sea nulo o muy pequeo y que la respuesta sea rpida. Para ello, partiendo del lugar de las races, se estudiaron los distintos controladores que se podran aplicar para que los polos dominantes se encuentren en un lugar que nos interese.

7.3.3.3 SUBSISTEMA LATERAL

Este controlador es uno de los ms importantes ya que permite mantener el UAV a un determinado heading. Para realizarlo hay que tener en cuenta que el rudder debe de estar coordinado con los alerones para realizar en todo momento una compensacin del giro. Una coordinacin o compensacin de giro se define como una aceleracin lateral del avin nula (aceleracin inercial en el eje cuerpo Y igual a 0).

Figura 59 Subsistema Lateral

101

Como puede observarse, este subsistema est compuesto de dos controladores de bajo nivel (Roll Autopilot & SAS y Yaw Autopilot), responsables del control de la dinmica lateral del avin. En un giro coordinado el avin mantendr el pitch y roll con respecto al sistema de coordenadas de referencia, pero su heading cambiar continuamente a una velocidad constante, por lo que las derivadas del roll y el heading sern nulas. El subsistema Roll Autopilot & SAS implementa un sistema de aumento de la estabilidad, con el mismo propsito que los implementados en los otros controladores, y el controlador Roll Attitude Hold, que controla la accin de los alerones para establecer el roll proporcionado como referencia por el mdulo Higth level.

Figura 60 Roll autopilot

La implementacin del controlador Roll Attitude Hold es la siguiente:

Figura 61 Roll attitude hold

Para que los giros estn coordinados se realiza una realimentacin al rudder de la aceleracin lateral para que sean cero.

102

Figura 62 Yaw autopilot

En cuanto a la realimentacin de la aceleracin lateral, se pretende que sta sea 0 en el menor tiempo posible, por ello una idea comn en el control de este bucle es realizar un PI o PID que aumente la velocidad del sistema sin llegar a inestabilizarlo y permita un error en rgimen permanente de 0.

Figura 63 Ay to rudder

7.4 VERIFICACIN DEL DISEO MEDIANTE PRUEBAS HARDWARE IN THE LOOP (HIL)

Los sistemas de avinica, especialmente los sistemas de navegacin y control de vuelo son unos de los sistemas ms crticos en una aeronave, si cabe an ms en una aeronave autnoma. Por ello, conseguir probar dichos sistemas en el entorno ms realista posible es un proceso fundamental. Un elemento esencial para hacer simulacin realista es integrar el hardware real dentro del entorno de simulacin, ya que la experiencia nos dice que no siempre un resultado obtenido en el entorno de simulacin se comporta de igual manera al 103

implementarlo en el hardware final, y/o al integrarlo con el resto de subsistemas. Esto es debido a las complejas interacciones entre el hardware y el software, que no siempre son consideradas por los entornos de simulacin. Adicionalmente, en un sistema complejo, como lo es el sistema de navegacin de una aeronave, la complejidad de estas interacciones se extiende por lo general a todos los subsistema que cooperan en la aeronave. Mediante las pruebas del sistema final integrado en el entorno de diseo y simulacin es posible realizar verificaciones de comportamiento en mltiples escenarios, de esta forma es posible la identificacin de ms problemas potenciales que mediante la aplicacin de pruebas por separado al hardware y al software.
7.4.1 METODOLOGA EMPLEADA

Partimos de nuestro modelo de diseo, compuesto por tres subsistemas: Modulo de control: realiza la accin de control sobre la aeronave de forma que esta permanezca dentro de su envolvente vuelo estable. Modulo de navegacin: proporciona las referencias al mdulo autopiloto, bsicamente, la ruta que debe seguir. Modelo de la aeronave: implementa el modelo dinmico de la aeronave, siendo este modelo la planta del sistema de control.

El subsistema que se codificar ser el mdulo de control, que realiza la accin de control sobre el avin. Es sistema est compuesto de varios subsistemas que realizan la accin de control sobre las superficies de control que determinaran en definitiva la actitud de la aeronave. Como se vio anteriormente, cada uno de estos subsistemas est compuesto de uno o varios controladores. Para la integracin del sistema implementado en el hardware definitivo, se enviaran desde Simulink los estados y las referencias requeridas por los controladores mediante un puerto serie. As mismo, las salidas de los controladores se enviaran por el puerto serie a Simulink donde se aplicarn al modelo del avin. En la siguiente figura se muestra el modelo utilizado para la simulacin HIL:

104

Figura 64 Modelo de pruebas HIL

En la siguiente ilustracin se represente un esquema de la configuracin para la simulacin HIL:

105

Figura 65 Diagrama comunicaciones con el microcontrolador

Adicionalmente, para obtener una visualizacin visual del comportamiento del sistema, se utilizar el simulador de vuelo FlighGear, el cual se comandar por UDP desde Simulink con un mdulo disponible para tal propsito. Como sabemos, Simulink no es un entorno de simulacin en tiempo real. Sin embargo, podemos hacer una buena aproximacin bajo ciertas condiciones empleando el modulo RTMatlab. Este mdulo bsicamente lo que hace es controlar el tiempo de ejecucin de la simulacin, de esta forma, si el clculo el tiempo de simulacin del sistema es ms rpido que el tiempo real, con este bloque podemos conseguir relentizarlo hasta aproximarse a tiempo real. Para la simulacin HIL, utilizaremos el bloque de comunicaciones serie en modo bloqueante, con un timeout bajo. De esta forma tambin conseguimos relentizar la simulacin hasta aproximarla a tiempo real.

106

7.5 IMPLEMENTACIN DEL CONTROLADOR EN UN MICROCONTROLADOR NXP LPC2148 CON FREERTOS 7.5.1 ARQUITECTURA SOFTWARE

La aplicacin se compone de los siguientes mdulos: Proceso de control: ejecuta el algoritmo de control, enviando los resultados a travs del puerto serie. Proceso de comunicaciones con Simulink: este proceso se encarga del parseo de los datos procedentes de Simulink, almacenndolos en la memoria compartida. Memoria compartida: la comunicacin de las referencias de control entre el proceso de comunicaciones y el proceso de control se realiza a travs de una estructura compartida. El acceso a esta estructura est protegido mediante un mutex. Driver UART: Este mdulo abstrae el acceso al hardware de la UART, proporcionando un buffer de entrada y salida adicional al presente en el hardware.

La siguiente figura ilustra las relaciones entre los distintos mdulos que componen la aplicacin:

Figura 66 Relacin entre componentes software

107

Cada uno de los procesos utilizar distintos servicios del sistema operativo, para la temporizacin de la ejecucin y las comunicaciones entre procesos. La siguiente figura esquematiza las dependencias de los procesos con la API de FreeRTOS:

Figura 67 Relacin entre la API de FreeRTOS y los procesos

La estrategia de tiempo real seguida es de tipo best effort. El proceso de control se ejecutar de forma determinista independientemente del proceso de comunicaciones con Simulink, de esta forma se garantiza la salida de control dentro del deadline an cuando pueda ocurrir un error o un retraso en el proceso de comunicaciones con simulik. As mismo, el driver de la UART proporciona funciones no bloqueantes tanto para la transmisin como para la recepcin por el puerto serie, limitndose el procesamiento al contexto de las RTI de la UART utilizada. 108

7.5.2

IMPLEMENTACIN DE LOS CONTROLADORES

En los siguientes puntos veremos cmo se ha efectuado la implementacin de los controladores vistos anteriormente. Todos los controladores se ejecutan dentro del proceso de control (vTaskControlador), que llamar de forma secuencial a cada uno de ellos, enviando la salida mediante el driver de la UART.
7.5.2.1 BUCLE PRINCIPAL DEL PROCESO DE CONTROL

A continuacin se presenta el listado del bucle principal del proceso:

portTASK_FUNCTION( vTaskControlador, pvParameters ) { ( void ) pvParameters; int reduct=0; Get_Sem_est_control(&xEstadosSem); //obtenemos el semforo para el acceso a memoria compartida while(1) //bucle infinito { vTaskDelay(10); //El controlador se ejecutara cada 10ms if(xSemaphoreTake( xEstadosSem,portMAX_DELAY)==pdTRUE) //Obtenemos acceso a memoria compartida { memcpy(&estados,&IN_est_control,sizeof(TEstado)); //Copiamos los datos a una variable local para no bloquear a otros procesos memcpy(&control,&IN_ref_control,sizeof(TRefs_Control)); xSemaphoreGive(xEstadosSem); //Liberamos la memoria compartida } Potencia(); //Procesamos el controlador de velocidad Elevador(); //Procesamos el controlador de altitud Alerones_Deriva(); //Procesamos el controlador de heading if(reduct==3) //Diezmamos la salida para no saturar a Simulink { reduct=0; SendControl(); //Enviamos la salida a la cola del driver de la UART } else { reduct++; } } }
Listado 3 Bucle principal del proceso de control

Como puede observarse, el bucle principal se limita a controlar la temporizacin de la ejecucin y a llamar a cada una de las funciones en las que se implementan los distintos controladores.

109

7.5.2.2 CONTROLADOR DE VELOCIDAD

En este controlador se implementa el subsistema throttle. El modelo de este controlador es el siguiente:

Figura 68 Controlador de velocidad

Recordemos que esta salida estaba saturada para no violar la envolvente de vuelo:

Figura 69 Saturacin del control de velocidad

La codificacin de este controlador es directa, tal y como puede apreciarse en el siguiente listado:
void Potencia() { float ferr; float r1,r2,r3; static float d1[2]; static float d2; ferr=control.troRef-estados.Vtas; SATURA(ferr,0.5) //Saturacin simetrica a +-0.5 //Implementacin del controlador

110

r1=PRM_ganancias.VelP1*ferr; r2=r1; r3=(d1[1]*PRM_ganancias.VelP3)+r2; OUT_control.throttle=(r3*PRM_ganancias.VelP4)+d2; d1[1]=d1[0]; d1[0]=ferr; d2=OUT_control.throttle; OUT_control.throttle=ferr; //Saturacin de la salida if(OUT_control.throttle>1.0) { OUT_control.throttle=1.0; } else if(OUT_control.throttle<0.0) { OUT_control.throttle=0.0; } }
Listado 4 Controlador de velocidad

7.5.2.3 CONTROLADOR DE ALTITUD

Este controlador implementa el subsistema Autopilot. Este modelo est compuesto a su vez por dos subsistemas, Altitude to pitch y Pitch hold Attitude. Sus modelos son:

Figura 70 Altitude to pitch

111

Figura 71 Controlador de pitch

Recordemos que el subsistema Pitch hold Attitude tiene su salida saturada y que implementa un sistema de aumento de la estabilidad:

Figura 72 Saturacin del control de pitch

La codificacin es la siguiente:
void Elevador() { float ferr; float r1,r2,r3; static float d1; static float d2; AlturaToPicth(); //Procesamos Altura to picht //Implementacin de pitch hold attitude ferr = pitch-estados.pitch; r1=ferr*PRM_ganancias.AHK1; r2=(d1*PRM_ganancias.AHK2)+r1; r3=(r2*PRM_ganancias.AHK3)+d2; OUT_control.profundidad=r3-SASElevador(); //Procesamos SAS SATURA(OUT_control.profundidad,0.3) //Saturacin de la salida }
Listado 5 Control de altitud

void AlturaToPicth() { float ferr; float r1,r2,r3; static float d1[2]; static float d2;

112

ferr=control.altRef-estados.alt; //saturacin SATURA(ferr,10) //Implementacin de Altitude to pitch r1=PRM_ganancias.ATPK1*ferr; r2=(PRM_ganancias.ATPK3*d1[0])+r1; r3=(PRM_ganancias.ATPK4*d1[1])+r2; pitch=(PRM_ganancias.ATPK2*r3)+d2; d1[1]=d1[0]; d1[0]=ferr; d2=pitch; //saturacin SATURA(pitch,0.2) }
Listado 6 Generacin de pitch de referencia

float SASElevador() { return PRM_ganancias.ESASK*estados.q; }

Listado 7 Sistema de aumento de la estabilidad

7.5.2.4 CONTROLADOR DE HEADING

Este controlador implementa el sistema Lateral. Este sistema est compuesto por dos controladores, ya que la dinmica lateral y longitudinal deben estar coordinadas: Roll Autopilot: controla el alabeo del avin. Esta implementado en la funcin
Alerones().

Yaw Autopilot: controla la guiada del avin. Est implementado en la funcin

Deriva().

El modelo del controlador Roll Autopilot es el siguiente:

113

Figura 73 Controlador de roll y SAS de roll

La implementacin del controlador Roll Attitude Hold es la siguiente:

Figura 74 Controlador de roll

La codificacin de este controlador es la siguiente:

void Alerones() { float ferr; float r1,r2; static float d1; static float d2; //Implementacin de Roll Attitude Hold ferr=control.latRef-estados.roll; r1=(ferr*PRM_ganancias.RAHK1)+(d1*PRM_ganancias.RAHK2); r2=(r1*PRM_ganancias.RAHK3)+d2; OUT_control.alerones=r2-SASAlerones(); SATURA(OUT_control.alerones,0.3) } float SASAlerones() { return estados.p*PRM_ganancias.ALSASK; }

114

Listado 8 Implementacin de controlador de roll

El modelo de sistema Yaw Autopilot es:

Figura 75 Controlador de yaw y SAS de yaw

Siendo el modelo del subsistema Ay to rudder el siguiente:

Figura 76 Controlador de yaw

En el siguiente listado se muestra la codificacin del sistema:

void Deriva() { float ferr; float r1,r2,r3,r4; static float d1[2]; static float d2; ferr=0.0-estados.ayb; r1=ferr*PRM_ganancias.RUDK1; r2=r1+d1[0]*PRM_ganancias.RUDK3; r3=r2+d1[1]*PRM_ganancias.RUDK4; r4=r3*PRM_ganancias.RUDK2+d2; OUT_control.deriva=r4-SASDeriva(); SATURA(OUT_control.deriva,0.3)

115

d1[1]=d1[0]; d1[0]=ferr; d2=r4; } float SASDeriva() { return estados.r*PRM_ganancias.RUDSASK; }

Figura 77 Implementacin del controlador de yaw

7.5.3 DRIVER UART

Para abstraer el hardware de las UARTs y simplificar su manejo, se ha implementado un driver que se encarga de la gestin de las UARTs y la transmisin y recepcin asncrona. Se ha implementado una API que permite la configuracin de las UART, proporciona funciones de transmisin y recepcin asncrona, y acceso mediante colas de mensajes. La implementacin est dividida en dos partes principales, las funciones de configuracin, y las rutinas de tratamiento de interrupcin. El funcionamiento se basa en la utilizacin de colas de mensajes tanto para la transmisin como para la recepcin. Empleando las funciones de la API del driver, o directamente con la API de FreeRTOS podemos acceder a estas colas de mensajes, lo que permite la operacin asncrona y el uso de timeouts. A continuacin se lista el archivo uart.h, en el que est definida la API del driver:
#ifndef _UART_H_ #define _UART_H_ #include "FreeRTOS.h" #include "queue.h" // Tipo manejador de UART typedef void *xComPortHandle; /* * uartInit * Inicializa una de las UARTs * \param pxPort UART que se va a configurar * \param ulWantedBaud baudrate de las comunicaciones * \param uxQueueLength tamao de las colas de tx y rx */ xComPortHandle uartInit (portCHAR pxPort, unsigned portLONG ulWantedBaud, unsigned portBASE_TYPE uxQueueLength); /* * uartPutString * Es un envoltorio de la cola de trasnmsin * Internamente llama a uartPutChar

116

* \param pxPort UART * \param pcString cadena a transmitir * \param xBlockTime tiempo de bloqueo o timeout */ void uartPutString (portCHAR pxPort, const signed portCHAR * const pcString, portTickType xBlockTime); /* * uartGetChar * * Esta funcin es un envoltorio para el acceso a la cola de recepcin * \param pxPort UART * \param pcRxedChar referencia a buffer de recepcin * \param xBlockTime tiempo de bloqueo o timeout */ signed portBASE_TYPE uartGetChar (portCHAR pxPort, signed portCHAR *pcRxedChar, portTickType xBlockTime);

/* * uartPutChar * Es un envoltorio de la cola de trasnmsin * Internamente llama a uartPutChar * \param pxPort UART * \param cOutChar caracter * \param xBlockTime tiempo de bloqueo o timeout */ signed portBASE_TYPE uartPutChar (portCHAR pxPort, signed portCHAR cOutChar, portTickType xBlockTime);

//void uartClose (portCHAR xPort); //Proporciona una referencia a la cola de mensajes de recepcin de la UART 0 void uart0GetRxQueue (xQueueHandle *qh); //Proporciona una referencia a la cola de mensajes de recepcin de la UART 0 void uart1GetRxQueue (xQueueHandle *qh); #endif

Listado 9 API del driver de la UART

El cdigo completo se encuentra en el DVD adjunto.

7.5.4 COMUNICACIONES CON SIMULINK

Las comunicaciones con Simulink se efectan mediante el driver de la UART. La transmisin se hace directamente desde el proceso de control. El protocolo que se ha definido es el siguiente:

117

1 A

2 A

3a6 elevador

7 a 10 alerones

11 a 14 deriva

15 a 18 potencia

19 /r

Tabla 14 Protocolo de transmision a Simulink

Para la recepcin del estado y las referencias procedentes de Simulink, se hace necesaria la implementacin de una tarea independiente. Esta tarea est implementada en el archivo hil.c. El proceso se encarga de parsear los bytes recibidos y comprobar la integridad de los paquetes. El protocolo es muy sencillo, limitndose a la transmisin de los valores, por lo que la sincronizacin se hace mediante un timeout que comprueba el tiempo entre paquetes. Si por alguna causa la recepcin se desincronizase, al producirse el timeout se descarta el paquete parcialmente recibido y se comenzara la recepcin a partir del siguiente. Este proceso, como se ha comentado anteriormente, parsea los datos recibidos, almacenndolos en una estructura en memoria compartida a la que acceder el proceso de control. Para evitar el acceso a datos incompletos, el acceso a esta estructura est protegido mediante un mutex.
7.5.5 CONFIGURACIN DE FREERTOS

La configuracin de FreeRTOS se ha hecho a partir de una configuracin preexistente, disponible en la demo que acompaa a FreeRTOS, concretamente la demo para el LPC2106. Se ha modificado la configuracin para adaptarla a esta aplicacin. El siguiente listado muestra la configuracin empleada:
#define configUSE_PREEMPTION 1 #define configUSE_IDLE_HOOK 0 #define configUSE_TICK_HOOK 0 #define configUSE_CO_ROUTINES 0 #define configCPU_CLOCK_HZ ( ( unsigned portLONG ) 60000000) #define configTICK_RATE_HZ ( ( portTickType ) 1000) #define configMAX_PRIORITIES ( ( unsigned portBASE_TYPE ) 10) #define configMINIMAL_STACK_SIZE ( ( unsigned portSHORT )256) #define configTOTAL_HEAP_SIZE ( ( size_t ) ( 20 * 1024 )) #define configMAX_TASK_NAME_LEN ( 20 ) #define configUSE_TRACE_FACILITY 0 #define configUSE_16_BIT_TICKS 0 #define configIDLE_SHOULD_YIELD 1 #define configUSE_MUTEXES 1 /* Co-routine definitions. */ #define configUSE_CO_ROUTINES 0 #define configMAX_CO_ROUTINE_PRIORITIES ( 10 )

118

/* Set the following definitions to 1 to include the API function, or zero to exclude the API function. */ #define INCLUDE_vTaskPrioritySet 1 #define INCLUDE_uxTaskPriorityGet 1 #define INCLUDE_vTaskDelete #define INCLUDE_vTaskCleanUpResources 1 #define INCLUDE_vTaskSuspend #define INCLUDE_vTaskDelayUntil #define INCLUDE_vTaskDelay #define INCLUDE_xTaskGetCurrentTaskHandle #endif /* FREERTOS_CONFIG_H */
Listado 10 Configuracin de FreeRTOS

1 1 1 1 1

Como puede observarse se ha configurado un tick rate de 1KHz, eso nos permite una resolucin de 1ms en las funciones de temporizacin de FreeRTOS. Tambin es de destacar que solo se ha configurado la planificacin como expropiativa. Al adaptar este archivo de configuracin ha habido que indicar la frecuencia de reloj del LPC2148, esto es importante porque FreeRTOS usa este parmetro para la configuracin del Timer. Tambin se han seleccionados los servicios de la API que se usan en la aplicacin.
7.5.6 ESTRUCTURA DEL CDIGO FUENTE

La estructura del proyecto es muy similar al proyecto bsico que se present en el captulo anterior. En la siguiente captura puede observarse el rbol que compone el proyecto:

119

Figura 78 Archivos del proyecto Autopiloto

Pasamos a describir brevemente los archivos principales que componen la aplicacin.

MAIN.C

Es el punto de entrada de la aplicacin. En l se implementa la funcin main, en la que se inicializa el hardware, se configura el driver de la UART, se crean los procesos y se inicia la ejecucin del planificador.
AUTOPILOTO.H/AUTOPILOTO.C

En estos archivos se definen las estructuras de datos usadas por el controlador, as como la estructura de memoria compartida y las estructuras para el almacenamiento de las ganancias de los controladores. Proporciona funciones para acceder al mutex de acceso a memoria compartida y una funcin de inicializacin de las ganancias.
HIL.C/HIL.C

En estos archivos se implementa la tarea encargada de la recepcin de datos de Simulink. Esta tarea es responsable del parseo de los datos y su escritura en memoria compartida. La recepcin se hace mediante el driver de la UART. 120

CONTROLADOR.H/CONTROLADOR.C

En estos archivos se implementa la tarea de control. Esta tarea ejecuta los distintos controladores sobre los datos contenidos en memoria compartida. Tras el cmputo de los controladores, el resultado se enva a Simulink empleando el driver de la UART.
UART.H/UART.C

En estos archivos se implementa la API del driver de las UARTs. Proporcionan funciones de inicializacin del driver, funciones de lectura y escritura, y referencias para el acceso directo a las colas de mensajes de transmisin y recepcin. La funcin de inicializacin crea las colas de mensajes, configura el hardware segn los parmetros indicados por el usuario y configura el VIC.
UARTISR.H/UARTISR.C

En estos archivos se implementan las rutinas de interrupcin de la UART. Forman parte del driver de la UART y se encargan de realizar las operaciones de transmisin y recepcin a bajo nivel. Para ello emplean las colas de mensajes creadas en la funcin de inicializacin.
FREERTOSCONFIG.H

Es el archivo de configuracin de FreeRTOS, en el se configura el comportamiento del SO as como los servicios disponibles.

Directorio lpc2148 Dentro de este directorio existen diversas libreras, con definiciones de los registros y funciones de inicializacin del microcontrolador. Estas libreras proceden de los ejemplos que acompaan a FreeRTOS.
7.6 RESULTADOS OBTENIDOS

En este punto compararemos los resultados de la simulacin en Simulink con la prueba HIL. El objetivo de este anlisis es validar la implementacin en el hardware real mediante comparacin directa de los resultados. Para realizar este anlisis se establecer la siguiente ruta de waypoints a seguir por la aeronave:

121

X Y Z

A 0 0 1200

B 1000 0 1300

C 1400 600 1400

D 1000 1000 1300

E 400 800 1205

F -200 400 1400

COMPARACIN DE TRAYECTORIAS EN EL PLANO XY

En las siguientes figuras se muestran las trayectorias seguidas en el plano horizontal tanto en la simulacin en Simulink, como en la prueba HIL. Simulink:

Figura 79 Trayectoria seguida en Simulink

Simulacin HIL:

Figura 80 Trayectoria seguida durante la prueba HIL

122

Se puede apreciar como el error en trayectoria realizada con el hardware real es despreciable. Este error viene dado principalmente por el hecho de usar aritmtica de punto flotante de 32bits, en lugar de los 64bit que emplea Simulink.
COMPARACIN DE TRAYECTORIAS EN EL EJE Z

Simulink:

Figura 81 Altura del UAV en la simulacin con Simulink

Simulacin HIL:

Figura 82 Altura del UAV durante la prueba HIL

123

En estas grficas tambin se observa que las trayectorias son prcticamente coincidentes.

Con estos resultados podemos afirmar que la respuesta de la implementacin en el microcontrolador LPC2148 con FreeRTOS es vlida, cumpliendo los requisitos funcionales de ms alto nivel al ser su respuesta muy prxima a la simulacin. En un entorno de produccin real, este hardware ya sera integrable en un UAV. A este proceso le seguira un proceso de refinamiento de los controladores, ya que con toda seguridad, la respuesta del avin real no se ajuste completamente al modelo empleado para el diseo del sistema de control.

124

CONCLUSIN

Tras el estudio de la familia, las herramientas y recursos disponibles, y la implementacin de un sistema de control con las mismas, hemos comprobado cmo es viable el uso de herramientas libres para configurar un entorno de desarrollo fiable y de alta calidad y prestaciones. Hemos verificado la versatilidad de la arquitectura y la gran cantidad de recursos libres disponibles. Este conjunto de caractersticas, hacen de esta familia una buena plataforma docente, ya que adems de ser una arquitectura ampliamente implantada y en continua evolucin, disponemos de todas las herramientas necesarias de forma gratuita, y en el caso del hardware, a muy bajo coste. Por otra parte se ha verificado la capacidad computacional de la misma, obteniendo resultados satisfactorios en la implementacin de un sistema de control en tiempo real, cuya validez se ha probado mediante la realizacin de una prueba de tipo hardware in the loop. Adicionalmente se ha demostrado la utilidad de este tipo de pruebas, ya que permiten la verificacin de un diseo de forma sencilla y fiable, ya que se centra en la comprobacin de requisitos funcionales de alto nivel.

125

126

LNEAS FUTURAS

Como desarrollo adicional de este proyecto se propone el estudio de la integracin de cdigo generado automticamente desde Simulink con la herramienta Realtime Workshop. La integracin de cdigo generado mediante herramientas de diseo basado en modelos puede presentar ventajas como la eliminacin de errores de codificacin y permitir que se puedan hacer modificaciones en los modelos sin que ello suponga una carga de trabajo adicional de codificacin. Tambin resulta interesante el estudio de las familias Cortex-M3 y Cortex-R4, especialmente indicadas para sistemas en tiempo real. Un desarrollo adicional podra ser la implementacin de un port de FreeRTOS para Cortex-R4, ya que todava est disponible. Con respecto a la pruebas HIL, resulta interesante investigar este campo, especialmente si se realizan con hardware especifico para tal propsito, como los equipos PXI para LabView Realtime. Esto equipos permiten la realizacin de estas pruebas en un verdadero entorno en tiempo real, contando con tarjetas de E/S mediante las cuales se podra interfasear el sistema de control a ms bajo nivel, por ejemplo, se podra conectar la salida PWM de un controlador de servos directamente al equipo PXI, este realizara la decodificacin de esta seal PWM y la aplicara a la modelo del sistema bajo control. De esta forma las pruebas HIL permiten probar no solo la funcionalidad en cuanto a clculo, sino tambin la correcta implementacin de los protocolos de E/S del sistema.

127

128

BIBLIOGRAFA

ARM7TDMI Technical Reference Manual , ARM Limited The insiders guide to the Philips ARM7 based microcontrollers, Trevor Martin, Hitex Ltd., ISBM: 0-9549988 1 Using Open Source Tools for AT91SAM7S Cross Development, James P. Lynch LPC214x User Manual, Koninklijke Philips Electronics FreeRTOS reference manual, Richard Barry, Real Time Engineers Ltd. Using the FreeRTOS Real Time Kernel A Practical Guide, Richard Barry, Real Time Engineers Ltd.

129

130

REFERENCIAS WEB

www.nxp.com/ http://www.arm.com/ http://www.freertos.org/ http://www.embeddedrelated.com/groups/lpc2000/1.php http://openocd.berlios.de/web/ http://www.eclipse.org/ http://www.highintegritysystems.com/ http://www.mathworks.com/matlabcentral/ http://forum.sparkfun.com/

131

132

ANEXO A: FAMILIAS SOPORTADAS POR FREERTOS

Altera: Nios II Atmel: CortexM3, ARM7, ARM9, AVR Cortus: APS 3 Energy Micro: EFM32, Cortex M3 Freescale: HCS12, Coldfire, PowerPC Fujitsu: MB91460, MB96340 Luminary Micro (adquirida por TI): Cortex M3 Microchip: PIC32, PIC24, dsPIC, PIC18 NEC: V850ES, 78K0R NXP: Cortex M3, ARM7 Renesas: SuperH, H8S Silicon Labs: 8051 ST: Cortex M3, ARM7, ARM9 TI: MSP430 Xilinx: Microblaze, PowerPC Intel/AMD/Otros: x86

133

134

ANEXO B: CDIGO PARA EL CLCULO DE REFERENCIAS DE TRAYECTORIAS

function k = track(u) global I_ANT global J_ANT %Sacar los valores de la entrada. long = (length(u)-4)/3; x_camino = u(1:long); y_camino = u(long+1:2*long); h_camino = u(2*long+1:3*long); x_v = u(3*long+1); y_v = u(3*long+2); reset=u(3*long+3); tipo=u(3*long+4); %Valores de los indices correspondientes al camino. i=I_ANT; j=J_ANT; %Calculamos variables. x_dif=x_camino(i)-x_camino(j); y_dif=y_camino(i)-y_camino(j); ang=atan2(x_dif,y_dif); modulo=sqrt(((x_camino(i)-x_camino(j))^2)+((y_camino(i)y_camino(j))^2)); x_track=-(x_v*(cos(ang-pi/2))-(y_v*(sin(angpi/2))))+(x_camino(j)*(cos(ang-pi/2)))-(y_camino(j)*(sin(angpi/2)))+modulo; %Calculo el ngulo siguiente. m=i+1; if (m==long+1) m=1; end xd2=x_camino(m)-x_camino(i); yd2=y_camino(m)-y_camino(i); angsig=atan2(xd2,yd2);

%Calculo la magnitud del giro siguiente. angtot=abs(angsig-ang); if (angtot>pi) angtot=(2*pi)-angtot; end %Seleccin de ganancias if (tipo==1) k=-(500/modulo)*0.002; else k=-(500/modulo)*0.002e7; end %Calculamos cundo se realizar el giro error=(angtot*3)/pi;

135

error2=modulo*error/100; %logica de guiado. if (x_track<error2) j=i; i=i+1; if i==long+1 j=long; i=1; end end if (reset==1) i=2; j=1; end %Salidas. k=[x_camino(j),y_camino(j),x_camino(i),y_camino(i),k,h_camino(i)]; I_ANT=i; J_ANT=j;

136

137