Electrocardiógrafo portátil basado en RTOS · de microcontroladores, los uales permiten dotar dec...

Electrocardiógrafo portátil basado en RTOS

C A Centeno, J A Voos, G G Riva, C Zerbini, E A Gonzalez

Grupo de Ingeniería Clínica, Facultad Regional Córdoba, Universidad Tecnológica Nacional, Maestro López esquina Cruz Roja, Ciudad Universitaria, X5016ZAA Córdoba, Argentina.

[email protected]

Abstract. En el presente trabajo se presenta la utilización de un Sistema Operativo de Tiempo Real RTOS sobre una plataforma microcontrolador para el manejo de las funciones asociadas al mismo , dentro de un electrocardiógrafo portátil. El CPU del electrocardiógrafo esta basado en el microcontrolador 18F4550, el cual permite ser embebido con el RTOS uCOS-II. La decisión del uso del mencionado kernel esta basada en las prestaciones del mismo, su licencia para uso educativo y sus características intrínsecas de control del tiempo y manejo de periféricos. La evaluación de la posibilidad de uso del mismo se realiza en la base a los requerimientos mínimos necesarios de memoria debido a la estructura del mencionado kernel, haciendo uso de las herramientas propias incluidas para la estimación tanto del tiempo como de los recursos empleados por cada proceso. A posterior del análisis de factibilidad se realizo la migración del código cíclico a una estructura basada en procesos independientes que emplean los eventos para su posterior sincronización, obteniendo como resultado un electrocardiógrafo basado su CPU en un sistema operativo de tiempo real.

1. Introducción Con el avance de la integración de dispositivos periféricos dentro de una pastilla o circuito integrado, es posible la implementación de mayor funcionalidad en los diseños electrónicos basados en estos elementos. Como fruto de este avance tecnológico se dispone en el mercado local de una amplia línea de microcontroladores, los cuales permiten dotar de características especiales al dispositivo a desarrollar.

En la línea de desarrollo de un electrocardiógrafo portátil [1][2], dentro del grupo de investigación, se hizo uso de una plataforma microcontrolador de la familia Microchip, en donde el modelo seleccionado inicialmente fue el 16F877.

En la etapa actual de desarrollo, el CPU del electrocardiógrafo esta basado en el microcontrolador 18F4550 [3][4] , el cual posee mayor memoria, requisito indispensable al momento de evaluar la posibilidad de implementación del software de control basado en el uso de un RTOS kernel. Una característica importante y necesaria también para el mencionado cambio, es la posibilidad de emplear la memoria RAM disponible para uso como stack.

En virtud de disponer de estas capacidades es posible pensar en el uso de un RTOS para el manejo de todas las funciones asociadas con el control de las distintas etapas del electrocardiógrafo, ya sean analógicas, y/o digitales.

El proceso de cambio del tipo ejecutivo cíclico al tipo multitarea, requiere en una primera instancia del análisis de cada proceso y su interacción con los restantes.

XVIII Congreso Argentino de Bioingeniería SABI 2011 - VII Jornadas de Ingeniería Clínica Mar del Plata, 28 al 30 de septiembre de 2011

2. Materiales y Métodos

2.1. Análisis de un Ejecutivo cíclico El sistema inicial estaba basado en un ejecutivo cíclico, es decir que cada proceso que compone el software de control se ejecuta uno a continuación del otro dentro de un bucle de repetición infinito. A continuación se presenta una descripción de cada una de las etapas de hardware y como interactúan con el microcontrolador, para culminar con un resumen de dicha información en la Tabla 1.

2.1.1. Teclado Matricial. El mismo esta compuesto por ocho teclas conformadas en un teclado lineal conectado a un codificador de 8 a 3 líneas BCD. El codificador se conecta a través de tres líneas de entrada/salida. El control de antirrobote se implementa por software y no están definidas teclas especiales. La función del teclado es permitir al usuario seleccionar los diversos modos y funciones disponibles para el equipo, como por ejemplo selección de derivación, ganancia y/o filtro notch aplicado, entre otras.

2.1.2. Multiplexor de Entrada. Al tratarse de un electrocardiógrafo es necesario poder obtener las distintas derivaciones, las cuales se implementan mediante el uso de un multiplexor que permite realizar la combinación de los biopotenciales presentes sobre el paciente, y los cuales luego serán amplificados. Para el control de este bloque se emplean cuatro puertos de entrada salida del microcontrolador.

2.1.3. Etapa de acondicionamiento. En un electrocardiógrafo tenemos una etapa de acondicionamiento que tiene como objetivo principal adecuar la amplitud del biopotencial a un valor tal que nos entregue la mayor información posible luego de que ésta sea digitalizada. Debido a que de un individuo a otro las señales biopotenciales cambian tanto en su amplitud, como en su frecuencia y composición espectral, es que debemos disponer de una etapa que nos permita tener señales comparables entre una persona y otra.

2.1.4. Filtrado. La composición espectral de las señales acondicionadas nos puede permitir determinar una cierta patología, pero si se encuentra afectada por ruido es posible no llegar a una determinación correcta.

Entre las componentes espectrales que afectan la señal obtenida se encuentran las señales a modo común, que se inducen sobre el dispositivo y sobre las conexiones de éste con el paciente. En particular la señal a modo común tiene como frecuencia característica 50Hz. Por este motivo se introduce en el circuito de acondicionamiento un filtro tipo Notch, con el cual se pretende atenuar los efectos nocivos de esta frecuencia sobre la señal a ser amplificada. Esta etapa se controla a través de un decodificador de dos a cuatro conectado a dos puertos de entrada salida del microcontrolador.

2.1.5. Amplificador de ganancia programable. Debido a la variabilidad de la amplitud que se presenta en la señal acondicionada es necesario el uso de un amplificador. Se emplea entonces para tal fin un amplificador de ganancia programable en los siguientes pasos, x1, x2, x4, x5 y x10. Para poder seleccionar el paso deseado se emplea la interfaz de comunicación serial síncrona SPI a través de la cual se envían los comandos de configuración desde el microcontrolador.

2.1.6. Tensión de offset programable. Una de las condiciones de diseño establece la necesidad de trabajar con señales amplificadas montadas sobre una tensión de offset que permita obtener la máxima excursión de la tensión de entrada aplicada al conversor AD. Esta tensión programable se obtiene de un chip dedicado para tal fin y que se controla mediante el protocolo SPI desde el microcontrolador.


2.1.7. Conversor Analógico Digital ADC. La conversión de las señales analógicas en digitales se realiza empleando un ADC de 12 bits, el cual entrega el valor digital mediante el uso de la interfaz SPI. La frecuencia de conversión máxima es de hasta 100kbps.

2.1.8. Decodificador selector de módulos. El uso de múltiples etapas en el diseño del electrocardiógrafo crea la necesidad de aumentar las líneas de entrada salida de control. Para ello se utiliza un decodificar de tres a ocho para obtener de esta manera una ampliación en cinco unidades de los pines de control del microcontrolador.

2.1.9. Etapa Digital. El control de todas las etapas antes mencionadas es realizado por un microcontrolador 18F4550, el cual cuenta con RAM: 2048 bytes, ROM: 32768 bytes, 3 timers, interfaz SPI, interfaz USB e interfaz USART, entre otros parámetros.

2.1.10. Display de cristal líquido inteligente. La información digitalizada es presentada sobre un LCD gráfico de matriz 240x64 píxeles. Sobre éste se muestran sumados a la grafica de la señal adquirida todos los datos de estado del electrocardiógrafo, como por ejemplo ganancia, filtro aplicado, derivación, etc. Emplea 10 líneas de entrada salida para la comunicación con el microcontrolador.

2.1.11. Interfaz de comunicación. Atento a la posibilidad de realizar postprocesamiento, realizar almacenamiento de estudios en una base de datos y aumentar la resolución en la presentación de la información gráfica, es necesario disponer de un medio para transmit ir la información adquirida a un computador personal. Se emplea la interfaz USART disponible y mediante el uso de un optoacoplador se obtiene el aislamiento galvánico requerido para este tipo de dispositivo. Luego de ello se intercala un conversor a protocolo USB.

Tabla 1. Módulos y su conexión con el CPU

Módulo Conexión Módulo Conexión Teclado Matricial 3 líneas I/O Conversor Analógico

Digital SPI por software

Multiplexor de Entrada 4 líneas I/O Decodificador selector de módulos

3 líneas I/O

Etapa de Acondicionamiento Etapa Digital Filtrado 1 líneas I/O Display de Crystal Líquido 10 líneas I/O Amplificador de Ganancia Programable

SPI por software Interfaz de Comunicación Interfaz USART

Tensión de Offset Programable SPI por software

2.2. Interacción entre los diversos módulos Como se menciono anteriormente cada módulo tiene asociada una función específica, la que debe ser realizada en el momento oportuno de manera de obtener una sincronía y para así conseguir el resultado esperado. En la Tabla 2 se presenta el ejecutivo cíclico que controla cada uno de los módulos que componen el electrocardiógrafo.

Cada una de las etapas/tareas debe estar correctamente sincronizada en el tiempo de manera de poder ejecutar un ciclo completo dentro del tiempo establecido, debido a que la frecuencia de conversión es de 500Hz, este tiempo es de 2mSeg.


Por otro lado se debe tener en cuenta que el ciclo completo de presentación en pantalla es de 10mSeg. En la Tabla 3 se enumeran los tiempos tanto mínimos como máximos necesarios para completar cada etapa/tarea.

Tabla 2. Ejecutivo Cíclico – Seudo código – Diagrama de flujo

Descripción Diagrama de Flujo 1- Leer_teclado

a. Modificar parámetros de adquisición i. Filtrado

ii. Ganancia iii. Offset iv. Derivación

2- Borrar_pantalla

3- Procesamiento - Filtrado digital

4- Escribir píxel – Dibujar línea

5- Esperar tiempo de nueva ciclo compuesto por cinco capturas (25mm/seg). Estado IDLE mediante una bandera que cambia de estado.

6- Repetir paso 1-

Tabla 3. Tiempos necesarios para cada proceso.

Proceso Tiempo mínimo Tiempo máximo

Leer_teclado 0.2 mSeg 0.2 mSeg Borrar_pantalla 8.6 mSeg 10.47 mSeg Dibujar línea 0.55 mSeg 3.55 mSeg Conversor AD 0.320 mSeg 0.320 mSeg Envío de datos vía USART 0.100 mSeg 0.100 mSeg Tiempo Total de CICLO 9.77 mSeg 14.64mSeg

Del relevamiento surge que el proceso Borrar_pantalla demanda más de 10 mSeg, por lo que es

necesario dividir lo en dos etapas, es decir que se ejecute completamente cada dos ciclos de impresión en pantalla . Adicionalmente debido a la resolucion de pantalla disponible sólo es posible imprimir un punto por cada cinco datos adquiridos por el ADC.

Hay que tener presente que además existen otros procesos, los que sumados deben poder completarse dentro de los 10mSeg establecidos.

Si se piensa en el envío de la información convertida a una PC, es necesario definir una velocidad de transmisión acorde. Como dificultad adicional se menciona que por tener una conversión de 12 bits, son necesarios al menos 2bytes por cada valor adquirido, y por tratarse de una transmisión asincrónica sin control de flujo , para garantizar la correcta interpretación de los datos recibidos por parte del PC, se introduce un byte marcador en cada paquete de transmisión. Queda como resultado que para cada dato convertido se deben transmitir 3 bytes, por lo que la velocidad de transmisión debe ser mayor o igual a 19200bps.


Resumiendo, se puede apreciar en la Figura 1, la sincronización necesaria entre cada proceso con el fin de evitar la pérdida de datos. Se debe tener en cuenta que el control del inicio de cada repetición se realiza mediante el uso de uno de los timers disponibles.

Figura 1. Diagrama Temporal Ejecutivo Cíclico

2.3. Empleo de un Sistema Operativo de Tiempo Real El uCOS-II es un Sistema Operativo de Tiempo Real [4](RTOS kernel) que permite hacer ejecución multitarea de tipo preemptivo. (Interrupción de la ejecución de un proceso cuando otro de mayor prioridad se encuentra en condiciones de ser ejecutado).

Además dispone de elementos denominados en forma genérico “Eventos”, tales como mailbox, semáforos o queues (colas) entre otros para realizar la sincronización y/o transferencia de datos entre procesos. A su vez cuenta con funciones para el control de tiempo y puede suspender o reiniciar procesos, como así también eliminar cualquiera de ellos.

Se debe tener presente y será parte del análisis que sigue , cuales son los requisitos de mínimos recursos de hardware necesarios para que el port PIC18 del RTOS pueda ser embebido en la plataforma de desarrollo con éxito [5] [6].

El RTOS a través de la prioridad asignada a cada proceso determina cual de ellos se ejecuta primero. Éste valor se define entre cero y un valor máximo configurable ,. Esta capacidad permitiría por ejemplo tener el proceso conversión_ADC con la mayor prioridad, por lo tanto se ejecutaría con la frecuencia establecida, y en el tiempo restante cada uno de los otros procesos definidos.

Una de las ventajas del uso de un RTOS es poder utilizar el tiempo que antes se empleaba para consumir ciclos de reloj, por ejemplo para introducir demoras, en la ejecución de un proceso/ tarea determinada.

2.4. Requerimientos del sistema para usar RTOS. El sistema RTOS empleado requiere de RAM y ROM para poder implementar sus funcionalidades por lo que es muy importante conocer a fondo cuales son sus necesidades mínimas de recursos.


A continuación se describen los módulos de software que componen el RTOS y sus necesidades específicas de hardware.

Para funcionar el RTOS necesita por cada tarea que integre el sistema, un Bloque de Control de Tarea; TCB, y por cada elemento de sincronización un Bloque de Control de Eventos; ECB. La cantidad total de TCB’s y ECB’s dependerá de cómo se estructure el sistema definitivo.

Una de las características del RTOS es la posibilidad de modificar la configuración del mismo, y por lo tanto sus capacidades intrínsecas, es decir habilitar y/o deshabilitar funciones propias para obtener el menor tamaño del ejecutable resultante. La correcta configuración nos permite el ahorro de memoria, tanto de RAM como de ROM. Por otro lado también es posible definir el modo de administrar el stack disponible para las distintas tareas. Este puede ser modo Mínimo o modo Extendido. En el modo Extendido el usuario puede conocer en todo momento cual es la demanda de stack por parte del proceso analizado.

Se presenta en la Tabla 4 el detalle de las cantidades de RAM y ROM asociadas a las distintas posibilidades de configuración de nuestro sistema.

Tabla 4. Capacidad de memoria necesaria para implementación con RTOS

Proceso Modo ROM RAM bytes Modo Mínimo 4712 Bytes

uCOS II – PIC18 Modo Extendido 5363 Bytes Modo Mínimo 14 Bytes

TCB Modo Extendido 26 Bytes

ECB Ambos Modos 8 Bytes Modo Mínimo 322 124 Bytes

Tarea Estadística Modo Extendido 973 220 Bytes

USO de SEMAFOROS Ambos Modos 1870 24 Bytes USO de MAILBOX Ambos Modos 2108 30 Bytes

MAILBOX + SEMAFOROS Ambos Modos 3139 30 Bytes Cada tarea para poder interactuar con las otras necesita de una prioridad y de un stack asociado. La

definición de la cantidad de stack es muy importante, y depende totalmente de factores como, la sobrecarga del CPU debido al Kernel, es decir cuantas veces por segundo se invoca al scheduler, la cantidad de tareas que conforman el sistema completo, y la duración en tiempo de cada una de ellas, entre otras.

Cada vez que el scheduler pone una tarea en estado Waiting, éste almacena en el stack asociado a la misma su contexto, de manera que cuando tenga la posibilidad de volver al estado Run, lo haga en el lugar del programa en que había quedado. La asignación incorrecta del stack de cada proceso, puede provocar que el sistema se vuelva inestable. En la figura 2 [5] se presentan los estados posibles que puede tomar cada proceso.

En el modo mínimo se almacena en el TCB asociado solo la prioridad y el tamaño del stack, mientras que en el modo Extendido también se almacena donde inicia y donde termina el mismo. De esta manera es posible mediante el uso de funciones definidas para tal fin , conocer en cualquier instante de tiempo cual es el porcentaje de stack utilizado. Esta funcionalidad permitiría definir el valor óptimo de stack para cada tarea teniendo como premisa el máximo aprovechamiento del recurso RAM. El TCB de cada tarea también cambia su configuración dependiendo del modo empleado, ya sea mínimo o extendido.


Figura 2. Estados definidos para el sistema Por otro lado es necesario además de conocer cual es el uso dinámico de RAM stack, cuan

sobrecargado se encuentre el CPU. La sobrecarga puede provocar que el CPU no llegue a completar un proceso, antes de que el mismo deba volver a ser ejecutado. Esta situación se puede deber a que se tienen más tareas de las que el sistema puede procesar, o que el tiempo de las mismas sea más pequeño que el tiempo mínimo del CPU. Para minimizar la sobrecarga es necesario conocer cual es el valor porcentual del uso del mismo. Si este valor llega a 100% el sistema se puede volver inestable. Para obtener este valor, el sistema dispone de una tarea de estadística, la cual también consume recursos valiosos. Resulta finalmente que esta tarea solo debe compilarse al momento de la evaluación y no en el producto final.

Luego de la cuantización de cada una de las capacidades del sistema queda que para el uso del uCOS-II en un PIC18 son necesarios 7600 bytes de ROM y 925 bytes de RAM aproximados. Es decir que alrededor de un 50% de ambas memorias son requeridas para usar el RTOS sobre el microcontrolador seleccionado.

3. Resultados

3.1. Definición de procesos o tareas. Luego del análisis de cada uno de los módulos que componen el electrocardiógrafo se determinaron las tareas (también llamados procesos) que debieran componer el sistema general. Por este motivo quedan definidas cinco tareas, las cuales se describen a continuación.

3.1.1.1 Proceso Tarea_Conversion Este proceso comunica al microcontrolador con el conversor AD mediante interfaz serial sincrónica SPI y se ejecuta con un período de 2mSeg. El resultado de la conversión es enviado a las tareas Tarea_LCD y Tarea_COM, mediante el uso de eventos. Se debe mencionar que la interfaz SPI está implementada por software.

3.1.1.2 Proceso Tarea_Leer_Teclado Este proceso se ejecuta con un período de 200mSeg y realiza la lectura del valor de tecla presionada del codificador 10 a 1. Este proceso se debe ejecutar luego que el conversor AD complete una conversión, ya que ambos módulos emplean la interfaz SPI. El proceso puede en función de las teclas presionadas cambiar las configuraciones del amplificador de ganancia programable y de la tensión de referencia programable los cuales también emplean el módulo de comunicación SPI por software.


3.1.1.3 Proceso Tarea_LCD. Este proceso se ejecuta luego del proceso Tarea_Conversion con el valor recibido a través de un mailbox. El valor empleado se origina en el proceso antes mencionado.

3.1.1.4 Proceso Tarea_COM Este proceso se ejecuta luego del proceso Tarea_LCD con el valor recibido a través de un mailbox generado en el proceso Tarea_Conversion. Dicho valor se transmite a una PC a través de interfaz de Hardware USART disponible.

3.2. Esquema de interacción entre tareas Se presentan en la figura 3 las interacciones de cada uno de los procesos antes mencionados.

Figura 3. Interacción entre todos los procesos definidos para el sistema evaluado

Podemos resumir que para una configuración en donde se emplean 5 procesos, son necesarios

como mínimo 40 bytes para el control de los mismos por parte del scheduler. En ese mismo sentido el uso de Eventos, es decir mailbox, o semáforos, también requiere de la

reserva de RAM para los ECB de cada uno de ellos. Para el óptimo aprovechamiento del recurso físico disponible de hardware fue necesario el uso de

los eventos para poder sincronizar cada proceso con el otro. Se presentan en la tabla 4 a modo de ejemplo los procesos Task_LCD y Conversión_Task definidos sobre la plataforma RTOS.

El módulo más critico al momento de trabajar en modo multitasking fue la interfaz serie de comunicación SPI. Debido a la imposibilidad de emplear el hardware especifico, ya que se decidió utilizar los pines de I/O con otro fin, se debió implementar la comunicación serial síncrona SPI por software. Al tratarse de un uso compartido del mismo canal desde dos procesos independientes, fue necesario el uso de semáforos para la sincronización de los mismos. Como los procesos Conversión_Task y el Teclado_Task pueden acceder al mismo recurso, se hizo uso de sendos semáforos para la sincronización entre ellos.


Tabla 4. Procesos Task_LCD y Conversión_TASK

void Task_LCD(void *pdata) { #if OS_CRITICAL_METHOD == 3 OS_CPU_SR cpu_sr; #endif char *rxmsg; INT8U err; INT16U valor_LCD; x=0;inicio = 0;fin = 25; for(;;) { rxmsg = (char *)OSMboxPend(COM_Mbox, 0, &err); // Espera mensaje de Conversion_TASK if(err == OS_ERR_PEND_ISR) valor_LCD = 0; else if(err == OS_ERR_PEVENT_NULL) valor_LCD = 0; else if(err == OS_ERR_EVENT_TYPE) valor_LCD = 0; else if(err == OS_ERR_PEVENT_NULL) valor_LCD = 0; else valor_LCD = *rxmsg; cuenta++; if(cuenta>=7) { bloquex++; cuenta=0; if(bloquex>=29) { bloquex = 0; x=0; } }

void Task_Conversion(void *pdata) { #if OS_CRITICAL_METHOD == 3 OS_CPU_SR cpu_sr; #endif INT8U cant_datos; INT16U dato_ADC, maximo_ADC; for(;;) { cant_datos++; if(Bits1.bit1_velocidad_25_50mm){ // si es 1 barro 25 puntos por segundo if(cant_datos>=10) { Bits1.bit1_interrupcion=1; // salgo del loop infinito e imprimo punto cant_datos=0; } } else { if(cant_datos>=5) { Bits1.bit1_interrupcion=1; cant_datos=0; } } dato_ADC = Leer_Adc(); if(dato_ADC >= 4096) dato_ADC = 4096; if(dato_ADC >= maximo_ADC) maximo_ADC = dato_ADC; if(Bits1.bit1_interrupcion){ Bits1.bit1_interrupcion = 0; if( OSSemAccept( ADC_Sem ) ) { OSSemPost( TECLADO_Sem ); } OSMboxPost(LCD_Mbox, (void *)&maximo_ADC); OSMboxPost(COM_Mbox, (void *)&maximo_ADC); maximo_ADC = 0; }

Se presenta en la tabla 5 el resumen de los recursos necesarios luego de la completa migración del

ejecutivo cíclico a la plataforma RTOS, en donde se muestra una comparativa del costo en recursos tanto en la versión ejecutiva cíclica como en la versión multitarea.

Tabla 5. Resumen de recursos necesarios

Recurso Ejecutivo Cíclico % RTOS % RAM 614 bytes 29,98% 1101 bytes 53,76% ROM 4268 bytes 26,05% 11544 bytes 70,46%

Composición del Sistema

* Proceso de Conversión Controlado por Interrupciones

* Polling del resto de procesos

* 5 TAREAS * 4 EVENTOS

* Mail Box Habilitado * MODO Mínimo


4. Conclusiones El uso de un RTOS para las tareas asociadas al CPU de un electrocardiógrafo genera un cambio en la definición de las operaciones a realizar por cada uno de los bloques que componen el sistema.

Por otro lado acerca los conceptos actuales de multitarea, otorgando al sistema resultante un alto grado de aprovechamiento de la capacidad de procesar del CPU.

Las dificultades que se presentan al momento de decidir el uso del RTOS para la implementación sobre la plataforma ya desarrollada, son la posibilidad de contar con los recursos de RAM y ROM mínimos, y el eventual cambio del microcontrolador, como así también la factibilidad de implementación sobre una plataforma RTOS libre de licencia o la consideración del costo asociado a la licencia de distribución, si es que la hubiera.

Desde el punto de vista de la estabilidad del software en el equipo migrado, es necesario poder comparar el comportamiento de la versión basada en RTOS con el diseño original sobre la forma ejecutivo cíclico para lo cual serían necesarios dos equipos electrónicos.

Debido a que el trabajo de análisis y su posterior migración se realizo sobre una plataforma existente, fue necesario el ajuste de los bloques de software disponibles, con el objetivo de minimizar el uso de las memorias RAM y ROM. Dentro de estas operaciones se procedió a la eliminación de variables antes empleadas, que al cambiar de metodología de trabajo ya no eran necesarias.

Se debe mencionar que el electrocardiógrafo se encuentra trabajando correctamente, pero no es factible agregarle mayor funcionalidad a las que tenía inicialmente, debido a la poca disponibilidad de memoria ROM para este microcontrolador luego de la implementación del RTOS. Sin embargo es posible pensar en utilizar el microcontrolador 18F4675 con la finalidad de incrementar funcionalidades, sin necesidad de modificar la plataforma física.

Con el respecto a la aplicación final se puede establecer que la misma interactúa correctamente con el hardware asociado, siendo por lo tanto factible la implementación del RTOS sobre el dispositivo ya desarrollado.

Referenc ias [1] Monitor de Pulsos cardíacos con Interfaz a PC. SABI 2003. Córdoba. Argentina. 2003 [2] Procesamiento digital sobre monitor cardíaco. CLAIB 2007. IV Congreso Latinoamericano de

Ingenieria Biomédica. Caracas. Venezuela. 2007 [3] Sistema para el análisis de la Morfología de la señal de ECG de ratones de Laboratorio

Infectados con Mal de Chagas. CBEB 2010. Crongreso Brasileiro de Ingenieria Biomédica. [4] Sistema de transmisión de datos médicos para centros de salud de zonas alejadas. SABI 2007. [5] uCOSII, The Real-Time Kernel , Jean J. Labrosse, R&D Technical Books, 1998,ISBN 0-

87930-543-6. [6] MPLAB-uCOS-II-PIC18 Version 2.51 www.micrium.com


Electrocardiógrafo portátil basado en RTOS · de microcontroladores, los uales permiten dotar dec...

Documents

Transcript of Electrocardiógrafo portátil basado en RTOS · de microcontroladores, los uales permiten dotar dec...