GENERACIÓN SOFTWARE DE 20 SEÑALES DE CONTROL PPM.

GENERACIÓN SOFTWARE DE 20 SEÑALES DE CONTROL PPM. Manuel Muñoz Alcobendas Salvador Peirò Frasquet Juan Francisco Blanes Noguera Miguel Albero Gil Instituto de Informática y Automática Industrial AI2 Universidad Politécnica de Valencia mamuoal @ posgrado.upv.es, {speiro, pblanes, mialgil} @ ai2.upv.es Resumen El presente artículo aborda la problemática del control de actuadores del tipo servomotor las restricciones temporales de los cuales son un claro caso de sistema en el cual las prestaciones se ven disminuidas con el incumplimiento de los plazos de control. Así se analizan diferentes soluciones para la generación mediante software de las 20 señales de control PPM que dirigen las 20 articulaciones en un robot bípedo. Para ello se utiliza un microcontrolador de la Familia ARM7. Se implementan diferentes soluciones que garantizan el cumplimiento de las restricciones temporales en la generación de las señales y con ello un posicionamiento preciso de las articulaciones. Finalmente se incluye una propuesta que implementa una versión sobre el sistema operativo de tiempo real PaRTiKle que facilita las tareas de programación, depuración y mantenimiento del código de la aplicación, sin comprometer los requisitos de tiempo real. sistema empotrado. Adicionalmente el sistema dispone de comunicaciones, USB y SPI, 8 canales analógico/digital libres, y sistemas de sensorización, entre los que destacan: sensor de infrarrojos, acelerómetro de 3 ejes, y sensores de presión en la planta del pie. Para disponer de total autonomía, el robot esta dotado con una batería de Polímetro de Litio que suministra la energía para los actuadores y el sistema de control. Para la consecución de movimientos del robot, se necesita gestionar el posicionamiento de las 20 articulaciones del robot, cada una de ellas impulsada por un servomotor. Para realizar este control se dispone de los recursos proporcionados por el sistema de control empotrado anteriormente descrito. Puesto que no se conoce ningún sistema específico capaz de generar las 20 señales PPM (posición por modulación de pulso) necesarias para el control del robot, se han implementado un conjunto de propuestas software que solucionen esta necesidad. Palabras Clave: Control en Tiempo Real. Robótica. Sistemas Operativos de Tiempo Real. Sistemas Empotrados. 1 INTRODUCCIÓN 1. MicroBIRO [8] es un robot humanoide de 20 grados de libertad desarrollado por el Instituto de Automática e Informática Industrial de la Universidad Politécnica de Valencia. Se trata de un pequeño bípedo formado por 20 actuadores, y unos pequeños elementos de aluminio que hacen de unión entre estos. La capacidad de cómputo viene dada por un procesador de la Familia ARM7 [1], el LPC2136 [12]. La adecuación de las señales de los sensores, el procesamiento de las mismas y la actuación correspondiente se realizan íntegramente en este 1 Este trabajo forma parte del proyecto KERTROL DPI2005-09327-C02-02 del Ministerio de Educación y Ciencia. Figura1: MicroBIRO. Por tratarse de un sistema de control, la implementación deberá de garantizar el cumplimiento de los tiempos de control, aun más cuando de la correcta generación de estas señales dependerá el posicionado adecuado de los

servomotores y con ello el caminar apropiado del robot. Por lo tanto se trata de un sistema de tiempo real, puesto que en caso de no cumplirse las restricciones temporales impuestas, la respuesta del sistema sufre un degradado, pudiendo incluso llevar el sistema a la inestabilidad que conlleva caídas del robot. El sistema adicionalmente debe ser capaz de atender a otras actividades como son: sensorización, planificación de comportamientos, generación de trayectorias y movimientos, comunicaciones, entre otras. Por tanto, las soluciones deberán de tener en cuenta también la gestión adecuada de los recursos disponibles intentando minimizar la utilización de los mismos, de modo que tengan cabida el resto de actividades del sistema. 2 ACTUADORES, SEÑAL PPM. El robot dispone de 20 articulaciones, cada una de ellas constituida por un pequeño servomotor de modelismo. Estos actuadores disponen de un lazo interno de control de posición, realimentado mediante un potenciómetro solidario al eje de salida del motor. Este regulador toma como referencia la proporcionada mediante una señal digital externa de tipo PPM [5]. Así, se aborda el problema de la generación de 20 señales PPM con un microcontrolador. Cada una de estas señales se utilizará para codificar la posición en la que debe de situarse uno de los servomotores. La señal PPM es una señal de modulación de pulso que se utiliza para la codificación de la posición. Se trata de una señal periódica de 50Hz en la que la posición se codifica en la franja comprendida entre los 850 μ s, correspondientes a -85º y los 2 55 ms correspondientes 85º, como se observa en la figura 2. Así, se puede apreciar, que como mínimo cada periodo de la señal contendrá un pulso de 850 μ s al inicio del mismo. Por otra parte la duración máxima del mismo será de 2550 μ s, correspondientes al 12 75% del periodo de la señal. Esta será la parte del periodo que contendrá la información mientras que en el resto del mismo la señal permanecerá a nivel bajo. Figura 2: Pulso PPM. Como se comento en el apartado 1 las 20 señales PPM se van a generar mediante software, utilizando uno de los contadores de los que dispone el microcontrolador y los puertos de entrada/salida de proposito general. Cabría destacar que en la actualidad muchos microcontroladores avanzados, poseen generadores de PWM (Señal de modulación de ancho de pulso), con la que se podrian generar de modo sencillo las señales PPM. El principal inconveniente es debido al número de señales a generar, puesto que no se conoce ningún dispositivo comercial, que genere las 20 señales simultaneamente. 2.1 REQUERIMIENTOS TEMPORALES PARA EL CONTROL. La duración del ancho de pulso de las señales es la que va a codificar la posición de los servomotores, por tanto ha de cumplir unos requerimientos impuestos por la tarea que se va a realizar con los actuadores y por estos mismos. Puesto que los actuadores se encargan de posicionar las articulaciones, y con ello llevar las extremidades del robot a una posición determinada en el espacio, los requerimientos que se le van a imponer a la señal serán aquellos que hagan que el posicionamiento final del robot sea adecuado y estable. Experimentalmente se ha comprobado que para lograr posicionar de madera precisa las extremidades del robot, el error de posición en cada una de las articulaciones de la misma deberá de ser menor de 0.5º. Esto determina la precisión que el programa que gestiona la generación de las señales de control debe de ser capaz de garantizar. Así, de la ecuación I se deduce que para asegurar dicha resolución angular en el posicionamiento del eje del servo, se debe de ser capaz de al menos tener una resolución de 5 μ s en la generación del ancho del pulso de cada una de las señales. TP max TP min 1700μ s S 10 μs ; (I) Rango 170º º Por una parte una temporización inadecuada a la hora de generar la señal, produciría un desplazamiento en

el tiempo de flanco de bajada de la señal, que conllevaría a un offset en el posicionado del eje. Mientras que una mala resolución a la hora de gestionar los tiempos conllevaría incertidumbre en la generación de las señales que producirá un temblor en el eje del servomotor. Por tanto se debe de abordar una tarea de altos requerimientos temporales que garantice los tiempos en la generación de las señales. Adicionalmente, se ha de tener en cuenta que la sincronización de las señales ha de ser adecuada, puesto que por tratarse de un sistema de control, una mala sincronización entre las señales puede comprometer el movimiento adecuado del robot. Esto es debido a que las posiciones de las extremidades del robot se calculan suponiendo que los actuadores deben de adoptar estas posiciones de forma sincronizada. De no ser así, las trayectorias no se seguirán correctamente. 3 GENERACIÓN PPM-PWM. Para la generación del conjunto de señales, se han abordado diferentes estrategias, que solucionan el problema con diferentes grados de dificultad y obteniendo resultados que satisfacen los requerimientos temporales necesarios para posibilitar el control y minimizar la utilización de recursos del sistema. El sistema se ejecuta sobre el sistema empotrado sin utilización de sistema operativo. Al iniciar la ejecución, se realiza una configuración del mismo, en la que se instalan los gestores de interrupción y se configuran los periféricos. En concreto, se configura la interrupción del temporizador T1 para que se ejecute cada 20 ms, y así poder utilizarlo en la generación de las señales PPM. La interrupción de este se ejecutará con la máxima prioridad del sistema, de este modo se garantiza que no será interrumpida y que se cumplirán así los tiempos estipulados en la implementación del programa. Una vez terminada la configuración inicial, entra en ejecución el bucle principal, en el que se realizarán el resto de actividades del sistema, como pueden ser, la planificación de trayectorias, las decisiones de comportamiento, comunicaciones, y otros, todos ellos entrando en ejecución según un planificador cíclico. En las siguientes secciones se describirán cada una de las soluciones propuestas. 3.1 INTERRUPCIÓN PERIODICA CON CONSULTA EXHAUSTIVA. La solución de partida esta basada sobre el sistema descrito en el apartado anterior. Por tanto la generación de la señal PPM se realiza dentro del manejador de interrupción del Temporizador T1. Se parte de la suposición de que el planificador de movimientos ha transformado mediante una transformación lineal la posición en tiempo de duración del pulso (Ec II). T PULSO ( pos+ 85º ) S 1700 10 pos μs T + (II) Pmin + En la interrupción, inicialmente se establece el valor de la señal a nivel alto para todas las señales, puesto que al menos se debe de generar el pulso mínimo. Una vez transcurrido este tiempo, mediante un bucle, se comprueba de forma exhaustiva para cada una de las señales si el tiempo transcurrido desde que se inicio la interrupción es superior a la duración del pulso y en caso afirmativo, se modifica el valor de la señal a nivel bajo. Transcurrido el tiempo de pulso máximo, la interrupción retorna. INT_Temporizador1: Señales_todos_Servos 1; espera(tiempo_pulso_mínimo). loop (Hasta_tiempo_pulso_máximo) if (Tiempo_Servo1cumplido) Señal_Servo1 0; if (Tiempo_Servo2cumplido) Señal_Servo2 0;... if (Tiempo_Servo20cumplido) Señal_Servo20 0; end loop; fin INT; Puesto que la interrupción tiene la máxima prioridad, no se realizará ninguna interrupción en la ejecución de la misma, por lo tanto, la duración de la misma será la duración del pulso máximo. Esto conlleva una utilización del procesador del 13 25%. Por otra parte, al realizar la comparación para cada una de las señales, se consigue una resolución de 1 9º no cumpliendo así las especificaciones marcadas. 3.2 INTERRUPCIÓN PERIÓDICA CON CONSULTA ORDENADA. La segunda propuesta intenta mejorar la primera de modo que se obtenga una mejor resolución temporal en la generación la señal PPM. Para ello se proponen dos modificaciones básicas. El principal problema de la propuesta anterior esta producido por la duración excesiva de cada una de las iteraciones del bucle en que se actualiza el estado

de las señales. Esto es debido a que en cada una de las iteraciones se realizan 20 comparaciones, una por cada uno de los servomotores. La nueva propuesta realiza una ordenación dinámica de las señales atendiendo a la duración de las mismas. De este modo en el bucle de control se debe de realizar la consulta únicamente sobre una de las variables, la que más cerca este de modificar su estado, que será la siguiente dentro del vector ordenado. Ordena_tiempos_Servos(); INT_Temporizador1: Señales_todos_Servos 1; wait(tiempo_pulso_mínimo). cont Primer_Servo; loop (Hasta_tiempo_pulso_máximo) if (Tiempo_Servo[cont]cumplido) Señal_Servo[cont] 0; contservo_siguiente; end loop; fin INT; Con ello se mejora notablemente la resolución temporal, obteniendo 0.09º y por tanto se cumple con las restricciones impuestas por el proceso. Como contrapartida se introduce una sobrecarga en la utilización de la CPU del 2 8% debida a la ordenación previa a cada ejecución de la interrupción. 3.3 INTERRUPCIÓN APERIODICA Y PPM DISTRIBUIDO. Analizando los principales inconvenientes de las propuestas anteriores se deduce que estos son: En primer lugar, la elevada carga de cómputo producida por la consulta iterativa durante la generación la longitud del pulso de 2 55 ms ; Y por otra parte, el consumo de energía, ya que como los motores sincronizan su consumo de energía con la señal de control, al estar el inicio de todas estas sincronizadas con el periodo de control, se producen ciclos de alta densidad de descarga y otros de prácticamente nula, con lo que las fuertes corrientes hacen disminuir bruscamente la tensión en las baterías y con ello se produce el reset del microcontrolador. Esto también produce la reducción del ciclo de vida de las baterías debidas al uso intensivo de las mismas. Para solucionar ambos problemas se plantea una solución en que las señales PPM para cada uno de los motores estén desfasadas cada una de la anterior en 850 μ s. De este modo, el consumo de energía se reparte a lo largo de todo el periodo de control. Este desfase en el periodo de control se deberá tener en cuenta a la hora de generar las trayectorias. En cuanto al modo de generación de las señales, continúan realizándose mediante la ejecución del manejador de interrupciones del Temporizador T1, pero en este caso el tiempo con el que se producen las interrupciones es variable. Se genera una interrupción cada vez que se necesita modificar el estado de alguna de las señales. Con ello se generan un conjunto de 40 interrupciones en cada uno de los periodos de control, 2 por cada una de las señales. Para poder llevar a cabo esta ejecución es necesario que al inicio de cada uno de los periodos de control se ejecute una rutina que calcule el tiempo en que se deben de producir cada una de las interrupciones. Esto introducirá una sobrecarga computacional de 70 μ s. Cálculo_Instantes_activación(); INT_Temporizador1: Señal_Servo[cont] nivel_act[cont]; cont activacion_siguiente; cuenta_temporizador1 T_hasta_activación_siguiente[cont]; fin INT; 3.4 INTERRUPCIÓN PERIÓDICA CON CONSULTA ORDENADA, SOTR PARTIKLE. PaRTiKle [9,15] es un nuevo sistema operativo de tiempo real destinado a sistemas empotrados y diseñado para ser compatible con POSIX [17]. PaRTiKle se ha diseñado con las siguientes premisas: Ser tan portable, configurable y mantenible como sea posible. Soporte para múltiples entornos de ejecución, permitiendo ejecutar el mismo código de aplicación (sin modificación) bajo distintos entornos de ejecución: sobre máquina desnuda, como un proceso Linux, como un dominio del hipervisor XtratuM [10]. Soporte para multiples lenguajes de programación: C, Ada, C++ y Java. Otras características interesantes de PaRTiKle son: Requisitos de memoria reducidos (kernel: 60-70Kb). Sistema configurable para adaptarse al sistema empotrado. API de programación estandar: POSIX PSE.51, lo que facilita la portabilidad de código de sistemas existentes. Uso eficiente del hardware disponible. 3.4.1 Porting PaRTiKle al LPC Este apartado describe los aspectos más relevantes del porting de PaRTiKle a los sitsemas LPC2000 [12].

PaRTiKle utiliza la UART0 como terminal serie conectada mediante la interfaz ftdi-usb [2] al puerto serie del ordenador de desarrollo lo que permite el envio/recepción de cadenas mediante las funciones printf/scanf. En cuanto a la gestión del tiempo, los sistemas LPC [12,18] incluyen para la gestión de tiempo un reloj (RTC) y dos temporizadores (T0 y T1). El RTC (Real Time Clock) funciona a una frecuencia de 32 Khz se utiliza como reloj del sistema. La resolución de este reloj es de 1 / 32Khz 30.5 μ s. Del mismo modo, el temporizador T0 se utiliza como timer hardware en PaRTiKLe para implementar timers virtuales utilizados por el planificador. Estos funcionan a la frecuencia del bus de periféricos PCLK (Peripheral bus Clock). Esto implica que trabajando a 60MHz se puede obtener una resolución de 0.06 μ s. De este modo queda disponible el temporizador T1 para ser utilizado por las aplicaciones. 3.4.2 Implementación sobre PaRTiKle. En este apartado se presenta la propuesta 3.2 (Interrupción periódica con consulta ordenada) implementada sobre el SOTR PaRTiKle. Para ello se rediseña la aplicación utilizando las primitivas que ofrece el SOTR, como son: uso de tareas periódicas y su comunicación (sincronización) por medio de monitores software. En particular las señales PPM se implementan mediante una tarea periodica con una frecuantcia de 50Hz, que utiliza el mismo mecanismo que la propuesta 3.2. Incluido el uso del temporizador T1 como referencia de tiempos. El resto de actividades del sistema, como son la generación de trayectorias y movimientos, y la planificación de comportamientos, se implementan por medio de tareas del SOTR y monitores para su comunicación. En concreto se ha implementado un monitor software que proporciona un mecanismo para la sincronizacion entre la tarea de planificación de comportamientos, y la generación de trayectorias. 4 RESULTADOS Se han evaluado los 3 (3.1, 3.2, 3.3) métodos mediante herramientas de simulación que proporciona el entorno de programación Keil Development Suit for ARM, y todos ellos realizando medidas directamente en el sistema utilizando las entradas y salidas digitales de proposito general. Con ello se han obtenido los siguientes resultados: Para las dos primeras soluciones el sistema invierte un tiempo fijo para la generación de las señales de control. Este viene dado por la duración del pulso máximo. En la ecuación III se puede apreciar el coste computacional que esto conlleva. U C T 2650μ s 13'25% (III) 20ms La segunda solución introduce una sobrecarga de cómputo debida a la ordenación de las señales de control. En la ecuación IV se puede apreciar el cómputo adicional que debe de ejecutar el procesador. C 560μ s U 2'8 % (IV) O T 20ms La resolución temporal obtenida para ambos casos produce como máximo un error de posicionamiento en el eje del motor como el que se muestra en la ecuación V para el primer caso y en la ecuación VI para la segunda propuesta. R 19μ s 1' 9 (V) 1700μs R 0'9μ s 0' 09 (VI) 1700μs Cabe destacar que estos resultados se han obtenido trabajando a una frecuencia de 60MHz, y puesto que en ambas propuestas la resolución depende directamente de la capacidad de relizar las iteraciones del bucle, se ve influenciada directamente por la velocidad de procesamiento del microcontrolador. Para la tercera solución el coste computacional esta distribuido a lo largo de todo el periodo de control, como se puede ver en la figura 3. Al inicio de cada periodo de control se ejecuta una rutina que calcula los tiempos con que debe de configurarse la interrupción a lo largo del periodo. La utilización del sistema producida por la generación de las señales PPM (ec. IX), será la suma de todas estas pequeñas interrupciones (ec. VII), y el cálculo de tiempos (ec. VIII). U INT C 3'7μ s 2 20 148μs 0'74 % (VII) T 20ms 20ms C 70μ s.. 0'35 % (VIII) C T 20ms U T U U + U 1'09% (IX) PPM INT C. T. El error en el posicionamiento del sistema depende de dos fuentes de retardo. Por una parte la resolución

del Temporizador T1 en el que esta implementada la interrupción (ec. X)y por otra parte, de la latencia de la interrupción en ser atendida.(ec.xi) Así el error máximo estará producido por la suma de los dos anteriores (ec. XII). R T 1 1μ s 01' (X) 1700 μ s. 432ns 0' 0432 (XI) L 1700 μ s R INT R R + R 0' 1432º (XII) TOTAL T1 L. INT la tarea que se propone, aunque es un método valido para muchas otras tareas con requerimientos menos estrictos, en cuanto al error de posicionamiento del servomotor. Las otras propuestas (3.2, 3.3, y 3.4) si ofrecen las prestaciones necesarias para alcanzar el posicionado de los ejes del motor con precisión suficiente para poder realizar el posicionado adecuado de las extremidades del robot. Estas tres propuestas aportan modos diferentes de abordar el mismo problema con diferentes grados de complejidad y obteniendo unos resultados variados, sobretodo en cuanto a consumo de recursos. La primera (3.2) de ellas nos proporciona simplicidad en la implementación pero un coste computacional elevado. La segunda (3.3) reduce en mucho el coste computacional aumentando en complejidad de implementación. La tercera (3.4), replica la segunda propuesta, incorporando las ventajas de utilizar un sistema operativo, estas serán comentadas con detalle en el siguiente apartado 5.1. 5.1 CONCLUSIONES DESARROLLO SOBRE PARTIKLE. Figura3: 3 Señales de PPM distribuido. Y activaciones de la interrupción del Temporizador T1. Para la cuarta solución mostrada en el apartado 3.4, Interrupción periódica con consulta ordenada con SOTR PaRTiKle, la sobrecarga introducida por el sistema operativo no afecta al control de los servomotores por lo que los resultados obtenidos en cuanto a carga del sistema por parte de la generación del PPM y la resolución obtenida no varian frente a las que se obtuvieron en la propuesta 3.2, Interrupción periódica con consulta ordenada sin sistema operativo. Cabe destacar que la implantación del sistema operativo mejora las posibilidades y facilidades de desarrollo e implementación. Estas serán comentadas en detalle en el apartado 5.1. 5 CONCLUSIONES Se han implementado 4 versiones software que permiten generar las señales de control PPM necesarias para controlar el conjunto de 20 servomotores que conforman las articulaciones del robot humanoide microbiro. La primera propuesta (3.1) no consigue gestionar la generación de tiempos con suficiente precisión para En este apartado se analizan y presentan las conclusiones extraidas del desarrollo de la aplicación sobre el SOTR PaRTiKle y como afecta a las diferentes fases del desarrollo: Diseño, Programación, Depuración y Mantenimiento. 5.1.1 Diseño. Una de las principales ventajas de usar un SOTR, es que se utiliza un API estandar (POSIX), lo cual permite abstraerse del hardware subyacente. Permitiendo realizar el modelado de la aplicación en base a tareas, objetos protegidos, y demás primitivas ofrecidas por el SO: Control de tareas (hilos de ejecución) Sincronización y temporización de tareas Gestión de recursos 5.1.2 Programación. El uso del SO durante la etapa de diseño redunda en que durante la programación no hay que preocuparse de los detalles del hardware como: Inicialización y configuración del hardware Gestión de dispositivos e interrupciones Gestión de memoria dinámica Detalles específicos del compilador y ensamblador.

Por otra parte, libera de la tarea de implementar mecanismos de comunicación y sincronización adhoc para una aplicación específica, ya que estos han sido implementados correctamente a nivel de SO, lo que también reduce el número de errores. 5.1.3 Depuración. En caso de producirse errores/excepciones del procesador, el sistema operativo se encarga de proporcionar un mensaje de diagnostico (excepción producida, estado de registros, pila,...) que permite determinar las causas de los errores. Esto es posible ya que se proporciona el contador de programa (PC) que proporciona la dirección de la instrucción que produjo el fallo. 5.1.4 Mantenimiento. Por último, el uso de una API homogénea (POSIX) durante el desarrollo facilita las modificaciones y cambios posteriores a lo largo de la vida útil del sistema. Referencias. [1] Advanced RISC Machines, ARM7TDMI-S (rev r4p3) Technical Reference manual. ARM Limited. http://www.arm.com/documentation/armprocessor_ Cores. [2] Craig Peacock, USB with the simplicity of RS- 232. http://www.beyondlogic.org/usb/ftdi.htm. [3] Craig Peacock, Interfacing the Serial RS-232 Port. http://www.beyondlogic.org/serial/serial.htm [4] David Seal, The ARM Architecture Reference Manual. 2nd Edition, Addison-Wesley Longman Publishing Co.. http://www.arm.com/documentation/books.html. [5] Dennis Clark, Michael Owings, Building Robot Drive Trains, McGraw-Hill Professional, http://users.frii.com/dlc/robotics/brdt.html. [6] Development systems Division, Compiler Tools Group. Procedure Call Standard for the ARM Architecture. ARM Limited, 2003. http://infocenter.arm.com/help/topic/com.arm.doc.ihi 0042a/IHI0042A_aapcs.pdf [7] Intel Corporation, Intel Hexadecimal Object File Format Specification, Intel 1988, http://www.pjrc.com/tech/8051/pm2_docs/intelhex.ht ml. [8] M. Albero, V. Nicolau, F. Blanes, J. Simó. microbiro: UN ROBOT BÍPEDO PARA LA ENSEÑANZA Y LA INVESTIGACIÓN. Instituto de Informática y Automática Industrial AI2, Universidad Politécnica de Valencia. http://www.gii.upv.es/robotica/ [9] M. Masmano, I. Ripoll, A. Crespo, PaRTiKle OS User Manual. Real-Time Systems Group, Universidad Politécnica de Valencia. http://www.e-rtl.org/partikle/node/5. [10] M. Masmano; I. Ripoll, A. Crespo, An overview of the XtratuM nanokernel, Workshop on Operating Systems Platforms for Embedded Real-Time applications, (2005), http://www.xtratum.org/biblio. [11] Martin Thomas, Philips LPC213x/214x examples ported for the GNU-Toolchain, http://www.siwawi.arubi.unikl.de/avr_projects/arm_p rojects/lpc2k_bundle_port/. [12] NXP, LPC2131/2/4/6/8 User manual. NXP, founded by Philips, http://www.standardics.nxp.com/support/documents/ microcontrollers/?searchlpc2&typeuser. [13] NXP, LPC2000 Application Notes: Boot sequence, Interrupts, Spurious Interrupts. NXP, founded by Philips. http://www.standardics.nxp.com/support/documents/ microcontrollers/?searchlpc2. [14] Paul Stoffregen, LPC2K_PGM Linux Bootloader Utility (Philips LPC 2000 ARM7 Chips). http://www.pjrc.com/arm/lpc2k_pgm. [15] S. Peiro, M. Masmano, I. Ripoll, and A. Crespo, PaRTiKle OS, a replacement of the RTLinux core. Real-Time Systems Group, Universidad Politécnica de Valencia. http://www.e-rtl.org/partikle/node/5, http://www.e-rtl.org/partikle. [16] The Mikrocontroller project, http://www.mikrocontroller.net/articles/lpc2000. [17] The Open Group. The core of the Single UNIX Specification, Version 3, ISO/IEC 9945, 2003. http://www.unix.org/version3/iso_std.html [18] Trevor Martin, The Insiders guide to the ARM7- based microcontrollers. Hitex development tools, http://hitex.co.uk/arm.