DEPURACIÓN DE SISTEMAS INTEGRADOS DESCRIPCIÓN DE LA INVENCIÓN La invención se refiere a depuración de un programa en tiempo real . La depuración y herramientas de desarrollo para localizar y eliminar defectos o errores en programas para sistemas de procesamiento de datos se conocen bien. En el pasado, las herramientas de depuración eran incapaces de moni torear una memoria asociada cuando un programa estaba operando normalmente, lo cual se refiere como depuración en "tiempo real". La depuración en tiempo real permite la observación variable de datos durante la ejecución del programa para poder determinar si el programa está funcionando o no adecuadamente. Inicialmente , un programa de depuración se ejecutaba en la tarjeta principal de la computadora. Cuando ambos programas y los sistemas de procesamiento han incrementado en velocidad y complejidad, el incremento grande en datos y variables para observar durante una operación de depuración excedía la potencia de procedimiento de procesador y/o la producción del bus de datos para permitir la depuración en tiempo real de software que se ejecutaba en la computadora. En respuesta, el monitoreo de variables de datos se ha limitado a obtener actualizaciones variables sólo cuando el código no se está ejecutando o se detiene
intencionalmente . Las herramientas de depuración típicamente logran esto utilizando puntos de derivación, que detienen la ejecución del programa con la ocurrencia de eventos específicos. Las variables de datos generadas por el programa entonces pueden examinarse en el punto de derivación. Esto posee un problema, ya que el programa puede comportarse en forma diferente cuando se detiene que cuando está durante una operación normal. Además, esto crea limitaciones severas sobre las capacidades de depuración, ya que las variables de datos no se examinan entre puntos de derivación. Cuando es necesaria la depuración en tiempo real, el hardware externo relativamente costoso se utiliza. El dispositivo de depuración externa tiene suficiente velocidad de procesador y un bus de datos lo suficientemente rápido para efectuar la depuración en tiempo real. Muchas familias de procesadores no tienen la capacidad de proporcionar monitoreo o depuración variable en tiempo real. Por lo tanto, existe una necesidad de capacidad para depurar programas complejos en tiempo real utilizando sólo software de depuración estándar y el sistema de procesamiento de datos mismo . La invención se refiere a un sistema de procesamiento de datos que comprende una unidad de procesamiento central para ejecutar instrucciones para implementar un programa basado en eventos, una primera
memoria acoplada con la unidad de procesamiento central para almacenar valores de datos variables generados por las instrucciones variables del programa, un motor de eventos acoplado con la unidad de procesamiento central y la memoria para monitorear en tiempo real por lo menos uno de los valores de datos variables y determinar la ocurrencia de un evento basándose por lo menos en uno de los valores de datos variables, y un módulo de depuración acoplado con la unidad de procesamiento central y con el motor de eventos para recibir por lo menos uno de los valores de datos variables en tiempo real para llevar a cabo una depuración en tiempo real del programa . BREVE DESCRIPCIÓN DE LOS DIBUJOS En los dibujos: La Figura 1 es una ilustración esquemática de un sistema de procesamiento de datos que tiene un motor de eventos de acuerdo con la invención. La Figura 2 es una ilustración esquemática del motor de eventos de la Figura 1. La invención proporciona una forma para obtener actualizaciones variables en tiempo real en una forma configurable para permitir la depuración en tiempo real de un sistema de procesamiento de datos. La invención logra esto al utilizar un motor de eventos de una aplicación de software basada en eventos para observar la ocurrencia de eventos
predeterminados, que ejecuta el administrador de eventos del software para pedir la función apropiada para administrar el evento. Un mensaje que significa la ocurrencia de un evento entonces puede enviarse por lo menos a otro componente dentro del sistema de procesamiento de datos. La determinación de un evento se logra al monitorear los valores de las variables del programa y determinar si las variables indican la presencia de un evento. Estas variables pueden ser las mismas variables y sus valores pueden monitorearse como parte de una operación de depuración. El sistema de procesamiento de datos puede ser uno que puede utilizarse en cualquiera de un número de dispositivos electrónicos, tal como en un automóvil, una PC, un aparato doméstico, o cualquier otro dispositivo que utilice una computadora. Un dispositivo que incorpora la invención típicamente comprenderá uno o más componentes que realizan operaciones del dispositivo. Al emplear una arquitectura de software que permite la comunicación fácil entre componentes internos de un dispositivo y/o entre un componente externo y uno o más componentes internos del aparato, varios componentes pueden comunicarse con el dispositivo para extender la capacidad, funcionalidad y utilidad del dispositivo . La arquitectura de software basada en eventos puede ser cualquier programa con o sin hardware correspondiente
donde el flujo del programa se determina por las acciones o mensajes del usuario dentro del programa o de otros programas. Una arquitectura de software basada en eventos adecuada se describe en la Publicación No. WO 2006/135726, titulada " SISTEMA DE ARQUITECTURA DE SOFTWARE Y MÉTODO PARA COMUNICACIÓN CON, Y ADMINISTRACIÓN DE, POR LO MENOS UN COMPONENTE DENTRO DE UN APARATO DOMÉSTICO", publicado el 21 de diciembre de 2006. En este ejemplo particular de arquitectura de software ( "SA" ) , la SA se implementa en y se comunica sobre una red de comunicación interna en un aparato, el cual conecta los componentes físicos diversos del aparato. Algunos de los componentes físicos tienen un controlador correspondiente (controlador principal, controlador de motor, interfaz de usuario, etc.), el cual puede ser un microprocesador simple montado en una tarjeta de circuito impreso. Otros componentes no tienen ningún controlador. Típicamente, los componentes que tienen controladores (si existen más de uno típicamente también son habilitados por red) cooperan a través de la mensajería de red u otras formas de transmisión de datos para controlar directa o indirectamente, a través de otros componentes, la operación de todos los componentes y sus dispositivos contenidos o agregados para implementar una operación o ciclo para el aparato.
La SA puede, aunque no tiene que, residir en cada uno de los componentes con un controlador. Estos componentes con la SA o una variante de la SA en cumplimiento con la SA (el cumplimiento determinado por la capacidad de enviar, recibir y procesar paquetes) forman un nodo en la red que puede comunicarse con otros nodos . La SA realiza múltiples funciones: identifica cada uno de los componentes que corresponde con un nodo de la red; identifica las capacidades y funciones de los componentes identificados en la red; identifica el estado de los componentes en la red; proporcionar interfaces de comandos bien definidas para cada componente; proporciona comunicación entre componentes de software interno y externo que no son parte de la SA; y proporciona comunicación entre componentes sin componentes de software de SA sobre diferentes componentes físicos. De esta manera, la SA funciona para informar a todos los nodos sobre la red de la presencia, capacidades y estados de los otros nodos. La SA comprende múltiples módulos, de los cuales cada uno tiene diferente funcionalidad. Varias combinaciones de los módulos o todos los módulos pueden residir en cada uno de los componentes. Un módulo que tiene la funcionalidad básica o central para la invención reside en todos los componentes. En una configuración anticipada, todos los módulos residen por lo menos en el controlador principal, el
cual establece el controlador principal para funcionar como una SA primaria o de controlador, con los otros nodos funcionando en relación de cliente con el SA del controlador. En tal configuración, todos los nodos pueden comunicarse a través de la SA del controlador. La SA es lo suficientemente fuerte para que pueda permitir configuraciones sin una SA de Controlador o con múltiple SA de Controlador. Independientemente de la configuración, cualquier componente con una SA residente puede funcionar como un cliente con respecto a los otros componentes. Las comunicaciones internas pueden conectarse a uno o más componentes externos directamente o a través de una red externa. Los componentes externos pueden tener también uno, algunos o todos los módulos de SA en el interior. Todas las comunicaciones entre los componentes interno y externo y/o cualquier combinación de componentes descritos en esta solicitud pueden implementarse por las estructuras de software y red descritas en esta solicitud. La arquitectura de software de preferencia se configura para generar una pluralidad de mensajes, con por lo menos uno de los elementos de software residiendo en cada uno de los componentes y configurado para permitir la transmisión de por lo menos uno de la pluralidad de mensajes entre los componentes. Los mensajes pueden transmitirse para la comunicación bidireccional entre componentes. Los mensajes
pueden incluir mensajes de comandos. Los mensajes de comandos pueden incluir mensajes de eventos, los cuales indican que un evento ha sucedido que podría requerir el llamado de una función o módulo particular del software en respuesta al evento . La Figura 1 ilustra un sistema 10 de procesamiento de datos de acuerdo con la invención y el cual puede implementarse dentro de una red como se describe previamente o como un dispositivo autónomo. El sistema 10 de procesamiento de datos puede tener cualquier número de elementos comunes para un sistema 10 de procesamiento de datos, y no se describirá en detalle excepto cuando sea necesario para un entendimiento completo de la invención. El sistema 10 de procesamiento de datos incluye una unidad de procesamiento central, referida en la presente como CPU 12, una memoria 16, y un bus 18 externo. El sistema 10 de procesamiento de datos también puede configurarse en el modo que una memoria 24 externa pueda conectarse al mismo. La memoria 24 externa puede ser cualquier tipo de memoria externa común, tal como un dispositivo de USB o una memoria flash. El sistema 10 de procesamiento de datos además incluye un motor 20 de eventos y un módulo 30 de depuración. Los diversos componentes del sistema 10 de procesamiento de datos se interconectan por una pluralidad de buses que permite la comunicación de datos entre los mismos.
Un ejemplo de un sistema 10 de procesamiento de datos es un controlador o tarjeta madre principal. Todos los mensajes enviados dentro del sistema de preferencia tienen el mismo formato. Cada bus proporciona comunicación de datos unidireccional o bidireccional . La CPU 12 se acopla con la memoria 16 mediante un bus 40 de comunicación principal, el cual puede comprender un bus de datos y un bus de direccionamiento para transmitir el valor para una ubicación de memoria correspondiente. La CPU 12 también se acopla con el motor 20 de eventos por un bus 42 de notificación de eventos de CPU, y con el módulo 30 de depuración mediante un bus 44 de depuración de CPU. El motor 20 de eventos se acopla con el bus 40 de comunicación principal mediante un bus 50 de monitoreo de eventos y el módulo 30 de depuración mediante un bus 52 de notificación de evento de depuración. El motor 20 de eventos y el módulo 30 de depuración se acoplan con un bus 18 externo mediante un bus 60 de evento y un bus 62 de depuración, respectivamente. El bus 18 externo se configura para su conexión a cualquier número de dispositivos externos (no mostrados) , tal como a través de un puerto en serie, un puerto de Ethernet, una interfaz de JTAG, o similares. La memoria 20 externa se acopla con el bus 50 de comunicación principal mediante el bus 68 de memoria externa. La CPU 12 puede ejecutar varias instrucciones para implementar un programa basado en eventos. Las instrucciones
generan varios valores de datos variables para una pluralidad de variables asociadas con el programa. Estos valores de datos variables de las variables se almacenan en o se escriben en la memoria 16. También pueden almacenarse en la memoria 24 externa, la cual puede servir como una copia de respaldo de la memoria 16. El bus 40 de comunicación principal permite a la CPU 12 leer los datos desde y escribir los datos en la memoria 16. El bus 68 de memoria externa se acopla con el bus 40 de comunicación principal de modo que la CPU 12 puede escribir valores de datos variables en la memoria 24 externa al mismo tiempo que escribe los valores de datos variables en la memoria 16. El módulo 30 de depuración se utiliza para comunicar datos a través del bus 62 de depuración con el bus 18 externo. Un dispositivo externo conectado al mismo puede interconectarse con el módulo 30 de depuración para propósitos de depuración. Las interfaces de depuración adecuadas incluyen, pero no se limitan a estándares de JTAG y BDM actuales. Alternativamente, una interfaz de depuración adecuada puede construirse como parte del bus 18 externo. El bus 50 de monitoreo de evento se puede configurar para permitir que el motor 20 de eventos lea datos directamente del bus 40 de comunicación principal. En otras palabras, el motor 20 de eventos puede "inspeccionar" todos los datos que pasan a través del bus 40 de comunicación
principal. Durante esta inspección, el motor de eventos busca valores de datos variables de interés. Típicamente, el motor de eventos buscará un cambio en un valor de datos variables . Una forma para hacerlo de esta manera es buscar un comando de escritura de la CPU que cambia el valor de datos variables de una variable específica en la memoria 16. Un cambio en el valor de datos variables puede representar un evento al cual responderá el programa basado en eventos con una llamada a la función o la subrutina adecuada. Si es verdadero y el cambio representa un evento, el motor 20 de eventos puede enviar un mensaje a la CPU 12 ylo al módulo 30 de depuración mediante el bus 42 de notificación de evento de CPU y/o bus 52 de notificación de evento de depuración, respectivamente. Esos mensajes pueden difundirse simultáneamente tanto a la CPU 12 como al módulo 30 de depuración. Con referencia ahora a la Figura 2, para poder lograr este reconocimiento de eventos y envíos de mensajes, el motor 20 de eventos comprende un administrador 70 de eventos, un área 72 de memoria, y una interfaz de programas de aplicación de adquisición de datos, referida en la presente como DAQ 74. El administrador 70 de evento envía y recibe todos los mensajes que se emiten desde y se dirigen hasta el motor 20 de eventos. Los mensajes recibidos pueden incluir información para configurar el administrador 70 de eventos para enviar mensajes de notificación de eventos a
ciertos componentes. Por ejemplo, el módulo 30 de depuración puede enviar un mensaje mediante el bus 52 de notificación de evento de depuración al administrador 70 de eventos para suscribirse a un evento particular, el cual dice al motor de eventos que la variable para ese evento es de interés y debe observarse. Tal mensaje puede instruir al administrador 70 de eventos para enviar un cierto mensaje al módulo 30 de depuración con la ocurrencia de un evento especificado por el mensaje. Similarmente , la CPU 12 es capaz de suscribirse a eventos específicos mediante el bus 42 de notificación de eventos de CPU. El módulo 30 de depuración puede configurarse para suscribirse por lo menos a un evento específico ya sea por software o hardware dentro del sistema 10 de procesamiento de datos, o mediante un dispositivo externo. Un dispositivo externo puede conectarse al bus 18 externo y enviar mensajes a través del bus 62 de depuración hasta el módulo 30 de depuración que instruye al módulo 30 de depuración para suscribirse a ciertos eventos. Dispositivos externos pueden ser dispositivos operados por el usuario, tal como una PC. De preferencia, el módulo 30 de depuración también puede suscribirse a la CPU 12 a un evento específico al enviar un mensaje apropiado al administrador 70 de eventos. El área 72 de memoria comprende una memoria en la cual se almacena una pluralidad de elementos que corresponden
con una disposición de eventos configurados por el administrador 70 de eventos mediante el bus 80 de acceso al área de memoria. Cada evento se define en el área 72 de memoria por un puntero en la ubicación de un valor de datos variables asociado en la memoria 16, el valor actual del valor de datos variables en la memoria 16, un operador de eventos y un argumento de operador. En algunos casos, un evento puede tener múltiples operadores o argumentos. Un desarrollador puede utilizar varios operadores de eventos. Ejemplos incluyen: a cambio, mayor que, menor que, igual a, filtro de banda muerta, máscara de bits, enlace a dos o más eventos a través de una expresión lógica, etc. Operadores adicionales podrían diseñarse para controlar el área 72 de memoria en tiempo de ejecución, o podrían funcionar para clarificar eventos, agregar eventos, apagar/encender la notificación externa, obtener eventos, obtener datos de eventos, etc. El argumento de preferencia es un valor numérico, tal como el número "5". El administrador 70 de eventos puede examinar el área 72 de memoria utilizando un bus 80 de acceso al área de memoria en cualquier momento para comprobar la ocurrencia de un evento. Por ejemplo, el administrador de eventos puede iterarse sobre cada uno de los elementos del área 72 de memoria o puede inspeccionar un elemento particular sobre un cambio en el valor de datos variables para ese elemento.
Además, el administrador 70 de eventos puede enviar datos desde el área 72 de memoria a través del bus 60 de eventos hasta el bus 18 externo. De esta manera, los datos almacenados en el área 72 de memoria pueden enviarse a un dispositivo externo. De preferencia, el bus 60 de eventos se utiliza para enviar datos desde el área 72 de memoria hasta una PC conectada al bus 18 externo para el propósito de transferencia de datos en tiempo real no asociados con la depuración. Un ejemplo de tal propósito puede ser si el sistema 10 de procesamiento de datos se conectara a un dispositivo externo para poder operar el dispositivo externo. El DAQ 74 monitorea el bus 40 de comunicación principal mediante el bus 50 de eventos para valores de datos variables de interés y puede suministrar los valores de datos variables en el área 72 de memoria y el administrador 70 de Eventos. El administrador 70 de eventos puede instruir al DAQ 74 que utilice un bus 84 de DAQ para observar el bus 40 de comunicación principal para datos asociados con por lo menos uno o más eventos específicos. El DAQ 74 puede configurarse por el administrador 70 de eventos para observar la ocurrencia de datos asociados con un valor de datos variables específico, y el DAQ 74 puede almacenar selectivamente los datos en el área 72 de memoria utilizando un bus 82 de almacenamiento de área de memoria. El DAQ 74 lo realiza de esta manera al comparar el valor de datos variables
reconocido en el bus 40 de comunicación principal con el valor de datos variables almacenado en el área 72 de memoria. Si el DAQ 74 detecta que el valor de datos variables en el bus 40 de comunicación principal es diferente del valor de datos variables almacenado en el área 72 de memoria para un evento especifico, el DAQ 74 almacenará el nuevo valor de datos variables en el área 72 de memoria en la disposición para el evento asociado. Al mismo tiempo, el DAQ 74 enviará una señal de cambio, la cual es una señal que indica un cambio de valor de datos variables, al administrador 70 de eventos . Cuando el administrador 70 de eventos recibe una señal de cambio del DAQ 74, el administrador 70 de eventos examinará el área de memoria para determinar si ha ocurrido un evento o no . El administrador 70 de eventos puede examinar el área 72 de memoria antes de la escritura del valor de datos variables cambiado en el área 74 de memoria. De esta manera, el administrador 70 de eventos puede utilizar el valor en el área 72 de memoria y el valor cambiado para determinar si ha ocurrido un evento. El administrador 70 de eventos logra esto al comprobar lógicamente el valor de datos variables asociado con el operador de eventos y el argumento. Cuando las condiciones de evento se evalúan como VERDADERO, mensajes de notificación se generan y se difunden al módulo 30 de depuración y/o a la CPU 12, dependiendo de si cada
componente se ha suscrito o no al evento particular. Esos mensajes pueden contener datos indicativos del evento especifico, el valor de datos variables detectado, y/o cualesquier otras señales solicitadas por el suscriptor . Por ejemplo, un evento podría tener un operador "mayor que" y un argumento de 10, y el módulo 30 de depuración podría suscribirse al evento. El administrador 70 de eventos lógicamente entonces puede probar el valor de datos variables en el área 72 de memoria asociada con el evento para observar si fue mayor que 10. Si el valor de datos variables es mayor que 10, el administrador 70 de eventos puede enviar un mensaje al módulo 30 de depuración que contiene todos los datos asociados con el evento (el puntero, el operador, el argumento y el valor de datos variables) . Además de buscar eventos para el programa basado en eventos, el motor de eventos puede utilizarse por el módulo 30 de depuración para monitorear los valores de datos variables en tiempo real y para capacidades de depuración de estándares. El módulo 30 de depuración puede solicitar que el administrador 70 de eventos monitorea ciertas variables y proporciones sus valores de datos variables. El administrador 70 de eventos entonces enviará mensajes siempre que ocurra cualquier evento de modo que el módulo 30 de depuración sea capaz de producir valores de datos variables en tiempo real sobre el bus 62 de depuración utilizando sólo ancho de banda
mínimo. Esto se logra debido a que los valores de datos variables sólo se producen por el motor 70 de eventos cuando satisfacen los criterios por el evento deseado. Esto proporciona valores de datos en tiempo real al módulo de depuración sin requerir un vuelco de memoria completo. Al rastrear los valores de datos variables de interés, lo cual normalmente es un subconjunto de todos los valores de datos variables, y envía cambios en esos valores sobre un bus dedicado, el motor de eventos es capaz de proporcionar al módulo de depuración con valores de datos variables en tiempo real mientras permanecen integrados en el hardware del sistema 10 de procesamiento de datos. Esto permite la depuración en tiempo real, la cual no ha estado actualmente disponible para muchos procesadores. El módulo 30 de depuración también puede configurarse de modo que ciertos eventos puedan activar puntos de derivación, los cuales pueden detener la ejecución del programa y permitir vuelcos de memoria. Sin embargo, el bus de vuelco de memoria no es capaz de transmitir valores de datos variables en tiempo real al módulo 30 de depuración, ya que puede requerir un ancho de banda enorme no soportado por los buses de vuelco de memoria. Mientras la invención se ha descrito específicamente junto con ciertas modalidades especificas de la misma, se entenderá que ésta es por medio de ilustración y
no de limitación. Variación y modificación razonables son posibles dentro del alcance de la descripción y los dibujos anteriores sin apartarse del .espíritu de la invención, la cual se define en las reivindicaciones anexas.