Quiero saber si el código básico, especialmente cosas como el código de inicialización del dispositivo / periférico, tiene algún método de prueba, ya que hay poco o nada que puede salir mal al escribir en los registros (una vez que sepa que todas las direcciones están asignadas correctamente) . Además, este tipo de código generalmente tiene muy pocas ramas / rutas cuando el dispositivo se configura para una sola función, por lo que ¿qué tipo de pruebas serían necesarias o aplicables aquí?
Lo primero que verifico en una nueva placa, si está usando un oscilador interno o un cristal externo, es que tengo la frecuencia de reloj configurada correctamente. Esto es importante porque muchos de los periféricos, como UART, SPI, I2C y temporizadores dependen de ello.
La forma en que lo verifico es escribir un programa con un bucle corto, ya sea en lenguaje ensamblador donde puedo contar los ciclos manualmente, o C siempre que pueda obtener una lista de desensamblado y hacer lo mismo, y gire un LED encendido y apagado. Configuré un bucle para que se ejecute una vez por segundo. Ejecuto el código y verifico que el LED parpadea 60 veces en un minuto.
En cuanto a los periféricos, la mejor forma de verificarlos es usar un osciloscopio si tiene uno, y mirar en la línea RX para UART, CLK, MOSI y líneas de selección de chips para SPI, y SDA y SCL para I2C, y verifique que las líneas estén alternando y que el tiempo se vea correcto.
Si no tiene un osciloscopio, puede colocar LED en estas líneas y luego habilitar o deshabilitar los periféricos. Cuando está deshabilitado, la mayoría de las líneas estarán bajas (LED apagado), pero algunas serán altas, como el cable RX del UART (LED encendido). Cuando el periférico está habilitado, la mayoría de los LED deberían atenuarse, ya que las líneas se alternarán. Al ejecutarse en un bucle (deshabilitado / habilitado) es más fácil ver la diferencia entre activado o atenuado.
Para el UART, puede conectar la línea TX a la línea RX como un bucle. También puede conectarse a un cable UART a USB , y en la PC real a terminal un programa como RealTerm . Además de probar la interfaz, esto será útil para otra depuración más adelante.
Para otras piezas de código, uso varios LED como sea necesario para mostrar que se están ejecutando varias rutas en el código. Si tiene el UART funcionando y conectado a una PC, puede rociar su código con llamadas a una subrutina para mostrar un mensaje para mostrar qué puntos ha alcanzado el programa (o usar printf si tiene las bibliotecas de C estándar disponibles). Pero como señala Vladimir Cravero en un comentario a continuación, esto puede ralentizar su código (a 115.200 baudios, no demasiado, ya que el tiempo de un carácter es < 10 µs). Pero en ISRs y otros códigos críticos de tiempo, solo use LEDs.
Como Al Bundy señala en un comentario a continuación, los depuradores en el circuito también pueden ser útiles, especialmente si se pueden establecer varios puntos de interrupción, y aún más útiles si se pueden cambiar los puntos de una ubicación de memoria. No todos los depuradores tienen esa característica.
Sin embargo, no uso mucho los depuradores a menos que tenga que hacerlo, por ejemplo, para mirar bits en un registro periférico; o para localizar un error que no puedo encontrar por inspección; o al análisis rudimentario de la cobertura del código. Pero en general, me gusta ejecutar programas a su velocidad "normal", ya que generalmente se presentan muchos problemas que pueden no ocurrir cuando el programa es de un solo paso. La mayoría de mis programas utilizan muchas interrupciones, lo que interfiere con el uso de un depurador.
Lea otras preguntas en las etiquetas microcontroller embedded testing