¿Qué es equivalente a una compilación diaria (y prueba de humo) para diseños esquemáticos?

One little nit: solo los desarrolladores realmente descuidados usan compilaciones diarias porque una compilación al día significa tener que esperar hasta un día para descubrir si rompió la compilación.

La mejor solución es crear y probar cada cambio individualmente antes de permitir que llegue a la sucursal pública y revertir el cambio si rompe la compilación de alguna manera.

Hacer cualquier tipo de prueba automática en un esquema o en un diseño de tablero puede ser muy difícil o imposible, pero todo lo que pueda automatizar debe automatizarse a través de algo como Hudson, las cosas que me vienen a la mente son:

• ERC
• DRC
• Actualización de la lista de materiales (verifique que existan las piezas, estén disponibles y calcule el costo total)
• Generar Gerbers y otros archivos de fabricación.
• Genere archivos PDF de las capas de esquemas y PCB, así como representaciones 3D del PDB, BOM diff y otra documentación.
• Coloque un correo en la lista de correo del desarrollador con el mensaje de confirmación y enlaces a los archivos de salida, para que los desarrolladores puedan revisar el cambio fácilmente.

El número de errores que pueden detectarse automáticamente puede no ser terriblemente alto, pero si el sistema CI genera los archivos de salida, esto ocurrirá correctamente cada vez que no se olvide de una configuración tonta cuando se hace manualmente.

No creo que haya un análogo de la compilación diaria del hardware. Es posible que no se pueda registrar un esquema si no pasa el DRC (o tal vez la simulación) pero eso es todo lo que puedo imaginar. La gente del software tiene la ventaja de poder ejecutar el producto terminado (en su mayor parte) en cualquier momento y obtienen muchas herramientas automatizadas. Los programas de captura esquemáticos y los simuladores en su mayor parte no están al tanto de la automatización, el control de versiones, etc. y es realmente una pena. Me gustaría ver el proceso de diseño del software imitado tanto como sea posible para el hardware, pero dudo que sea completamente posible.

Supongo que si sus herramientas lo admiten, podría exportar listas de redes y hacer algo con ellas que encuentre muy repetitivo y mundano.

Una cosa útil en la que puedo pensar es en generar la factura de las partes. Solía trabajar en una pequeña empresa que diseñaba los esquemas de hardware y las listas de redes y especificaba las partes, y luego subcontrataba el diseño a expertos en diseño de PCB.

Tuvimos un programa Excel VBA muy útil para leer en la lista de redes y generar la lista de piezas a partir de una base de datos de piezas.

La idea de una compilación diaria de software es detectar los problemas introducidos por los cambios.

Si cambia el esquema, deberá probar el PCB antes de ir a la fabricación. Puede reducir los riesgos si registra y revisa todos los cambios.

Creo que el equivalente más cercano es desarrollar la prueba de producción Accesorio y guión de prueba para su circuito tan pronto como sea posible. Hacer Seguro que prueba todas las funcionalidades importantes. El accesorio de prueba emula cualquier interfaz de usuario y hardware del sensor están conectados a la circuito. El script de prueba de "verificación de diseño" probablemente tendrá Más pruebas y tome más tiempo que el script de prueba de producción, donde En su mayoría están probando para ver que las piezas están conectadas entre sí. correctamente.

Entonces, cuando estás haciendo cambios al firmware o al circuito En sí mismo, ocasionalmente puede ejecutar la prueba de verificación de diseño contra Es para asegurarse de que no ha causado ninguna regresión. Tambien es Es útil hacer guiones de prueba reducidos para probar un aspecto de la Rendimiento del circuito, por ejemplo, prueba de respuesta en el suministro. variaciones, o una máquina de estado particularmente difícil que requeriría Dos páginas de instrucciones para que un humano intente. Estos mas cortos Los scripts son para ahorrar tiempo y dar una mejor cobertura de prueba que la completa guión. Pero siempre ejecuta la prueba de verificación antes de cometer Cambios en el esquema o firmware. Para el diseño final publicado, ejecute la prueba de verificación a través de la temperatura.