Depuración de buses serie de baja velocidad en …materias.fi.uba.ar/6644/info/osciloscopios/avanzado/buses serie... · el bus todo lo que debe hacerse es observar el estado

▶ Nota de aplicación

Depuración de buses serie de baja velocidad en diseños de sistemas embebidos

Introducción Los sistemas embebidos se encuentran en la sociedad de nuestros días literalmente en cualquier lugar. Una simple definición de sistema embebido es la de un sistema basado en un ordenador dedicado a un propósito especial que forma parte de un sistema o de una máquina más grande y su propósito es el de proporcionar servicios de supervisión y control a ese sistema o máquina. Los sistemas embebidos típicos

comienzan haciendo funcionar alguna aplicación de propósito general tan pronto como son puestos en marcha y no se detienen hasta que se desconectan. Virtualmente, cada dispositivo electrónico diseñado y producido hoy en día es un sistema embebido. En la siguiente lista se incluye un breve listado de algunos ejemplos de sistemas embebidos:

Depuración de los buses de datos serie de baja velocidad en los diseños de sistemas embebidos ▶ Nota de aplicación

2 www.tektronix.com/oscilloscopes

– Despertadores – Cajeros automáticos – Teléfonos móviles – Impresoras para ordenadores – Controladores de antibloqueo de frenos – Hornos de microondas – Sistema de guía inercial de misiles – Reproductores de DVD – Agendas electrónicas (PDA’s) – Controladores de lógica programable (PLC)

para automática industrial y supervisión – Reproductores de música portátiles – Incluso puede que su tostadora … Los sistemas embebidos pueden contener muchos tipos diferentes de dispositivos entre los que se incluyen microprocesadores, microcontroladores, DSPs, RAM, EPROMs, FPGAs, A/Ds, D/As, y dispositivos de E/S. Todos estos variados dispositivos se han comunicado tradicionalmente entre ellos y con el exterior mediante grandes buses paralelos. Sin embargo, en los bloques que se emplean para el diseño de sistemas embebidos de hoy en día se están reemplazando cada vez más esos grandes buses paralelo por buses serie debidos a las siguientes razones: – Se requiere menos espacio en la tarjeta

debido a que hay que enrutar menos señales – Menor coste – Menores requisitos de alimentación

– Encapsulado con menos terminales de contacto

– Relojes embebidos – Utilización de señales diferenciales para

mejorar la inmunidad al ruido – Amplia disponibilidad de componentes en el

mercado que utilizan interfaces serie estándar.

Mientras que los buses serie proporcionan un buen número de ventajas, también plantean algunos desafíos significativos para el diseñador de sistemas embebidos, debido simplemente al hecho de que la información se transmite en serie en lugar de paralelo. Esta nota de aplicación trata sobre los desafíos comunes de los diseñadores de sistemas embebidos y de como superarlos utilizando las capacidades disponibles en los nuevos osciloscopios de la serie DPO4000 Paralelo con respecto a serie En una arquitectura en paralelo cada componente del bus tiene su propio camino para la señal. Podría darse el caso de que fueran 16 líneas de dirección, 16 de datos, una de reloj y otras varias de control. Los valores de las direcciones o de los datos se transfieren al mismo tiempo por las líneas de los buses paralelo. Esto hace que sea relativamente fácil disparar sobre los eventos de interés utilizando el disparo por “Estados” o por “Patrones” que puede encontrase en la mayor parte de los osciloscopios y analizadores lógicos. También hace que sea fácil interpretar de un vistazo los datos capturados y visualizados en la pantalla del osciloscopio o analizador lógico. Por ejemplo, en la figura 1 se ha utilizado un analizador lógico para adquirir el reloj, la dirección, el dato y las líneas de control de un microcontrolador. Utilizando el disparo por “Estados” se ha aislado la transferencia del bus que se estaba buscando. Para descodificar lo que está ocurriendo en el bus todo lo que debe hacerse es observar el estado lógico de cada línea de dirección, dato y control. En el caso de un bus serie toda esta información debe enviarse en serie sobre solo unos pocos conductores (algunas veces solo uno). Esto significa que una sola señal puede incluir la información sobre la dirección, las señales de control, el dato y el reloj. Como ejemplo se puede observar en la figura 2 la señal serie de un bus CAN (Controller Area Network)


www.tektronix.com/oscilloscopes 3

▶ Figura 3. Un mensaje adquirido de un bus I2C.

Este mensaje contiene una trama de inicio, un identificador (dirección), un código que indica la longitud del dato, el dato, unos bits de comprobación de errores CRC (Cyclic Redundancy Check) y el final de la trama, así como unos pocos bits de control. Para complicar todo un poco más, el reloj va embebido en los datos y se utilizan unos bits de relleno para asegurar la existencia de un número adecuado de flancos para que el dispositivo receptor pueda engancharse al reloj. Incluso para un ojo muy bien entrenado sería extremadamente difícil interpretar con rapidez el contenido de este mensaje. Ahora vamos a imaginar que este es realmente un mensaje erróneo que ocurre solo una vez al día y que se necesita disparar sobre él. Los osciloscopios y analizadores lógicos no están simplemente bien equipados para tratar con este tipo de señal.

Incluso con un bus serie estándar tan simple como el I2C es todavía significativamente más dura la observación de lo que se está transmitiendo por él que en el caso de un protocolo paralelo.

El bus I2C utiliza líneas separadas para el reloj y para los datos; así que, por lo menos en este caso se puede utilizar el reloj como punto referencia. Sin embargo, todavía se necesita encontrar el inicio del mensaje

(momento en que la línea de datos va a “0” mientras el reloj está a “1”), inspeccionar manualmente el tren de pulsos y escribir debajo de cada uno su valor utilizando como referencia los flancos de subida del reloj y por último organizar todos los bits en la estructura general del mensaje. En todo ese proceso se puede tardar fácilmente un par de minutos en decodificar un solo mensaje dentro de una larga adquisición y además se desconoce si ese es el mensaje que se está buscando en ese momento. Si no lo es, entonces es necesario

▶ Figura 1. Adquisición realizada con un analizador lógico de las líneas de reloj, bus de direcciones, bus de datos y control.

▶ Figura 2. Un mensaje adquirido de un bus CAN..



▶ Figura 4. Estructura de un mensaje I2C.

volver a empezar con este proceso tedioso y proclive a errores sobre el siguiente mensaje. Sería agradable poder realizar un disparo en el contenido del mensaje que se está buscando, sin embargo los disparos por “Estados” y “Patrones” que se han utilizado durante años en los osciloscopios y los analizadores lógicos no serán de mucha ayuda en este caso. Ambos están diseñados para buscar un patrón que ocurra al mismo tiempo en canales múltiples. Para poder trabajar sobre un bus serie, la máquina de disparo necesitaría una profundidad desde decenas a cientos de estados (un estado por bit). Incluso si esta capacidad de disparo existiese, no sería una tarea divertida la de programar estado por estado todos esos bits. ¡Debería haber una manera mejor!

Con la serie DPO4000 hay una manera mejor. Las secciones siguientes realzan la forma en que la serie DPO4000 puede ser utilizada con algunos de los buses serie estándar de baja velocidad más comunes utilizados en los diseños de sistemas embebidos.

Información básica sobre el bus I2C I2C o “I al cuadrado C” soporta la intercomunicación entre circuitos integrados. Este bus fue originalmente desarrollado por Philips en los comienzos de los años 80 con el objetivo de proporcionar a bajo coste la interconexión de los controladores con sus chips periféricos en el interior de los aparatos de TV, pero desde entonces ha evolucionado hasta convertirse en un estándar mundial para las comunicaciones entre los dispositivos de sistemas embebidos. Los diseños simples basados en dos cables de comunicación han encontrado su camino gracias a una amplia variedad de chips como E/S, A/D’s, D/A’s, sensores de temperatura, microcontroladores y microprocesadores fabricados por numerosas compañías líderes en el mercado como: Analog Devices, Atmel, Infineon, Cyprus, Intel, Maxim, Philips, Silicon Laboratories, ST Microelectronics, Texas Instruments, Xicor y otras.

Como funciona El bus I2C es físicamente una interfaz basada en dos cables para las líneas bidireccionales del reloj serie (SCL) y de los datos (SDA). El bus I2C soporta múltiples “maestros” y “esclavos” en el bus, pero solo uno de los “maestros” puede estar activo a la vez. Cualquier dispositivo I2C se puede unir al bus permitiendo que cualquier dispositivo “maestro” intercambie información con un dispositivo “esclavo”. Cada dispositivo es reconocido por una dirección única y puede operar como un transmisor o como un receptor, dependiendo de la función del dispositivo. Al principio, el bus I2C solo utilizaba direcciones de 7bits, pero ha evolucionado en el tiempo para permitir también un direccionamiento basado en 10 bits. El bus soporta tres velocidades de transmisión: 100kbps (modo estándar), 400kbps (modo rápido) y 3.4Mbps (modo de alta velocidad). El número máximo de dispositivos está determinado por una capacidad máxima de 400pf o aproximadamente de 20 a 30 dispositivos. El estándar I2C especifica el siguiente formato en la figura 4: – Start – indica que el dispositivo está tomando el control del bus y que le seguirá un mensaje. – Address – un número de 7 o 10 bits que representa la dirección del dispositivo sobre el que se realizará una acción de lectura o escritura de datos. – R/W Bit – un bit para indicar si el dato va a ser leído o escrito en el dispositivo. – Ack – un bit emitido por el dispositivo esclavo para acusar recibo de las acciones del maestro. Normalmente cada byte de direcciones y datos tiene un bit de acuse de recibo, pero no siempre. – Data – un número entero de bytes que van a ser leídos o escritos en el dispositivo.

– Stop – indica que el mensaje se ha completado y que el “maestro” tiene que liberar el bus.



▶ Figura 5. Menú de configuración del bus I2C en el osciloscopio.

▶ Figura 6. Ejemplo de bus I2C.

Funcionamiento del bus I2C Gracias al módulo de disparo serie y análisis DPO4EMBD la serie DPO4000 se convierte en una poderosa herramienta para los diseñadores de sistemas embebidos que trabajan con buses I2C. El panel frontal de la serie DPO4000 tiene dos botones de BUS (B1 y B2) que permiten al usuario definir las entradas del osciloscopio como pertenecientes a un bus. En la figura 5 se muestra el menú de configuración del bus I2C. Con solo definir a que canales de entrada se conectan las líneas de reloj y datos y los umbrales utilizados para determinar los niveles lógicos correspondientes al “0” y al “1”, el osciloscopio puede comprender el protocolo que se trasmite a través del bus.

Gracias a este conocimiento, el osciloscopio puede disparar sobre cualquier nivel de información del mensaje especificado y a continuación descodificar la adquisición proporcionando resultados significativos y de fácil interpretación. Por fin se acabaron los días en los que se disparaba por flanco esperando que se capturase el evento de interés y luego había que proceder a descodificar manualmente el mensaje después de haber encontrado el problema. Como ejemplo, vamos a considerar el sistema embebido de la figura 6. En él un bus I2C está conectado a dispositivos múltiples que incluyen una CPU, una EEPROM, un controlador de velocidad de un ventilador, un convertidor analógico-digital y un par de sensores de temperatura.



▶ Figura 7. Ejemplo de bus I2C.

Este instrumento fue vuelto al departamento de ingeniería para el análisis de un fallo que consistía en que el producto se mantenía demasiado caliente de forma continua y dejaba de funcionar por sí mismo. La primera cosa que se comprobó fue el regulador del ventilador y los propios ventiladores, pero ambos parecían trabajar correctamente. La siguiente cosa que se comprobó fue si el sensor de temperatura fallaba. El regulador de la velocidad del ventilador interroga periódicamente a los dos sensores de temperatura (situados en diversas áreas del instrumento) y ajusta la velocidad del ventilador para regular temperatura interna. Se sospechó que los datos de uno o ambos sensores de temperatura no se estaban leyendo correctamente. Para ver la interacción entre los sensores y el regulador de velocidad del ventilador, se necesitó simplemente conectarse a las líneas del reloj y datos del bus I2C y configurar el bus en el DPO4000. Sabiendo que los dos sensores tienen las direcciones 18 y 19 en el bus I2C; así que, se decidió preparar un evento de disparo para buscar una acción de escritura en la dirección 18 (el regulador de la velocidad del ventilador interrogando al sensor sobre la temperatura actual). La adquisición obtenida mediate ese disparo aparece en la imagen de la pantalla del osciloscopio mostrada en la figura 7. En este caso, el canal 1 (amarillo) está conectado a la línea SCLK y el canal 2 (cian) a la SDA. La forma de onda de color cian es el bus I2C que hemos definido introduciendo solo algunos parámetros simples en el osciloscopio. La porción superior de la pantalla muestra la adquisición entera. En este caso hemos capturado mucho tiempo de inactividad del bus y breve ráfaga de actividad en el centro sobre la cual hemos realizado el zoom. La porción más baja y grande de la pantalla es la ventana dedicada al zoom. Como se puede observar, el osciloscopio ha descifrado el contenido de cada mensaje presente en el bus. La representación de los buses en la serie DPO4000 utiliza los colores y marcas detallados en la tabla 1 para indicar las partes importantes del mensaje.

Echando una ojeada a las formas de onda adquiridas, se puede ver que el osciloscopio disparó de hecho en un evento de escritura en la dirección 18 (mostrado en la parte inferior-izquierda de la pantalla). Además se puede apreciar que el regulador de velocidad del ventilador intentó escribir dos veces en la dirección 18, pero en ambos casos no recibió el acuse de recibo después de intentar escribir en el sensor de temperatura. A continuación se comprobó el sensor de temperatura en la dirección 19 y se recibió la información deseada. Así pues ¿por qué el primer sensor de temperatura no estaba respondiendo al regulador del ventilador? Echando una mirada a la parte involucrada de la tarjeta donde estaba el sensor se encontró que una de las líneas de dirección no estaba soldada correctamente. El sensor de temperatura no podía comunicarse con el bus y la unidad se recalentaba consecuentemente. Como puede verse, se ha gestionado el aislamiento de este problema, potencialmente evasivo, en cuestión de solo un par de minutos gracias a la capacidad de disparo sobre buses I2C y a la capacidad de descodificación de la serie DPO4000.



▶ Tabla 1. Condiciones del bus.

Condición del bus Indicado por: El inicio (Start) se indica con barras verdes verticales. El comienzo repetido ocurre cuando aparece otro inicio sin una parada anterior (Stop). Las direcciones se muestran en cajas amarillas junto con una [W] en el caso de escritura o [R] para el caso de lectura. Los valores de las direcciones se pueden visualizar en hexadecimal o binario.

Los datos se muestran en cajas de color cian. Los valores de los datos se pueden visualizar en hexadecimal o binario. Los fallos de acuse de recibo se indican con una exclamación dentro de una caja roja.

Las paradas (Stop) se indican con barras rojas verticales.

En el ejemplo de la figura 7 se ha disparado sobre un evento de escritura, pero dentro del potente disparo para buses I2C del DPO4000 se incluyen muchas otras capacidades de disparo. – Inicio (Start) – el disparo se produce cuando la línea SDA pasa a nivel “0” mientras la línea SCL está a “1”. – Inicio repetido (Repeated start) – el disparo se produce cuando ocurre una condición de inicio sin una condición de parada anterior. Éste es generalmente cuando un “maestro” envía mensajes múltiples sin liberar el bus. – Parada (Stop) - el disparo se produce cuando la línea SDA pasa a nivel “1” mientras la SCL está a “1”. – Falta de acuse de recibo (Missing Ack) - los “esclavos” se configuran a menudo para transmitir un acuse de recibo después de cada byte de dirección y datos. El osciloscopio puede disparar en los casos donde el “esclavo” no genera el bit de reconocimiento.

– Dirección (Address) – el disparo se produce sobre una dirección especificada por el usuario o sobre cualquier dirección especial pre-programada entre las que se incluyen: General Call, Start Byte, HS-mode, EEPROM, ó CBUS. El direccionamiento puede ser realizado mediate 7 ó 10 bits y se puede introducir en binario o hexadecimal. – Dato (Data) – el disparo se puede realizar hasta sobre 12 bytes de valores de datos especificados por el usuario e introducidos en binario o hexadecimal. – Dirección y dato (Address and Data) – esto permite especificar tanto la dirección como los valores de los datos que se leen o escriben para así capturar el evento exacto de interés. Estos disparos permiten el aislamiento del tráfico particular del bus sobre el que se está interesado, mientras que la capacidad de descodificación permite ver inmediatamente el contenido de cada mensaje transmitido sobre el bus una vez realizada la adquisición.



▶ Figura 8. Configuración SPI común.



▶ Tabla 9. Configuración del bus SPI en modo encadenado.

Información básica sobre el bus SPI El bus de interfaz con periféricos serie (SPI) fue desarrollado originalmente por Motorola en los últimos años de los 80 para sus microcontroladores de la serie 68000. Debido a la simplicidad y al renombre del bus, muchos otros fabricantes han adoptado el estándar a lo largo de los años. Ahora se puede encontrar en una amplia variedad de componentes usados comúnmente en el diseño sistemas embebidos. El bus SPI se utiliza sobre todo entre los microcontroladores y sus dispositivos periféricos inmediatos. Se encuentra comúnmente en los teléfonos móviles, PDAs y otros dispositivos móviles que comunican datos entre la CPU, el teclado, la pantalla y los chips de memoria. Como funciona El bus SPI (Serial Peripheral Interface) es un bus maestro/esclavo de comunicaciones sobre 4 hilos. Las cuatro señales son el reloj (SCLK), la salida del maestro/entrada del esclavo (MOSI), la entrada del maestro/salida del esclavo (MISO) y la selección del dispositivo esclavo (SS). Siempre que dos dispositivos se comunican, a uno se le llama “maestro” y al otro “esclavo”. El “maestro” controla el reloj serie. Los datos se transmiten y se reciben simultáneamente, haciéndolo mediante un protocolo full-duplex. En lugar de tener direcciones únicas para cada dispositivo en el bus, el SPI utiliza la línea SS para especificar a cual o desde cual dispositivo se están transfiriendo los datos. Como tal, cada dispositivo único en el autobús necesita su propia señal SS proveniente del “maestro”. Si hay 3 dispositivos esclavos existen también 3 líneas SS desde el “maestro”, una para cada”esclavo” como se muestra en la figura 8. En la figura 8, cada esclavo habla solamente con el maestro. Sin embargo, el bus SPI se puede cablear a través de todos los dispositivos auxiliares mediante un enlace en cadena y de esa forma cada uno realiza una operación respetando su turno y después ese dispositivo envía los resultados al “maestro” según como se muestra en la figura 9.

Como se puede ver, no hay un "estándar" para la implementación del bus SPI. En algunos casos, cuando no se requiere la comunicación del “esclavo” hacia el “maestro”, la señal MISO se puede dejar desconectada en todos los chips.



▶ Figura 10. Menú de configuración del bus SPI en el osciloscopio.

▶ Figura 11. Sintetizador controlado mediante el bus SPI.

Cuando ocurre una transferencia de datos en el bus SPI , la palabra de datos que es de 8-bit se desplaza bit a bit por la salida MOSI, mientras que otra palabra diferente de datos de 8-bits se introduce en la entrada MISO desplazándose bit a bit. Esto puede considerarse como el funcionamiento de un registro de desplazamiento circular de 16-bits. Cuando ocurre una transferencia, este registro de desplazamiento 16-bits es desplazado 8 posiciones, intercambiando de esa forma los 8-bits de datos entre el “maestro” y los dispositivos “esclavos”. Un par de registros, la polaridad del reloj (CPOL) y su fase (CPHA) determinan los flancos del reloj en los que se transmiten los datos. Cada registro tiene dos estados posibles que permiten cuatro combinaciones que son incompatibles las unas con las otras. Asi que, el par maestro/esclavo debe utilizar los mismos valores parámetricos para comunicarse. Si se utilizan “esclavos” múltiples que permanecen fijos en diversas configuraciones, el “maestro” tendrá que reconfigurarse a sí mismo cada vez que necesite comunicarse con un “esclavo” diferente. Funcionamiento del bus SPI El módulo de aplicación DPOÊMBD para disparo serie y análisis permite también la utilización de características similares a las del bus SPI. Una vez más, se pueden utilizar los botones del panel delantero B1 ó B2 para definir un bus SPI mediante la simple incorporación de los parámetros básicos del bus entre los que se incluyen los canales SCLK, SS, MOSI, y MISO que estarán activos, los umbrales y las polaridades (véase la figura 10). Como ejemplo, vamos a considerar el sistema embebido de la figura 11. Un bus SPI está conectado a un sintetizador, a un convertidor D/A y a algún dispositivo de entrada salida (I/O). El sintetizador está conectado a un oscilador controlado por tensión (VCO)

que proporciona un reloj de 2,5GHz al resto del sistema. Se supone que el sintetizador es programado por la CPU en el arranque. Sin embargo, algo no está funcionando correctamente porque el VCO se queda atascado generando 3GHz. El primer paso para depurar este problema consiste en examinar las señales entre la CPU y el sintetizador para estar seguros de que las señales están presentes y no hay problemas de conexión física, pero tras el proceso de búsqueda no se encuentra ningún error. A continuación se decide echar un vistazo a la información real que es transmitida a través del bus SPI para programar el sintetizador. Para capturar la información de interés se ajusta el osciloscopio para que dispare sobre la señal de selección del sintetizador (SS) en el momento en pase a su estado activo y encienda el DUT (Device Under Test) con el objetivo de capturar los comandos de programación que le envía la CPU en el momento del arranque. La adquisición final se muestra en la figura 12.



▶ Figura 12. Adquisición de mensajes de configuración del sintetizador mediante el bus SPI.

▶ Tabla 13. Mensajes correctos de la configuración del sintetizador.

▶ Figura 13. Mensaje correcto de configuración del sintetizador.

El canal 1 (amarillo) representa la línea SCLK, el canal 2 (cian) la línea MOSI y el canal 3 (magenta) la línea SS. Para a ayudar a determinar si estamos programando el dispositivo correctamente echaremos un vistazo a la hoja de datos del sintetizador. Los primeros tres mensajes en el bus se supone que sirven para inicializar el sintetizador, para cargar el factor de la división de frecuencia y para almacenar los datos. De acuerdo a las especificaciones, el último byte (carácter hexadecimal único) de las primeras tres transferencias debería ser 3, 0 y 1 respectivamente, pero estamos viendo 0, 0 y 0. Una vez que se ha visto que todos los mensajes acaban en “0” nos damos cuenta de hemos cometido uno de los errores más comunes que ocurren en SPI, la programación de las palabras de 24 bits en orden opuesto a la hora de escribir el programa. Un cambio rápido en el programa da lugar la adquisición que se muestra en la figura 13 donde el VCO ya está funcionando correctamente a 2,5GHz. En el ejemplo de arriba utilizamos un simple disparo sobre el SS activo. La completa capacidad de disparo sobre el bus SPI de la serie DPO4000 incluye los tipos siguientes: – SS Active – el disparo ocurre cuando la línea SS de un dispositivo “esclavo” pasa al estado lógico “vedadero”. – MOSI – el disparo ocurre sobre los hasta 16 bytes de datos especificados por el usuario y que son enviados desde el “maestro” al “esclavo”. – MISO – el disparo ocurre sobre los hasta 16 bytes de datos especificados por el usuario y que son enviados desde el “esclavo” al “maestro”. – MOSI/MISO – el disparo ocurre sobre los hasta 16 bytes de datos especificados por el usuario y que son enviados desde el “maestro” al “esclavo” o recíprocamente. Una vez más, estos disparos permiten el aislamiento de un tráfico particular en el bus sobre el que se está interesado, mientras que con la capacidad adicional de descodificación se puede observar el contenido de cada

mensaje transmitido sobre el bus y capturado en la adquisición.



▶ Figura 14. Trama de datos y trama remota de un bus CAN.

Más información sobre el bus CAN El bus CAN (Controller Area Network) fue desarrollado originalmente en los años 80 por Roberto Bosch gmbH como un bus de comunicaciones de bajo coste entre dispositivos que tenían que funcionar en ambientes eléctricamente ruidosos. Mercedes-Benz se convirtió en el primer fabricante de automóviles que en 1992 comenzó a emplear el bus CAN en sus sistemas para automóviles. Hoy en día casi todos los fabricantes de automóviles utilizan controladores y redes basadas en el bus CAN para controlar los dispositivos tales como por ejemplo: reguladores de los motores de los limpia-parabrisas, sensores de lluvia, bolsas de aire protectoras, cerraduras de puertas, controles que miden los tiempos del motor, sistemas antibloqueo de frenos, control de la distribución eléctrica y ventanas eléctricas, solo por nombrar algunos. Debido a su tolerancia eléctrica al ruido, cableado mínimo, capacidades excelentes de detección de errores y la transferencia de datos de alta velocidad, el bus CAN se está expandiendo rápidamente en otras aplicaciones tales como el control industrial, navales, electromedicina, aeroespaciales y otras. Como funciona El bus CAN utiliza una interfaz de dos hilos balanceados (en modo diferencial) cuyo soporte físico puede ser un par de cables trenzados y apantallados (STP), un par de cables trenzados y sin apantallar (UTP) o un cable de tipo cinta. Cada nodo utiliza un conector macho tipo D de 9 contactos. Se utiliza la codificación de bits sin retorno a cero (NRZ) con bits de relleno para asegurar mensajes compactos con un número mínimo de transiciones y alta inmunidad con el ruido. La interfaz

del bus CAN utiliza un esquema de transmisión asíncrona en el que cualquier nodo puede comenzar a transmitir en cualquier momento si el bus está libre. Los mensajes se difunden por igual a todos los nodos en la red. En los casos cuando varios nodos inician el envío de mensajes a la vez, se utiliza un arbitraje inteligente para determinar qué mensaje tiene la prioridad más alta. Los mensajes pueden ser uno de cuatro tipos: Trama de datos (Data Frame), trama de petición de transmisión remota (RTR), trama de error (Error Frame) o trama de sobrecarga (Overload Frame). Cualquier nodo en el bus que detecta un error transmite una trama de error que provoca que todos los nodos en el bus detecten que el mensaje actual está incompleto y el nodo que lo transmitió debe volver a enviar el mensaje. Las tramas de sobrecarga son iniciadas por los dispositivos receptores para indicar que no están todavía listos para recibir más datos. Las tramas de datos se utilizan para transmitir datos mientras que las tramas remotas solicitan datos. Los datos y tramas remotas se controlan mediante los bits de inicio (start) y parada (stop) situados al principio y al final de cada trama e incluyen los campos siguientes: campo del arbitraje de prioridades (Arbitration field), campo de control (Control field), campo de datos (Data field), campo de control de errores (CRC field) y un campo de acuse de recibo (ACK field) como se muestra en la figura 14.



– SOF – La trama se inicia con el bit de inicio de trama (SOF) – Arbitration – El campo de arbitraje incluye una dirección (address) de identificación (identifier) y un bit de petición de transmisión remota (RTR) utilizado para distinguir las tramas de envío de datos y las tramas de petición remota de datos, llamadas tramas remotas. El identificador (identifier) puede tener el formato estándar (11bits -versión 2.0A) o el formato ampliado (29bits - versión 2.0B). – Control – El campo de control consiste en seis bits que incluyen el bit de ampliación del identificador (IDE) con el que se puede distinguir el tipo de formato: el estándar CAN 2.0A (identificador de 11bits) o el ampliado CAN 2.0B (identificador de 29bits). El campo de control incluye también el código de longitud de los datos (DLC: Data Length Code). El DLC está formado por cuatro bits y sirve para indicar el número de bytes del que se compone el campo de datos de una trama de datos o el número de bytes que está siendo solicitando por una trama remota. – Data – El campo de datos se compone de cero a ocho bytes de datos. – CRC – Está formado por quince bits de un código de comprobación de redundancia cíclica y un bit de delimitación recesivo.

– ACK – El campo de acuse de recibo es de dos bits de longitud. El primero es el bit de slot, transmitido como recesivo, pero que puede ser sobrescrito por los bits dominantes transmitidos desde cualquier nodo que reciba con éxito el mensaje transmitido. El segundo bit es un bit de delimitación recesivo. – EOF – Siete bits recesivos indican el final de la trama (EOF). El campo de interrupción (INT) posee tres bits recesivos que indican que el bus está libre. El tiempo de reposo del bus puede ser de cualquier longitud, incluido cero. En el bus CAN hay definidas varias velocidades de transmisión de datos y están comprendidas entre la más rápida de 1Mb/s y la más lenta de 5kb/s. Todos los módulos deben soportar al menos 20kb/s. La longitud máxima del cable depende de la velocidad de transmisión utilizada. Todos los dispositivos dentro de un sistema transfieren normalmente la información a velocidades uniformes y fijas. La longitud máxima de una línea puede ser desde millares de metros para transmisiones a baja velocidad hasta unos 40 metros a 1Mbps. Se utilizan resistencias de terminación en los extremos del cable.



▶ Figura 15. Menú de configuración para el bus CAN. en el osciloscopio.

▶ Figura 16. Disparo en un identificador y dato específicos de un bus CAN y descodificación de todos los mnsajes capturados en la adquisición.

.

Trabajando con el bus CAN El módulo de aplicación DPOAUTO para disparo serie y análisis permite características similares de disparo y análisis para el bus CAN. Una vez más, se pueden utilizar los botones B1 ó B2 del panel delantero del DPO4000 para definir un bus CAN sin más que introducir los parámetros básicos del bus entre los que se incluyen: el tipo de señal CAN a la que se va a aplicar las sondas de medida y en qué canal del osciloscopio se van a conectar, la velocidad de transmisión, los umbrales y el punto de muestreo (como un % de tiempo de un bit), véase la figura 15. Vamos a imaginar que se necesita realizar las medidas de tiempo asociadas al estado latente del bus desde cuando un conductor presiona el mando para bajar la ventanilla del pasajero hasta cuando el módulo CAN en la puerta del conductor emite el comando y a continuación el tiempo en que la ventana del pasajero comienza realmente a moverse. Especificando el identificador del módulo CAN de la puerta del conductor; así como, los datos asociados con el comando de "bajada de ventanilla", se puede realizar un disparo en la trama de datos exacta que se está buscando. Colocando las sondas del osciloscopio simultáneamente en el conmutador de la puerta del conductor para la bajada de la ventanilla y otra en el controlador del motor que acciona la ventanilla de la puerta del pasajero, la medida de los tiempos llega a ser excepcionalmente fácil, como se muestra en el figura 16.

Los triángulos blancos en la figura son las marcas que se han puesto en la forma de onda como puntos de referencia. Estas marcas se agregan o se quitan de la pantalla presionando simplemente el botón “Set/Clear” en el panel delantero del osciloscopio. Además, si se presionan los botones “←” y “→” del panel delantero se consigue que la ventana de zoom salte de una marca a la siguiente, permitiendo una fácil navegación entre los eventos de interés en la adquisición.



▶ Figura 17. Tabla de eventos de un bus CAN. .

Ahora vamos a imaginar que se fuese a realizar esta tarea sin estas capacidades. Sin el disparo CAN en el osciloscopio se tendría que disparar utilizando la señal del mismo interruptor, capturar lo que se espera que sea una ventana suficientemente larga de tiempo de actividad del bus y después comenzar manualmente a descodificar trama tras trama del bus CAN hasta que finalmente se encuentre la trama correcta. Lo cual podría haber consumido decenas de minutos o incluso horas antes de lograr lo que ahora puede llevarse a cabo en unos momentos. Las potentes capacidades de disparo del DPO4000 para el bus CAN incluye los tipos siguientes: – Inicio de la trama (Start of Frame) – el disparo tiene lugar sobre el campo SOF de la trama. – Tipo de trama (Frame Type) – las opciones disponibles son: Trama de datos (Data Frame), trama remota (Remote Frame), trama de error (Error Frame) y trama de sobrecarga (Overload Frame). – Identificador (Identifer) – el disparo tiene lugar sobre un valor especifico del identificador de 11 ó 29 bits con cualificación de lectura/escritura (Read/Write). – Datos (Data) – el disparo tiene lugar sobre los datos especificados por el usuario en 1-8 bytes. – Falta de acuse de recibo (Missing Ack) – el disparo tiene lugar cuando el dispositivo receptor no emite un acuse de recibo. – Final de trama (EOF: End of Frame) – el disparo tiene lugar en el campo EOF.

Estos tipos de disparo permiten aislar virtualmente y sin esfuerzo cualquier cosa que se esté buscando en un bus CAN. Sin embargo, el disparo es solo el principio. La localización de averías requiere a menudo la inspección del contenido del mensaje antes y después del evento del disparo. Una manera simple de visualizar el contenido de mensajes múltiples después de realizar una adquisición es mediante la tabla de eventos de la serie DPO4000, según se muestra en la figura 17. La tabla de eventos muestra el contenido descodificado de cada mensaje capturado dentro una adquisición en un formato tabular y con estampados de tiempos. Esto hace fácil la visión, no solamente de todo el tráfico en el bus, sino que también permite realizar fácilmente medidas de tiempo entre los mensajes. Las tablas de eventos están también disponibles para los buses I2C y SPI.



▶ Figura 18. Búsqueda de un identificador y datos específicos en una adquisición de un bus CAN.

El sistema de disparo con respecto al de búsqueda Como se ha venido diciendo a través de esta nota de aplicación, se requiere un sistema de disparo capaz de aislar los eventos de interés dentro de un bus serie. Sin embargo, una vez que se han adquirido los datos (el osciloscopio se detiene) y se desea analizarlos, el disparo ya no se puede aplicar más. ¿No estaría bien que el osciloscopio tuviera recursos parecidos a los del disparo para analizar los datos capturados de la forma de onda? El Wave InspectorTM de la serie DPO4000 proporciona esta capacidad gracias a sus potentes prestaciones para realizar búsquedas. Todas las características del disparo discutidas a través de todo este documento están también disponibles como criterios de búsqueda sobre los datos ya adquiridos. Por ejemplo, se puede observar en la figura 18 como el osciloscopio ha buscado dentro de una larga adquisición un mensaje CAN que tiene una dirección y un contenido de datos específico y los ha marcado automáticamente con un triángulo blanco hueco en la parte superior de la pantalla. La navegación posterior entre las ocurrencias es tan simple como presionar los botones “←” y “→” del panel delantero de la serie DPO4000. Por supuesto, las búsquedas están también disponibles para los tipos más tradicionales de disparo. Así pues, los tipos de la búsqueda incluidos son: flanco (edge), anchos de pulso (pulse widths), cualificación de amplitud de pulsos (runt), tiempos de establecimiento y retención (setup & hold), lógico (logic) y tiempos de subida y bajada (rise/fall). Conclusión Aunque la transición de buses paralelo a buses serie en el diseño de sistemas embebidos conlleva muchas ventajas también incluye una serie de retos a los que el

ingeniero de diseño debe enfrentarse. Con las herramientas tradicionales de prueba y medida es mucho más difícil conseguir un disparo sobre el evento que se está buscando y puede ser casi imposible decir qué información está presente en la captura sin más que mirar la señal analógica y además es un proceso en el que se desperdicia el tiempo de manera notable y también propenso a errores al tener que descodificar manualmente un período largo de la actividad del bus para diagnosticar los problemas. La serie DPO4000 lo cambia todo. Con su potente disparo y las capacidades de descodificación y búsqueda los ingenieros de diseño de hoy en día pueden solucionar los problemas de diseño de sistemas embebidos con una eficacia excepcional.

Contacte con Tektronix: ASEAN / Australasia / Pakistan (65) 6356 3900

Austria +41 52 675 3777 Balkan, Israel, South Africa and other ISE Countries +41 52 675 3777

Belgium 07 81 60166 Brazil & South America 55 (11) 3741-8360

Canada 1 (800) 661-5625 Central East Europe, Ukraine and Baltics +41 52 675 3777

Central Europe & Greece +41 52 675 3777 Denmark +45 80 88 1401 Finland +41 52 675 3777

France & North Africa +33 (0) 1 69 86 81 81 Germany +49 (221) 94 77 400

Hong Kong (852) 2585-6688 India (91) 80-22275577

Italy +39 (02) 25086 1 Japan 81 (3) 6714-3010

Luxembourg +44 (0) 1344 392400 Mexico, Central America & Caribbean 52 (55) 56666-333

Middle East, Asia and North Africa +41 52 675 3777 The Netherlands 090 02 021797

Norway 800 16098 People’s Republic of China 86 (10) 6235 1230

Poland +41 52 675 3777 Portugal 80 08 12370

Republic of Korea 82 (2) 528-5299 Russia & CIS 7 095 775 1064

South Africa +27 11 254 8360 Spain (+34) 901 988 054

Sweden 020 08 80371 Switzerland +41 52 675 3777

Taiwan 886 (2) 2722-9622 United Kingdom & Eire +44 (0) 1344 392400

USA 1 (800) 426-2200 Para otras áreas contacte con Tektronix, Inc. at: 1 (503) 627-7111

Ültima actualización 15 Junio 2005

Nuestra información más actualizada está disponible en: www.tektronix.com

Copyright © 2005 Tektronix. Todos los derechos reservados. Los productos Tektronix están protegidos

por patentes de EE.UU. y de otros países, emitidas y pendientes. La información contenida en esta publicación anula la información contenida en cualquier material publicado con antelación. Se reservan

los derechos de cambios en el precio y en las especificaciones. TEKTRONIX y TEK son marcas comerciales registradas de Tektronix, Inc. El resto de marcas a las que se hace referencia son marcas

de servicio, marcas comerciales o marcas comerciales registradas de sus respectivas empresas.

10/05 FLG/WOW 48S-19040-0

Documents

Depuración de buses serie de baja velocidad en …materias.fi.uba.ar/6644/info/osciloscopios/avanzado/buses serie... · el bus todo lo que debe hacerse es observar el estado