Flujo de diseño integrado

No sé de un flujo de diseño definido, pero te diré lo que funciona para mí:

Primero, obviamente tienes que hacer el diseño general del sistema. Escriba algo que diga qué quiere que haga su widget en general y haga un diagrama de bloques. Esto le permite pasar al siguiente paso de seleccionar un procesador y elegir partes. Después de eso, es hora de jugar con las partes y ver cómo funcionan (si nunca las has usado antes). Para las piezas analógicas, las pegaré en una placa de pruebas y veré cómo se ven en un visor: cuánto rebote hay en los interruptores, qué tan rápido cambian las cosas, qué voltajes se producirán, etc. Entonces es una buena idea conectar todo. Hasta su microcontrolador de alguna manera. Esto le dirá 1) si conectarlo al microcontrolador cambia las características de la pieza. Luego escribiré un código ficticio en el microcontrolador para ver cómo interactúa con la parte y qué tipo de datos puedo esperar.

Para las partes digitales, prefiero usar un analizador lógico / generador de patrones o un pirata de bus y obtener el bloqueo del dispositivo antes de intentar conectarlo al microcontrolador. Esto le permite descubrir cosas importantes, como la tasa de buad que debe usar y la secuencia de comandos necesarios para que se comporte de la manera deseada.

Para cualquier algoritmo o función de biblioteca complicada, siempre creo una prueba de unidad y la pruebo en mi computadora de escritorio antes de intentar colocarla en el microcontrolador. He creado buffers circulares, buscadores de paquetes, funciones DIO, etc. de esta manera y es un sueño. Escribe la prueba de una función un poco, escribe la función un poco. Piense en nuevas funciones y pruebas a medida que avanza. Agregue pruebas de los escenarios del mundo real que haya encontrado (es decir, correo no deseado al comienzo de una secuencia de bytestream que intenta encontrar un paquete, un END mal colocado, etc.). Cuando esté seguro de que funciona lo suficientemente bien, compílelo en una biblioteca y copie el encabezado y el archivo de la biblioteca en los lugares apropiados para su compilador de microcontroladores. Tengo un makefile que compila todo mi código en bibliotecas para PSOC y AVR y luego las copia en las carpetas correctas para poder usarlas.

Antes de que empieces a reunir todo, me resulta útil escribir un plan de prueba. Comience con el escenario más optimista ("Engancho todo y funciona de inmediato") y luego vaya a "qué pasa si". ¿Y si no hay comunicación serial? Tenga puntos de prueba para sondear, use el bus pirata para conducir el puerto para ver si está funcionando, coloque puntos de interrupción en los controladores de interrupción de UART, etc. Siempre siga preguntando: ¿qué sucede si no funciona? ¿Cómo lo pruebo?

Entonces empiezas a juntarlo todo. Usted sabe qué hardware de soporte analógico necesitará para interconectar todo y tiene todo el código de fondo que desea usar. En este punto, probablemente haré una tabla para el proyecto (odio hacer un trabajo detallado en una placa de pruebas; un cable se va y has perdido media hora tratando de volver a ponerlo). Ahora puedes comenzar con el código de tu aplicación. Al hacer esto, encuentro útil tener un modo de respaldo. A veces harás tres cambios y todo dejará de funcionar. Es útil tener una función main () completamente separada que solo maneje cosas de bajo nivel, es decir, ¿mi UART sigue funcionando? ¿Funciona este botón? ¿Están todas mis luces conectadas? Por lo tanto, cuando cambia las cosas y todo se detiene, puede agregar una # definición en su código y cambiarla al modo de prueba de hardware para asegurarse de que no destruyó todo.

Solo sigue desarrollando y eventualmente terminarás. Esta es la parte a la que nunca llegué, así que buena suerte si lo haces :)

Me gusta planificar hitos (alcanzables) desde el principio. En lugar de apuntar siempre hacia el final, solo estás trabajando en algunas funciones para el próximo hito.

He probado un montón de cosas diferentes de flujo de trabajo. Parece que las partes más útiles de cualquier esquema de flujo de trabajo son las especificaciones (cómo se ve), las líneas de tiempo (cómo llegar) y las listas de tareas (qué hacer ahora).

Realmente los primeros y los últimos son los más importantes. Necesita saber lo que quiere hacer con la mayor precisión posible. También necesita saber qué hacer en un momento dado.