Estoy tratando de hacer un producto incorporado, pero soy nuevo en las pruebas de firmware y quiero asegurarme de no perder nada. ¿Cuáles son las cosas que deben verificarse para el rendimiento de su firmware?
El temporizador de vigilancia apropiado es una cosa que debe verificarse. El uso de Flash / RAM podría ser otro. ¿Qué otra cosa debe verificarse para asegurarse de que el producto tenga un firmware "bueno"?
En mi mayor parte trato con PIC y compiladores de C.
Algunos de estos son más controles de idiotas del código que los 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 es importante para su proyecto, las pruebas deben ser simplemente una cuestión de comparación con la especificación. Nunca lo es, pero es un buen objetivo. Una cosa que a veces se queda fuera de las especificaciones es el tiempo de respuesta . Si su sistema hace lo que se le indica, pero toma un segundo en lugar de un milisegundo, todavía no tiene un buen sistema.
Pruebe cada pieza individual del firmware por separado. Asegúrate que Los convertidores A / D funcionan, 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 funciona, asegúrese de que los temporizadores funcionan. Entonces comienza a preocuparte por cómo funciona todo junto. Es casi seguro que el firmware no funcionará en la primera pasada, y Tendrás que romperlo en pedazos de todos modos. Mejor comenzar allí.
Enciende y apaga el tablero muchas docenas de veces y asegúrate de que todo arranca correctamente sobre una base consistente. Probablemente sea una buena idea Mire todos los rieles de alimentación en un alcance y asegúrese de que todos los reguladores puesta en marcha. Haga esto con cada combinación posible de entradas y potencia. suministros. Esto prueba tanto su hardware como su software.
Exponga la unidad al ruido EMI / RFI. Normalmente tomo un probador de hipotecas AC y acortarlo a sí mismo para generar chispas de bajo voltaje de alto voltaje. Causa estragos en los circuitos que carecen de inmunidad al ruido. (Además, arrastrando el Las chispas a lo largo del chasis te hacen sentir como una versión pequeña de Emperador Palpatine. Pero tal vez eso sea solo yo.) Esto prueba tanto tu hardware y su software.
Busque todos los casos posibles de división o módulo por una variable. Asegúrese de que nunca, nunca, puede dividir o modificar por una variable que podría posiblemente se ponga a cero.
Busca todos los punteros y asegúrate de que ninguna de las mil cosas puede hacer mal con los punteros posiblemente suceda.
Busca todas las matrices y asegúrate de que nunca puedas ejecutar el final de la matriz.
Busque todas las instancias de lo que pretendía ser una comparación (==) y Asegúrate de que no sean asignaciones (=). Una expresión regular útil para esto sería be: (. + =. +)
Busque las ocasiones de escrituras de EEPROM y asegúrese de Pon a prueba esos casos. EEPROM es lento , por lo que múltiples EEPROM escriben en Las series pueden ralentizar otros procesos críticos. Esto podría simplemente dispare su temporizador de vigilancia y provoque un reinicio, o (en el caso de una fuente de alimentación conmutada) esto podría causar una explosión debido a que su Las salidas no se actualizaron correctamente.
Si está usando alguna interrupción, intente no hacerlo a menos que sea absolutamente necesario. Aumentan el número de posibles códigos inesperados. interacciones dramáticamente. Si tiene que usar interrupciones, considere ¿Qué sucede si la interrupción ocurre en cada punto posible en el Ejecución de su programa. Además, considere todos los anidamientos posibles de interrupciones, o simplemente deshabilitar las interrupciones anidadas para que no tenga que preocuparse por eso.
Pruebe CADA característica en tantas combinaciones y escenarios únicos de esquinas como sea técnicamente posible. Algo menos y puede que esté entregando un producto defectuoso.