Continuamos la serie de artículos sobre pruebas de automatización de sistemas embebidos. Este artículo le dirá cómo integrar de manera rápida y relativamente fácil la capacidad de controlar la potencia del dispositivo bajo prueba desde un script de prueba, así como también la capacidad de simular presionar botones mecánicos en un comando desde un script de prueba.
Entonces lo que tenemos:
- Docenas de dispositivos integrados en los que necesita probar la nueva versión de FirmWare (para ser más preciso, ensamblaje de firmware diario)
- Debido a la naturaleza del procedimiento de arranque de FW, es posible que deba restablecer la alimentación (el llamado modo de descarga de firmware en modo de captura de encendido)
- En algunos momentos específicos durante la ejecución del script de prueba, me gustaría simular presionar los botones mecánicos ubicados en la placa de depuración del sistema incorporado.
¿Por qué podría ser necesario el punto 3? En mi caso, la tarea es la siguiente: en el caso de una excepción crítica de la ejecución del código, el sistema "se levanta" a un estado medio muerto del cual no saldrá hasta que se apague (otra razón para la administración de energía). Pero lo más interesante es que si en este modo presiona el botón mecánico especialmente diseñado para este propósito, el llamado Registro de excepciones: información de depuración en la que será posible intentar comprender en qué lugar se produjo una excepción en el código.
Es precisamente por esta razón que para la automatización efectiva de la configuración de la prueba, se hizo necesario poder restablecer la alimentación del dispositivo y simular presionar los botones mecánicos en el tablero de depuración, "guardando" información muy importante sobre Excepción de perderlo pronto. tarde o temprano, un script de prueba que se da cuenta de que no hay respuesta del dispositivo intentará reanimarlo restableciendo la alimentación.
Una pequeña digresión lírica: a veces correrás durante semanas detrás de esta Excepción porque surge solo ocasionalmente cuando todas las estrellas convergen y no se cumplen muchas otras condiciones. Por lo tanto, cada registro de depuración es muy importante y necesario.
El análisis de la depuración de la placa de circuito mostró que el botón simplemente cierra la línea GPIO extraída a +3.3 V en GND. Entonces, si “suelda” el botón y usa el relé para cerrar la línea GPIO al suelo, entonces será lo que necesita.
A continuación, surgió la cuestión de elegir un dispositivo / módulo para el control al que se presentaron los siguientes requisitos:
- El número máximo de relés (necesita 2 piezas por dispositivo, y hay docenas de dispositivos)
- Acceso a Ethernet
- Administrar comandos de URL
- Capacidad para copiar y escalar el sistema.
Por tradición, se detuvieron en el módulo Etherent del relé Laurent-128:
El módulo, por todos los parámetros, nos hizo felices: podemos administrar 14 dispositivos a la vez (un relé para alimentación, el otro con solo tocar un botón) usando comandos de URL (muy conveniente para los lenguajes con script en los que se escribe la automatización de pruebas).
El diagrama de conexión y comunicación de la placa de depuración del dispositivo bajo prueba y el módulo de control se muestra en la siguiente figura:
El "Soldar" a los contactos de un botón mecánico en el ejemplo de uno de los dispositivos probados se ve así:
¡Hurra! La parte técnica está hecha. Lo único que queda es agregar el código de los procedimientos de prueba para que, si es necesario (descargue la imagen del firmware después de un reinicio de energía o una depuración de grabación con solo tocar un botón) dé un comando para encender / apagar el relé deseado.
La sintaxis de las URL de comando de control es simple y obvia. Por ejemplo, para habilitar el relé bajo el número 4, debe usar la siguiente dirección HTTP:
http://192.168.0.101/cmd.cgi?psw=Laurent&cmd=REL,4,1
Y aquí hay una función simple en Perl que se llama desde el procedimiento de prueba principal si necesita "tirar" del relé:
Observo que el sistema funciona de manera muy confiable sin bloqueos y bloqueos. Laurent-128 y el Laurent-112 utilizado anteriormente (para 12 relés) trabajaron durante un par de años sin fallas y paradas, teniendo en cuenta el trabajo diario.
Y aquí hay un ejemplo de tal excepción que se identificó durante las pruebas con un extraordinario ensamblaje de firmware diario. Después de que quedó claro para el script de prueba que no había respuesta del dispositivo en el puerto serie (es decir, "murió"), se hizo un intento de presionar el botón mecánico de emergencia para registrar la depuración y esto funcionó: el informe de prueba final generado por el script de prueba en sí estaba lleno de información útil de El lugar de un posible bloqueo del sistema para su posterior análisis por parte del equipo de desarrollo:
