Control de versiones de esquemas y código fuente

10

Estoy desarrollando un dispositivo electrónico que tiene dos partes: hardware (esquemas Eagle) y firmware (código fuente de C ++). Me gustaría hacer un seguimiento de los cambios tanto en el código fuente como en los esquemas, pero hay algunos puntos en los que no estoy seguro de cómo organizar mi trabajo:

  • Para el código fuente definitivamente usaría Git. Pero valen los esquemas Versiones cuando en realidad son archivos binarios (nuevas versiones de Eagle usa algún formato XML, pero no es tan fácil de leer ...)?

  • ¿Es una buena idea colocar las fuentes y los esquemas en un repositorio Git? Eso Tendría sentido, pero por otro lado mi registro contendría tanto software y cambios de hardware. También el software puede tener varias ramas, pero hardware probablemente no ...

  • ¿Cómo lidiar con las revisiones de hardware? Etiquétalos o guárdalos por separado. directorios?

  • También podría haber algunas dependencias entre la revisión del hardware y el firmware. versión. ¿Cómo lidiar con ellos?

¿Podría compartir sus mejores prácticas conmigo?

    
pregunta klasyc

2 respuestas

18

La mayoría se reduce a preferencias personales.

Rastreo todo lo que hago para un proyecto en Git. Especialmente porque Git maneja la mayoría de los tipos de archivos, incluso binarios, de manera suficientemente eficiente. (En lugar de sin sentido Altium SVN incorporado)

Una de mis principales razones para hacerlo es que mis clientes no sienten que Dropbox sea lo suficientemente seguro y que necesito un sistema de respaldo al que pueda acceder en todo el mundo, también con algún contexto de versiones en la mayoría de lo que hago. hacer. Así que configuré un servidor Git privado y un sistema de copia de seguridad encriptado y funciona muy bien. Tableros, esquemas, código, documentación, informes, modificaciones manuales, todo está rastreado.

Normalmente crearía un Repositorio para Hardware, uno para Software y Firmware si es un proyecto grande, potencialmente de larga ejecución, pero para pequeños proyectos de servicio, ejemplos o pequeños experimentos, a menudo lo pongo todo en un repositorio, ya que el caos resultante no será grande.

En Git puede usar sub repositorios también para integrar el Firmware en el proyecto de Hardware o al revés, incluso si se trata de repositorios administrados por separado.

Para los proyectos más grandes, también suelo utilizar sistemas de seguimiento de errores para realizar un seguimiento de los problemas y las resoluciones, de nuevo para HW y SW, Mantis es una buena opción que se puede utilizar de forma gratuita.

Para las revisiones de hardware genero a Gerbers, o lo que sea, etiquetado con el Git Hash para esa revisión, esos Gerberos son los únicos elementos discretos "pasados de moda" versionados en carpetas por R01, 02, etc. t desea regenerarlos todo el tiempo, pero son archivos resultantes, por lo que no deberían ser versionados en Git en realidad (porque su software de diseño debería ser determinista al generar contenido de producción, o bien ...).

Si hay algo interesante en R01 que no está sucediendo en R02 (o al revés), tienes dos Git Hashes con los que puedes comparar archivos de origen, sin preocupaciones.

Como nota final, un ejemplo conceptual de un proyecto, tendría un repositorio de Hardware, que también alberga un archivo "BoardPinout.h". Este archivo se incluye como un archivo de versión remota en el repositorio de Firmware, que tiene algunos archivos de definición de interfaz que se incluyen de forma remota en el repositorio de Software.

Lo que significa que cada vez que cambio algunas señales sin modificar la funcionalidad general, el proyecto HW "actualiza" el BoardPinout, que luego puede actualizarse y usarse en Firmware, y así sucesivamente.

    
respondido por el Asmyldof
5

1) Definitivamente vale la pena versionar archivos esquemáticos / de placa. Incluso si no puede rastrear las diferencias tan fácilmente, tiene una manera limpia de volver a una versión de hardware específica si tiene que trabajar con una revisión de dispositivo anterior.

2) Tenemos la siguiente estructura en nuestro SVN.
/ etiqueta
/ rama
/ tronco / hardware
/ trunk / software / firmware

Si corresponde con más subcarpetas como tal / Firmware y / ConfigTool para software y / mainboard y / daughterboard o algo así para hardware.

2) Las etiquetas se crean a partir de subcarpetas, no de todo el tronco, como Tag / Mainboard-v1.2.345. El hardware (es decir, el PCB) siempre contiene la revisión SVN en la impresión de pantalla de seda o en cobre para tener una referencia directa.

4) Las dependencias entre hardware y firmware pueden ser complejas. En mi opinión, no tiene mucho sentido tratar con él en el nivel del repositorio, excepto dejar comentarios útiles en las confirmaciones. Considere la posibilidad de codificar cambios de hardware utilizando pines de E / S de repuesto. Algo así como usar 4 pines para codificar 16 versiones diferentes de hardware. También utilizamos una única entrada ADC con diferentes valores de resistencia para codificar versiones. De esta manera, el software puede "saber" en qué hardware se ejecuta y cambiar / deshabilitar / habilitar características específicas.

    
respondido por el Rev1.0

Lea otras preguntas en las etiquetas