Codificando tu propio equipo de prueba en red

Mark Harris
|  Creado: January 18, 2024  |  Actualizado: February 9, 2024
Codificando tu propio equipo de prueba en red

Introducción

Si alguna vez has pasado tiempo probando manualmente lotes de componentes, sabrás cuán laborioso y consumidor de tiempo es todo el proceso. Cada prueba sigue los mismos pasos básicos repetidos para cada artículo que estás probando. También entenderás el poder de usar equipos de prueba que puedes programar para realizar estos pasos por ti, así que simplemente se trata de configurar todo y conectar todo para que puedas presionar un botón para realizar una prueba. Puedes ahorrar aún más tiempo automatizando la configuración de todo tu equipo de prueba con un solo clic de un ratón de computadora.

Sin embargo, ¿qué pasa si quieres crear equipos de prueba a medida para agregar a tu suite de pruebas automatizadas? Esta guía paso a paso te mostrará cómo escribir código que te permite configurar tu equipo de prueba en red desde la comodidad de tu computadora.

La automatización en red elimina la necesidad de configurar cada pieza de equipo de prueba por separado y ahorra tiempo si necesitas repetir las mismas pruebas en el futuro. La ventaja es que restaurar configuraciones después de cualquier corte de energía o apagado accidental del equipo es rápido y sencillo.

Introducción a SCPI

Si no estás familiarizado con el equipo de prueba en red, necesitarás saber sobre los Comandos Estándar para Instrumentos Programables (SCPI). En sus inicios, Hewlett-Packard ideó el concepto de un bus de interfaz estándar que permitiría a cualquier computadora con la interfaz correcta conectarse a cualquier pieza de equipo de prueba. Este estándar HPIB se conoció como el Bus de Interfaz de Propósito General (GPIB) con su propia designación de estándar IEEE 488. Esta estandarización permitió que cada pieza de equipo de prueba en red respondiera a comandos de la computadora para realizar funciones como emitir una señal o realizar una medición.

SCPI expandió el principio de la estandarización en red de equipos de prueba agregando una capa adicional para el estándar IEEE-488 para regular los comandos de computadora que el equipo de prueba podría entender. Este enfoque ahora significa que un osciloscopio hecho por HP responderá a los mismos comandos que un osciloscopio hecho por Keysight. Antes de la estandarización de comandos, a menudo diferentes modelos producidos por el mismo fabricante reaccionarían a diferentes comandos. Esta estandarización significa que el programa de control de equipo de prueba en una computadora funcionará con cualquier marca y modelo de equipo de laboratorio, por lo que cambiar una fuente de alimentación de banco en red, por ejemplo, a un modelo mejor no requerirá cambios en el programa de control.

Esta estandarización también significa que cualquier código escrito para esta guía paso a paso funcionará en cualquier otro laboratorio si tienes los mismos tipos de equipo de prueba en red vinculados a una computadora adecuada.

Introducción a SCPI

Los comandos SPCI están en forma de cadenas ASCII simples que son razonablemente intuitivas de leer y entender. Por ejemplo, enviar el comando “*RST” a un equipo de prueba lo reiniciará; enviar el comando “*WAI” le instruirá a esperar.

Los comandos SPCI pueden instruir al equipo de prueba para realizar una acción o solicitar información dependiendo de su formato. Por ejemplo, el comando “TIM:ACQT 20ms” cambiará el tiempo de adquisición de un osciloscopio a 20ms, mientras que el comando “TIM:ACQT?” hará que devuelva su tiempo de adquisición actual.

Puntos importantes a considerar son que los comandos no son sensibles a mayúsculas y minúsculas y admiten formas abreviadas, así, por ejemplo, “TRIG SOUR CH1” y “Trigger source Channel1” son ambas alternativas válidas del mismo comando. También puedes concatenar comandos, así por ejemplo, “TRIG SOUR CH1”, “TRIG LEVEL1 10” y “TRIG POL INV” pueden escribirse como “TRIG:SOUR CH1;LEVEL1 10;POL INV” ya que todos los comandos se aplican al mismo TRIG. Estos comandos establecen el canal fuente, su nivel en voltios y la polaridad. Este ejemplo establece el nivel del canal 1 a 10V con polaridad invertida. No tienes que especificar su disparador 1 ya que esto se asume, pero podrías usar “TRIG1:” para evitar ambigüedad.

El Proyecto de Codificación

El video que acompaña a este artículo muestra cómo crear tu propio equipo de prueba en red que utiliza comandos SCPI. Esto se basa en un video anterior que muestra cómo comunicarse con equipos de prueba para automatización.

El objetivo de este ejercicio es permitir que el hardware de prueba personalizado se integre sin problemas en cualquier software de prueba existente que pueda manejar comandos SCPI, como aquellos que usan las LAN eXtensions for Instrumentation (LXI) o la Arquitectura de Software de Instrumentos Virtuales (VISA). El objetivo final es desarrollar un dispositivo de prueba integrado y completo incorporando un microcontrolador en el hardware de prueba automatizado.

Codificando tu propio equipo de prueba en red

El tablero de desarrollo Infineon XMC4700 Relax Kit, hecho para aplicaciones industriales, está en el corazón del proyecto. El tablero incluye un microcontrolador con memoria estática y dinámica, relojes, suministros de energía, interfaces estándar y controles básicos. También incluye una conexión ethernet a bordo con una dirección de control de acceso al medio (MAC) para la red.

Un beneficio clave de esta configuración es la disponibilidad del entorno de desarrollo integrado Digital Application Virtual Engineer (DAVE) que proporciona Infineon. DAVE es una herramienta de desarrollo de software y generación de código basada en C para aplicaciones de microcontroladores. Permite simplificar el proceso de codificación, manejando convenientemente la mayoría de las tareas de configuración para que puedas concentrarte en implementar comandos SCPI.

El código de prueba que crearemos leerá la posición de un botón y controlará el estado de un LED. Esta prueba simplista ofrecerá un ejemplo fácil de entender y proporcionará un excelente punto de partida para una exploración más profunda del poder y los beneficios de las pruebas automatizadas.

Guía de Codificación Paso a Paso

Configuración del Proyecto:

Codificando tu propio equipo de prueba en red Una guía paso a paso

Al usar la herramienta DAVE para un nuevo proyecto, el primer paso es crear un nuevo archivo de proyecto usando la secuencia de comandos “Archivo -> Nuevo -> Proyecto DAVE”. Esta acción abrirá una nueva ventana donde puedes seleccionar la opción “Proyecto DAVE CE” y darle un nombre apropiado.

Codificando tu propio equipo de prueba en red Una guía paso a paso

Luego necesitarás elegir tu hardware objetivo; en este caso, el kit XMC4700 Relax.

A menos que tu proyecto vaya a estar limitado por recursos, siempre es una buena práctica usar la biblioteca estándar newlib con todas las características en lugar de la opción de tamaño nano.

Codificando tu propio equipo de prueba en red Una guía paso a paso

El siguiente paso es configurar los periféricos para el proyecto usando el comando “DAVE -> Añadir Nueva APP”.

Codificando tu propio equipo de prueba en red Una guía paso a paso

La primera configuración que se debe establecer es la conexión de red, y esto se hace con el comando “Ethernet -> ETH_LWIP”, que añade una pila de protocolo de internet ligero (IP) al proyecto para manejar esta interfaz.

Codificando tu propio equipo de prueba en red Una guía paso a paso

También necesitas añadir las interfaces de entrada/salida (IO) para el equipo de prueba, el botón y el indicador LED en este ejemplo. Ambos son componentes discretos, por lo que debes añadir dos “aplicaciones DIGITAL_IO” bajo la opción de comando del Sistema, una para cada elemento.

Prueba

Es una buena práctica renombrar las aplicaciones de IO para identificar sus funciones en sus nombres para facilitar la vida y prevenir el acceso accidental a la aplicación incorrecta. Este error puede ser difícil de detectar cuando se intenta depurar un programa de prueba que se comporta de manera inesperada.

Pruebas

También debes configurar la pila IP para la conexión Ethernet haciendo clic derecho en la "ETH_LWIP App" y seleccionando "Configurar instancia de APP". Descubrirás que el XMC4700 Relax Kit ya está preconfigurado, lo que ahorra tiempo. Necesitarás cambiar la dirección IP estática en la página de configuración de IP para que coincida con la subred del ordenador que estás utilizando para tus pruebas automatizadas. Además, el protocolo de datagramas de usuario (UDP) no es necesario en este ejemplo, por lo que puedes desactivarlo en la pestaña de configuración del protocolo.

Pruebas

Finalmente, necesitas proporcionar la asignación entre la configuración de pines de la APP y el hardware del microcontrolador utilizando la opción de asignación manual de pines para cada componente. Para configurar el botón discreto, haces clic derecho en el botón y seleccionas el comando "Asignador de Pines Manual".

Pruebas

Luego puedes elegir el número de pin apropiado para el botón en el Relax Kit desde el menú desplegable, que convenientemente proporciona etiquetas para hacer esto de manera sencilla. Configurar el LED y la conexión Ethernet sigue el mismo proceso. Descubrirás que la función de asignador de pines simplifica este proceso al permitirte seleccionar solo pines con la funcionalidad necesaria. La herramienta proporciona automáticamente todas las etiquetas del XMC4700 Relax Kit para facilitar esto.

Estos pasos completan la configuración de tu proyecto de prueba automatizada, y ahora estás listo para escribir el código de prueba.

Codificación de la Aplicación del Proyecto

Prueba

Puede generar el código para las aplicaciones simplemente haciendo clic en el botón “Generar Código” en la barra de herramientas de DAVE y luego esperar a que la operación se complete.

Antes de programar en serio, se recomienda un paso que es transferir la consola del microcontrolador al ordenador, proporcionando un fácil acceso a `printf`. Esto le permitirá formatear e imprimir datos para hacer que la escritura y depuración de código sea más rápida y fácil. Puede hacer esto habilitando “GDB Semi-Hosting” en la configuración. Esto se hace navegando a las “Propiedades del Proyecto”, procediendo a “C/C++ Build”, y luego seleccionando “Configuraciones”.

Pruebas

Bajo “ARM-GCC, Enlazador C, Varios”, necesitará agregar “–specs=rdimon.specs” a las banderas “Otras”. Este paso incorpora la configuración de semi-hosting para el enlazador.

Prueba

Luego puede ir a la sección “ARM-GCC Compilador C, Preprocesador” y agregar un símbolo recién definido de “XMC_DEBUG_ENABLE”. Esta configuración asegura la redirección de la consola en la configuración de construcción de depuración.

Pruebas

Necesitará en la configuración del proyecto desmarcar la casilla que proporciona “llamadas al sistema newlib por defecto” bajo la configuración de “ARM-GCC Enlazador C, General”. Si deja esto marcado, encontrará que interrumpe la inicialización del manejador del monitor y causa que la construcción falle.

A continuación, necesita inicializar el monitoreo, lo cual puede hacer agregando “extern void initialise_monitor_handles(void);” al principio de su código. Esta función necesita ser llamada después de la llamada a DAVE_Init();.

Note que la ortografía de “initialise” es la variante en inglés británico ya que la base de ARM está en Cambridge, Inglaterra. Usar la ortografía estadounidense provocará un error que puede ser difícil de resolver si no se nota la sutil diferencia de ortografía.

Codificación de Redes de Proyecto

El primer paso para hacer funcionar la red Ethernet es habilitar la pila IP Ligera para verificar nuevos mensajes regularmente. Puede hacer esto agregando una llamada a la función “sys_check_timeouts();” dentro de su bucle while infinito que se ejecuta después de que la inicialización esté completa.

Esta función necesitará depuración para permitir su ejecución en el microcontrolador. Puedes hacer esto creando una nueva configuración de depuración. Se recomienda desactivar la opción “Establecer punto de interrupción en: main” para permitir que el código se ejecute tan pronto como el microcontrolador se inicie. Seleccionar la opción de depuración cargará tu nuevo código en el microcontrolador.

Pruebas

Puedes confirmar que el código se está ejecutando al abrir una consola de Windows en tu computadora y hacer ping a la dirección IP de la placa de desarrollo, que en este ejemplo, es el XMC4700 Relax Kit. La placa de desarrollo debería responder a cada ping, confirmando que la placa está operativa y la conexión de red está funcionando.

El código de pila Lightweight IP manejará automáticamente las funciones del Protocolo de Mensajes de Control de Internet (ICMP). Sin embargo, debes crear código para manejar las conexiones entrantes y los datos del Protocolo de Control de Transmisión (TCP). Puedes hacer esto utilizando declaraciones de código de pila Lightweight IP estándar que no son específicas del microcontrolador.

Ahora que has completado la configuración de la conexión de red, puedes configurar el bloque de control de protocolo para escuchar en el puerto 5025, que el código SCPI utiliza para las comunicaciones. Deberías configurar la pila Lightweight IP para delegar todas las nuevas conexiones a una función llamada client_accept que necesitarás extender para manejar nuevos clientes. Todos los datos recibidos necesitarán ser redirigidos a una función de procesamiento separada que también emitirá un mensaje de depuración para indicar la recepción de una nueva conexión.

Implementar un método client_recv copiará los datos recibidos en un búfer para su procesamiento. Esta función también debe verificar las conexiones sin datos, lo que indica que el host remoto ha cerrado la conexión. Para esta condición, el código puede realizar acciones de limpieza para eliminar cualquier artefacto no deseado dejado por la conexión cerrada.

Compilar el código generará una compilación funcional si no hay errores de codificación que depurar.

Codificación de Proyecto IO

El siguiente paso es la configuración de las “Aplicaciones de IO Digital” para realizar sus operaciones requeridas.

Prueba

Haga clic derecho en cada aplicación y seleccione la opción “Configurar instancia de la aplicación”. La configuración predeterminada para los componentes IO es una entrada tristate, perfecta para el botón. Sin embargo, para el LED, necesitará cambiar la configuración a “Entrada/Salida” con una conducción fuerte y borde suave. Esta configuración de conducción fuerte asegura que la placa produzca suficiente corriente de conducción para iluminar el LED. La configuración de borde suave se refiere a la velocidad de transición del borde del pin. Un borde suave alivia cualquier efecto transitorio en la red de distribución de energía y reduce el riesgo de un impacto adverso en la conformidad electromagnética. Usar esta opción para la salida discreta es una buena práctica a menos que necesite una señal con tasas de borde de nanosegundos.

Regenerar el código actualizado agregará estos nuevos cambios a la construcción funcional. Es importante recordar siempre regenerar el código después de hacer cualquier cambio en una aplicación DAVE.

Codificación SCPI del Proyecto

Con las funciones de configuración e inicialización completas, la codificación del proyecto finalmente puede avanzar para implementar los comandos SCPI para pruebas. No es necesario implementar los comandos SCPI desde cero; una excepcional biblioteca SCPI-Parser de Jan Breuer está disponible en GitHub como punto de partida.

Puede aprovechar este recurso extrayendo la carpeta libscpi en la carpeta de Bibliotecas de su proyecto. Luego extraiga las carpetas scpi-def de “ejemplos -> común” en su carpeta de proyecto. Este paso importa la biblioteca SCPI-Parser y proporciona un buen punto de partida para implementar su proyecto.

Necesitará eliminar la carpeta de pruebas y el makefile en la biblioteca libscpi dentro del entorno de desarrollo integrado de DAVE, ya que serán incompatibles con la biblioteca ARM-GCC en uso.

Pruebas

Luego, regrese a la ventana de propiedades del proyecto bajo “Construir, Configuraciones, Compilador, Directorios” y agregue una referencia a la carpeta de includes de libscpi.

También necesitará abrir el archivo scpi-def.c y agregar una declaración include para “dave.h” para enlazar sus funciones IO al archivo scpi-def.

Como nota al margen, este archivo incluye una fantástica implementación de demostración de un Multímetro Digital y funciones para pruebas automatizadas. Desafortunadamente, estas funciones son incompatibles con el compilador ARM utilizado para este ejemplo, por lo que deben eliminarse. Sin embargo, si necesita implementar sus propias funciones en el futuro, puede referirse a los archivos originales para referencia.

Al editar el archivo, elimine todas las funciones de DMM y pruebas en el bloque de configuración de comandos pero retenga el código para el comando TST y todas las declaraciones siguientes, junto con los comandos SCPI estándar que la biblioteca manejará.

Puede definir la información de identificación para la configuración de prueba en el archivo “scpi-def.h”, de modo que usar el comando SCPI *IDN devolverá información útil en respuesta a cualquier solicitud de identificación.

Puede configurar los comandos SCPI en el archivo “main.c” del proyecto. Necesitará agregar el contexto SCPI a la función principal utilizando la propiedad user_context para pasar una referencia al bloque de control del protocolo Lightweight IP permitiendo la inicialización de la biblioteca SCPI. Luego, necesita agregar sus funciones para permitir que libscpi se comunique a través de la conexión de red. En este ejemplo, se deben definir las siguientes funciones:

  • La función “SCPI_Write” permite que libscpi envíe datos a través de la conexión de red.

  • La función “SCPI_Flush” notifica a la pila Lightweight IP para enviar cualquier dato en el búfer inmediatamente.

  • La función “SCPI_Error” proporciona un medio para manejar errores SCPI. Para este ejemplo básico, puede omitir esto con una simple llamada a la función printf.

  • La función “SCPI_Control” es una característica opcional que le permite escribir en el canal de control en el puerto TCP 5026, lo cual no requerirá para este ejemplo.

  • La función “SCPI_Reset” se llama en respuesta a recibir un comando de reinicio, revirtiendo todos los instrumentos de prueba a sus configuraciones predeterminadas. No hay equipo de prueba conectado para este ejemplo básico, por lo que puede omitir esto con una simple llamada a la función printf.

Prueba

Finalmente, el user_context necesita ser establecido para la nueva conexión de cliente al realizar una conexión a la pila Lightweight IP. Esto permitirá que los datos pasen a la biblioteca SCPI desde el búfer a través de la función client_recv a “SCPI_Input” para ser procesados. Deberá tener en cuenta que esta implementación no manejará múltiples conexiones simultáneamente pero representa una buena práctica de configuración de red.

Compilar el código actualizado y subirlo al microcontrolador debería resultar en un sistema de prueba que no solo continúa respondiendo a pings desde una Consola de Windows sino que también debería responder a comandos SCPI.

Pruebas de Código SCPI del Proyecto

Este proyecto de ejemplo utilizó una aplicación Rohde & Schwarz VISA Tester para probar comandos SCPI.

Prueba

Después de conectar la aplicación al equipo de prueba, la primera prueba es emitir una solicitud de identidad (IDN?). Este es un primer paso recomendado, y el comando es manejado completamente por la biblioteca SCPI, asegurando que las comunicaciones estén operativas y que hayas configurado correctamente la biblioteca. Esto significa que resolver cualquier problema relacionado con pruebas que requieran una respuesta de un dispositivo periférico o equipo de prueba puede asumir que las comunicaciones y la biblioteca no son sospechosas en el proceso de depuración.

Probar los periféricos requiere agregar nuevos patrones al arreglo `scpi_commands` para implementar las funciones requeridas. Se pueden incluir llamadas a la función “printf” para depurar la funcionalidad, proporcionando un método simple de verificar la ejecución del código.

Prueba

En el ejemplo, el código lee el estado del botón usando la función “scpi_result_t IO_Btn“ en la aplicación DAVE previamente configurada para el manejador del botón con el estado enviado usando la respuesta “SCPI_ResultBool”. El valor devuelto se invierte ya que este botón es un componente de baja activación.

Prueba

La función manejadora del LED analiza el parámetro de estado del botón recibido y establece el estado del LED apropiado. Si no existen parámetros, entonces no se toma ninguna acción en este ejemplo. Este paso utiliza la función “scpi_result_t IO_Led” para realizar su función.

Con el microcontrolador programado, puedes probar el código usando la pestaña Consola en la herramienta DAVE. Esto demostrará la recepción de la conexión y la operación del comando de solicitud de identidad.

Prueba

Puedes verificar el estado del botón enviando una consulta SCPI y probar la funcionalidad observando que el estado devuelto cambia cuando presionas el botón.

Puedes probar la funcionalidad del LED simplemente enviando comandos de encendido y apagado, observando el estado de la luz y monitoreando el estado de la consola.

Con ambos, el botón y el LED funcionando correctamente, tienes la base de un instrumento conectado a la red completamente funcional. La conexión de una plataforma de automatización de pruebas o escribir tu propio código de prueba te permitirá verificar remotamente el estado del botón y controlar el LED.

Conclusión

El artículo muestra cómo el uso del entorno de prueba integrado DAVE con una placa de desarrollo te permitirá crear y conectar tu propio equipo de prueba en red para integrarlo con tu equipo de banco y automatizar las pruebas de laboratorio.

Esta guía paso a paso es para una demostración de prueba de concepto elemental, pero seguir los pasos y obtener un sistema de prueba funcional te equipará con todo lo que necesitas para crear tus propios instrumentos de prueba.

Utilizaremos los principios que exploramos en este proyecto para crear un artículo práctico de equipo de prueba en un futuro cercano, así que mantente atento a futuros desarrollos.

Sobre el autor / Sobre la autora

Sobre el autor / Sobre la autora

Mark Harris es un ingeniero experto, con más de 12 años de experiencia diversa en el sector de la electrónica, que abarca desde contratos aeroespaciales y de defensa hasta pequeñas empresas emergentes, hobbies, etc. Antes de trasladarse al Reino Unido, Mark trabajaba para uno de los centros de investigación más grandes de Canadá –cada día traía consigo un proyecto o desafío diferente que involucraba electrónica, mecánica y software–. Asimismo, publica la biblioteca de base de datos de componentes de código abierto más extensa para Altium Designer, conocida como "Celestial Database Library". A Mark le atraen el hardware y el software de código abierto, así como encontrar soluciones innovadoras a los desafíos diarios que plantean estos proyectos. La electrónica es pura pasión: ver un producto pasar de una idea a convertirse en realidad y comenzar a interactuar con el mundo es una fuente de placer inagotable.
Se puede contactar con Mark directamente en: mark@originalcircuit.com

Documentación técnica relacionada

Volver a la Pàgina de Inicio
Thank you, you are now subscribed to updates.