utilización de la api win32 para el control de la comunicación serie

UTILIZACIÓN DE LA API WIN32 PARA EL
CONTROL DE LA COMUNICACIÓN SERIE EN
UN SISTEMA PARA PRUEBA DE ESFUERZO
N. Gómez, M. Cañizares, O. Mora, M. de la Parte, A. Guía, J. A. Rodríguez
Instituto Central de Investigación Digital
Calle 202 #1703 e/ 17 y 19, Siboney, 11600 La Habana, Cuba;
E-mail: [email protected]
RESUMEN
Este trabajo explica el procedimiento utilizado para el control de la comunicación serie
entre un electrocardiógrafo comercial y una computadora personal (PC) en el sistema para
la automatización y control de la prueba de esfuerzo denominado EXECG-100. El método
propuesto emplea las herramientas que brinda la API Win32 de Microsoft para la
comunicación por puerto serie y el control de la prioridad de las aplicaciones. Permite la
adquisición de los datos y su procesamiento en tiempo real. Se ha utilizado durante más de
un año con resultados satisfactorios. Ha sido probado en diferentes arquitecturas
compatibles con IBM demostrando su aplicabilidad en motherboards Pentium o superior.
Se realizaron pruebas de funcionamiento ejecutando el EXECG-100 con otras
aplicaciones, obteniéndose buenos resultados. Solo se detectaron problemas cuando se
emplean programas antivirus residentes. Las soluciones obtenidas son aplicables para el
monitoreo de cualquier señal biomédica y válidas para cualquier plataforma Windows®.
Palabras clave: comunicación serie, Win32, monitoreo de bioseñales, prueba de esfuerzo,
Windows.
USE OF WIN32 API FOR THE CONTROL OF SERIAL
COMMUNICATION IN A STRESS TEST SYSTEM
ABSTRACT
In this work the authors explain a procedure to control the serial communication between a
commercial electrocardiograph and a personal computer in a system for automated and
control of stress test named EXECG-100. The proposed method employs the tools
contained in Microsoft’s Win32 API for serial communication and control of the
application’s priorities. It allows the acquisition of data and its real-time processing. It has
been used for more than a year with satisfactory results. It has been tested on different
IBM-compatibles architectures showing its applicability on Pentium-powered same or
superior motherboards. Working test were realized executing EXECG-100 with other
applications, obtaining good results. Some problems were detected only when use resident
antivirus software. The solutions obtained can be applied to monitor any biomedical signal
and are valid for any Windows® platform.
Keywords: serial port communication, Win32, biosignal monitoring, ECG stress test,
Windows.
31
Bioingeniería y Física Médica Cubana
1. INTRODUCCIÓN
El auge alcanzado por la computación en los últimos años ha potenciado la utilización de
las computadoras personales (PC) en la solución de problemas biomédicos de diversa
índole.
Fig.1. Partes componentes de un
sistema electrocardiográfico basado
en PC: Computadora, software
analizador y electrocardiógrafo.
Una gran variedad de sistemas de adquisición de datos médicos se encuentra disponible en
el mercado. Básicamente un sistema biomédico basado en PC consta de un módulo
encargado de la adquisición de las bioseñales (ECG, EEG, etc.) y una computadora con un
software instalado para el procesamiento y análisis de la misma (figura. 1).
Los módulos de adquisición pueden ser externos o internos, aunque los más corrientes son
los externos por ser más fáciles de instalar por el propio usuario. La conexión entre el
dispositivo externo y la PC puede establecerse a través de los puertos que posee la PC:
serie, paralelo, infrarrojo, Bus Serie Universal (USB), etc. Aunque la tendencia actual es el
uso del USB, la comunicación serie tradicional es indudablemente la más utilizada, ya que
todas las computadoras con arquitectura IBM PC tienen al menos un puerto RS232
disponible [5].
A pesar de no ser el mejor sistema operativo, de presentar numerosos bugs y muchas
limitaciones para realizar sobre él aplicaciones profesionales, el número de usuarios que
emplean Windows® como sistema operativo se incrementa cada día por su interfaz
amistosa, su amplio uso, compatibilidad y la gran cantidad de programas desarrollados
sobre esta plataforma. Esto ha traído como consecuencia que la mayoría de los fabricantes
de sistemas basados en PC lancen al mercado equipos con sus aplicaciones para
Windows®.
La realización de las pruebas de esfuerzo de ECG requiere la recolección, visualización y
procesamiento de hasta 12 derivaciones de ECG simultáneas en tiempo real. Por esa razón,
se propuso desarrollar un procedimiento que permitiera la recepción a través de un puerto
serie de las señales de ECG, su procesamiento y análisis en tiempo real en ambiente
Windows®.
2. METODOLOGÍA
2.1 Requisitos del Software
Los requisitos de la aplicación realizada hicieron necesario realizar la recolección y
procesamiento de las señales en tiempo real. Un sistema de tiempo real es aquel cuya
respuesta a variaciones en la entrada es suficientemente rápida en comparación con los
requisitos de trabajo del sistema. En el caso de un sistema para realización de pruebas de
esfuerzo (o ergométricas), la respuesta del sistema puede demorarse ocasionalmente hasta
32
Bioingeniería y Física Médica Cubana
8 a 12 ms sin que sea perceptible para el usuario (médico que realiza la prueba), pero es
conveniente que sea menor que 4 ms, que es el intervalo de muestreo.
Las posibles soluciones de software deben asegurar el procesamiento de un volumen
considerable de información que implica la realización de las siguientes tareas:
• Recogida de información: por puerto serie a una velocidad de 57600 baud para recibir 8
canales de ECG muestreados a 250 Hz, con 12 bits de resolución, en forma de paquetes
con chequeo de suma. De esta forma se cumple con las recomendaciones de la
American Heart Association para prueba de esfuerzo[1].
• Mostrar por pantalla informaciones de la prueba: incluye la forma de onda de un grupo de
canales y otros parámetros numéricos y gráficos.
• Identificación de ondas del ECG: complejos QRS, complejos atípicos, etc.
• Medición de ondas y parámetros: amplitudes e intervalos dentro de los complejos QRS,
frecuencia cardiaca (FC), etc.
• Clasificación de complejos, comparación por correlación y promediación.
• Control general de la prueba: tiempo por etapa y total según el protocolo.
• Control de periféricos: manejo del equipo para la realización del ejercicio físico.
• Chequeo de condiciones peligrosas y emisión de alarmas: arritmias, EV, variaciones de la
FC, etc.
El sistema realiza otras tareas que no requieren de respuesta en tiempo real, como son las
tareas antes de la recogida de información, la elaboración y emisión de reportes y las tareas
asociadas al manejo de la información resultante de las pruebas.
2.2 Alternativas de diseño
Para implementar el sistema se evaluaron dos soluciones posibles para realizar la recogida
de información:
Desarrollo y uso de un Virtual Device Driver:
Un Virtual Device Driver (o VxD) es una rutina o un conjunto de rutinas que implementan
operaciones de entrada/salida de forma específica para un dispositivo. Cuando se tiene un
dispositivo para el cual Windows® no posee un VxD se hace necesario buscar o escribir
uno, pero este no es el caso de los puertos de comunicación. La atención a los mismos se
realiza por la API Win32, en modo Kernel lo que provee el acceso más privilegiado a los
recursos del sistema [6].
Por esto desechamos esta alternativa, ya que las funciones que brinda el sistema le son
necesarias para garantizar la seguridad y la estabilidad de su funcionamiento.
Uso de la API Win32:
La Application Programming Interface (API) Win32 define un conjunto de funciones que
intercambian información con el sistema operativo, las cuales pueden ser usadas por los
programas de aplicación para llevar a cabo su trabajo. La información vinculada con sus
características y formas de utilización aparecen en la docume ntación que brinda Microsoft
para programadores especializados en Windows®, llamada Microsoft Software
Development Network (o MSDN).
Microsoft ha implementado la API Win32 para cada uno de sus variantes de Windows.
De esta forma cada sistema operativo es optimizado para cada situación en específico[2].
Por tanto una de las ventajas de desarrollar una aplicación bajo los requisitos de la API
Win32 es que esta aplicación podrá ser ejecutada sobre cualquier sistema operativo que se
adhiera a esta normativa (Windows NT/2000, Windows 95/98/Me).
33
Bioingeniería y Física Médica Cubana
La Win32 consta de alrededor de 300 funciones que proveen todos los servicios que el
usuario espera en un sistema operativo multitarea. Entre ellos: asignación de memoria,
acceso a ficheros y dispositivos de entrada/salida, control, sincronización y comunicación
entre hilos de una aplicación, etc. [4]. Es por eso que se ha incrementado el uso de Win32
para el desarrollo de aplicaciones en tiempo real [3].
2.3 Uso de la API Win32
Existen dos formas de realizar la lectura de los datos del puerto serie: encuestar el puerto
continuamente chequeando que haya llegado la cantidad de bytes que forman el paquete, o
mandar a leer todos los bytes del paquete y esperar hasta que se reciba el paquete
totalmente o salga por timeout.
Luego de varias pruebas se optó por la segunda variante, ya que la primera ocupa mucho
tiempo del procesador, necesario para acometer todas las tareas descritas en 2.1.
Para implementar la solución de lectura por paquetes se emplearon varias funciones de la
API Win32 a fin de lograr dos objetivos:
•
•
Utilizar el Timer Multimedia para darle el control a una rutina cada un cierto tiempo.
El Timer Multimedia permite interrumpir cualquier otra tarea que se esté ejecutando.
Realizar la lectura del bloque de información en el puerto serie y colocar la
información recibida en una cola para su posterior procesamiento en el procedimiento
principal de la aplicación.
Teniendo en cuenta que la señal es digitalizada empleando una determinada frecuencia de
muestreo, se tomó el intervalo de muestreo como intervalo para que sea invocada la rutina
Timer donde se realiza la lectura del puerto serie.
Un diagrama de flujo del método utilizado se muestra en la figura 2 y es descrito a
continuación.
2.3.1 Abrir y configurar el puerto serie
El puerto serie seleccionado para la comunicación entre el electrocardiógrafo y la PC se
abre y se configura definiendo velocidad de transmisión, bits de inicio, bits de parada,
paridad, etc. Para ello se usaron las siguientes funciones:
CreateFile : Crea o abre el dispositivo de comunicación.
SetupComm: Fija tamaño de los buffers de entrada y salida. El tamaño del buffer de
entrada utilizado fue de 1024 bytes. Ello se debe a que cuando se programa el Timer,
llegan un número elevado de bytes que no se emplean, pero que si se pierden dificultan la
sincronización inicial con el electrocardiógrafo.
Getcommstate: Llena una estructura (DCB) con las especificaciones del puerto
seleccionado.
SetCommstate: Configura el puerto seleccionado en cuanto a velocidad de transmisión,
bits de inicio, bits de parada y paridad.
34
Bioingeniería y Física Médica Cubana
Fig.2. Diagrama de flujo del
método propuesto.
Abrir y configurar puerto serie
Elevar prioridad aplicación
Establecer protocolo inicial con electrocardiógrafo
NO
1er paquete
recibido
SI
Activar Multimedia Timer
Procesar y analizar señal
NO
Fin de la
prueba
SI
Desactivar Multimedia Timer
Terminar intercambio de información
Restaurar prioridad aplicación
Cerrar puerto serie
2.3.2 Elevar la prioridad de la aplicación
La API Win32 ofrece funciones que permiten variar la prioridad de una aplicación y de un
hilo de ejecución dentro de ella. Utilizando la función SetPriorityClass se puede definir la
prioridad de una aplicación como: HIGH, IDLE, NORMAL y REALTIME.
35
Bioingeniería y Física Médica Cubana
Con la función SetPriorityThread se puede definir la prioridad de un hilo como:
ABOVE_NORMAL, BELOW_NORMAL, HIGHEST, IDLE, LOWEST, NORMAL y
TIME_CRITICAL.
La combinación de las prioridades de la aplicación y del hilo determina la prioridad base
del hilo en ejecución.
Para elevar la prioridad de la aplicación se utilizó la combinación de HIGH como prioridad
de la aplicación y TIME_CRITICAL como prioridad del hilo principal de la aplicación.
Aunque a primera vista parece obvio el uso de la prioridad REALTIME, esta no se puede
usar en este caso pues con ella la aplicación no puede recibir los eventos del teclado y del
mouse.
2.3.3 Establecer protocolo inicial con el electrocardiógrafo.
Realiza el intercambio de comandos inicial entre el electrocardiógrafo y la PC.
Para el envío y recepción de comandos/datos por el puerto serie deben utilizarse las
funciones:
Readfile : Lee n datos del puerto seleccionado.
Writefile: Escibe datos en el puerto seleccionado.
2.3.4 Verificar recepción del primer paquete de datos
La recepción del primer paquete de datos permite la sincronización entre el
electrocardiógrafo y la función que realiza la lectura de los datos del puerto.
2.3.5 Activar el Timer Multimedia
Una vez que llega el primer paquete de datos se activa el Timer Multimedia utilizando la
función TimeSetEvent que hace que se ejecute una función callback que es la rutina que
realiza la lectura del paquete de datos del puerto serie. El intervalo fijado fue de 4 ms, el
cual coincide con el intervalo de muestreo de las señales analógicas del ECG. Para que la
interrupción se realice con la mayor precisión posible, se utilizó la resolución de 0 para el
Timer Multimedia.
Si los datos llegaron correctamente (cantidad de bytes y checksum), se ponen en una cola
para su procesamiento por parte del hilo principal de la aplicación. Si hubo algún error en
la transmisión, se pone en la cola la última muestra correcta, minimizando los efectos
negativos de la pérdida de información.
2.3.6 Procesar y analizar la señal recibida
El procesamiento y análisis de la señal se organizó de forma tal que el sistema responda en
tiempo real. Las tareas del sistema se ordenaron por prioridades y se dividieron en
pequeñas sub-tareas para lograr que su ejecución no demorase la atención de tareas más
prioritarias.
El empleo de una cola para almacenar los datos de entrada permite que ocasionalmente el
procesamiento de las muestras pueda demorar más tiempo que el previsto sin pérdida de
información, e independiza la recepción de los datos del algoritmo de análisis. El tamaño
de esta cola se fijó de acuerdo con las características de la aplicación y su procedimiento
de análisis.
2.3.7 Desactivar el Timer
36
Bioingeniería y Física Médica Cubana
Una vez que finaliza la prueba, se desactiva el Timer Multimedia. Para ello se utiliza la
función TimeKillEvent.
2.3.8 Terminar intercambio de información con el electrocardiógrafo.
Se intercambian comandos para finalizar la transmisión de datos.
2.3.9 Restaurar la prioridad de la aplicación
Una vez finalizada la transmisión no es necesario que la aplicación monopolice el control
del procesador, por lo que se restaura la prioridad de la aplicación y de su hilo principal a
NORMAL.
2.3.10 Cerrar el puerto serie
El puerto serie debe ser liberado mediante la función Closehandle.
3. RESULTADOS Y DISCUSIÓN
El software descrito en el trabajo fue programado en Borland Delphi 5.0. El mismo ha sido
probado rigurosamente durante un año en el ICID y está en proceso de evaluación por la
firma productora del electrocardiógrafo ECG-310B, Dr. Lee Co. Ltd. de Corea del Sur.
Este trabajo es el resultado del esfuerzo conjunto para desarrollar un sistema
electrocardiográfico basado en PC para prueba de esfuerzo.
Las condiciones de prueba fueron las siguientes:
•
•
Ejecutándose como única aplicación abierta, con diferentes arquitecturas compatibles
con IBM, apreciándose un buen desempeño en computadoras con microprocesadores
Pentium. Sin embargo, en las pruebas realizadas en PCs con microprocesadores 486,
se produjeron pérdidas visibles en la adquisición de los datos por la limitada
capacidad de procesamiento.
Ejecutándose sobre PC con microprocesadores Pentium con varias aplicaciones en
ejecución, obteniéndose buenos resultados. En estas condiciones solo se observaron
algunos problemas cuando se ejecutó el software con antivirus residentes,
detectándose la pérdida de algunos paquetes de información, aunque el efecto visual
no es perceptible.
El criterio asumido para evaluar los resultados fue calificarlo de “buenos resultados” en las
pruebas donde el programa no pierde el control, no hay perdida aparente de datos para el
usuario y la pérdida si la hay no compromete el funcionamiento del sistema desde el punto
de vista médico.
En conveniente destacar las imprecisiones potenciales de la evaluación ya que aun en
condiciones controladas no se puede garantizar el conocimiento de todas las tareas que
Windows® está ejecutando simultáneamente con el programa sometido a prueba.
4. CONCLUSIONES
Como resultado de este trabajo se obtuvo una solución robusta y segura para la
comunicación serie entre un electrocardiógrafo comercial y una computadora personal
(PC) que forma parte de un sistema para la automatización y control de la prueba de
esfuerzo denominado EXECG-100.
37
Bioingeniería y Física Médica Cubana
El método empleado proporciona una total independencia entre la adquisición de los datos
y su procesamiento simultáneos, dándole además al algoritmo de análisis la posibilidad de
demorarse en su ejecución ocasionalmente un tiempo mayor que el tiempo entre la toma
de muestras, haciendo uso de las funciones que ofrece la API Win32 para la comunicación
serie y la prioridad de la aplicación.
El uso de la API Win32 también asegura la compatibilidad de la aplicación con Windows
NT/2000, Windows 95/98/Me.
No obstante haberlo desarrollado para una aplicación específica, se considera que el
algoritmo puede ser usado en otras aplicaciones para la recolección de señales biomédicas.
REFERENCIAS
J. J. Bailey et al, “Recommendations for Standardization and Specifications in
Automated Electrocardiography: Bandwidth and Digital Signal Processing. A report for
Health Professionals by an Ad Hoc Writing Group of the Committe on
Electrocardiography and Cardiac Electrophysiology of the Council on Clinical Cardiology,
American Heart Association”, Circulation, vol 81, p 730-739, 1990.
[1]
[2]
M. Pietrek, “Which Win32 is for you?”, PC Magazine Vol 13, n16, p303-310.
[3]
R. M. Smith, “Win32 driving real-time applications”, Electronics engineering
times, n895, p62, 1996.
[4]
X. Teixeira, J. Pacheco, “Delphi 5 Developer’s Guide”, Sams Publishing, 2000.
[5]
W. Tompkins, “Biomedical Digital Signal Processing: C-language examples and
laboratory experiments for the IBM® PC”, Prentice Hall, 1993.
[6]
“NT drivers – FAQ- Basics: Kernel Mode Systems”,
http://www.cmkrnl.com/faq01.html/
38
Bioingeniería y Física Médica Cubana