Estoy tratando de crear un producto integrado, pero soy nuevo en las pruebas de firmware y quiero asegurarme de no perderme nada. ¿Cuáles son las cosas que deben verificarse para el rendimiento del firmware?
El temporizador de vigilancia adecuado es una cosa que debe verificarse. El uso de Flash/RAM podría ser otro. ¿Qué más se debe verificar para asegurarse de que el producto tenga un firmware "bueno"?
Principalmente trato con compiladores PIC y C.
Algunos de estos son más controles idiotas del código que procedimientos de prueba reales, pero son buenos para hacer de todos modos.
Asegúrate de tener buenas especificaciones . Si tiene especificaciones claras para cada variable posible que sea importante para su proyecto, las pruebas deberían ser solo una cuestión de comparación con la especificación. Nunca lo es, pero es un buen objetivo. Una cosa que a veces queda fuera de las especificaciones es el tiempo de respuesta . Si su sistema hace lo que se le dice, pero tarda un segundo en lugar de un milisegundo, todavía no tiene un buen sistema.
Pruebe cada pieza individual del firmware por separado. Asegúrese de que los convertidores A/D funcionen, asegúrese de que las luces se enciendan según lo ordenado, asegúrese de que cada entrada funcione, asegúrese de que cada salida funcione, asegúrese de que los temporizadores funcionen. Entonces empieza a preocuparte por cómo funciona todo junto. Es casi seguro que el firmware no funcionará en la primera pasada y, de todos modos, tendrás que descomponerlo. Lo mejor es empezar por ahí.
Encienda y apague la placa docenas de veces y asegúrese de que todo se inicie correctamente de forma constante. Probablemente sea una buena idea observar todos los rieles de alimentación en un alcance y asegurarse de que todos los reguladores se inicien. Haga esto con todas las combinaciones posibles de entradas y fuentes de alimentación. Esto prueba tanto su hardware como su software.
Exponga la unidad a ruido EMI/RFI. Por lo general, tomo un probador de hipot CA y lo corto para generar chispas de baja corriente de alto voltaje. Causa estragos en los circuitos que carecen de inmunidad al ruido. (Además, arrastrar las chispas por el chasis te hace sentir como una versión diminuta del Emperador Palpatine. Pero tal vez solo soy yo). Esto prueba tanto tu hardware como tu software.
Busque todos los casos posibles de división o módulo por una variable. Asegúrese de nunca, nunca, dividir o modificar por una variable que posiblemente podría establecerse en cero.
Busque todos los punteros y asegúrese de que ninguna de las miles de cosas que puede hacer mal con los punteros pueda suceder.
Busque todas las matrices y asegúrese de que nunca pueda salirse del final de la matriz.
Busque todas las instancias de lo que pretendía ser una comparación (==) y asegúrese de que no sean una asignación (=). Una expresión regular útil para esto sería: (.+ = .+)
Busque cualquier ocasión de escritura de EEPROM y asegúrese de probar a fondo esos casos. La EEPROM es lenta , por lo que varias escrituras de EEPROM en serie pueden ralentizar otros procesos de tiempo crítico. Esto podría simplemente disparar su temporizador de vigilancia y provocar un reinicio, o (en el caso de una fuente de alimentación conmutada) esto podría causar una explosión porque sus salidas no se actualizaron correctamente.
Si está utilizando alguna interrupción, intente no hacerlo a menos que sea absolutamente necesario. Aumentan drásticamente el número de posibles interacciones de código inesperadas. Si tiene que usar interrupciones, considere lo que sucede si la interrupción ocurre en cada punto posible de la ejecución de su programa. Además, considere todas las anidaciones posibles de interrupciones, o simplemente deshabilite las interrupciones anidadas para que no tenga que preocuparse por eso.
Pruebe CADA característica en tantas combinaciones y escenarios únicos de casos de esquina como sea técnicamente factible. Cualquier cantidad menor y es posible que esté entregando un producto defectuoso.
Spehro Pefhany
Juan U.
olin lathrop