Quiero saber si el código básico, especialmente cosas como el código de inicialización de dispositivo / periférico tiene algún método de prueba, ya que hay poco o nada que pueda 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, entonces, ¿qué tipo de pruebas serían necesarias o aplicables aquí?
Respuestas:
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 él.
La forma en que lo verifico es escribiendo un programa con un bucle corto, ya sea en lenguaje ensamblador donde pueda contar los ciclos manualmente, o C siempre que pueda obtener una lista de desmontaje y hacer lo mismo, y encienda un LED y fuera. Configuré un bucle para que se ejecute una vez por segundo. Ejecuto el código y compruebo que el LED parpadea 60 veces en un minuto.
En lo que respecta a los periféricos, la mejor manera de verificarlos es usar un osciloscopio si tiene uno, y mirar la línea RX para UART, CLK, MOSI y las líneas de selección de chips para SPI, y las líneas 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 estará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 encendido o apagado.
Para el UART, puede conectar la línea TX a la línea RX como un bucle. También puede conectarse luego a un cable UART a USB , y en la PC real un terminal, un programa como RealTerm . Además de probar la interfaz, esto será útil para otra depuración posterior.
Para otras piezas de código, utilizo múltiples LED según 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 enviar un mensaje que muestre a qué puntos ha llegado el programa (o use printf si tiene las bibliotecas C estándar disponibles). Pero como Vladimir Cravero señala en un comentario a continuación, esto puede ralentizar un poco su código (a 115.200 baudios, no demasiado, ya que el tiempo de un carácter es <10 µs). Pero en los ISR y otros códigos críticos, solo use LED.
Como Al Bundy señala en un comentario a continuación, los depuradores en circuito también pueden ser útiles, particularmente si uno puede establecer múltiples puntos de interrupción, y aún más útil si puede cambiar el punto de interrupción en 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 buscar bits en un registro periférico; o para localizar un error que no puedo encontrar por inspección; o al análisis de cobertura de código rudimentario. Pero, en general, me gusta ejecutar programas a su velocidad "normal" ya que generalmente aparecen muchos problemas que pueden no aparecer cuando el programa tiene un solo paso. La mayoría de mis programas usan muchas interrupciones, lo que interfiere con el uso de un depurador.