Control de versiones de esquemas y código fuente.

12

Estoy desarrollando un dispositivo electrónico que tiene dos partes: hardware (esquemas Eagle) y firmware (código fuente 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 vale la pena versionar los esquemas cuando en realidad son archivos binarios (las nuevas versiones de Eagle usan algún formato XML, pero no es tan legible para los humanos ...)?

  • ¿Es buena idea poner fuentes y esquemas en un repositorio de Git? Tendría sentido, pero, por otro lado, mi registro contendría cambios de software y hardware. Además, el software puede tener varias ramas, pero el hardware probablemente no ...

  • ¿Cómo lidiar con las revisiones de hardware? ¿Etiquetarlos o guardarlos en directorios separados?

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

¿Podrías compartir tus mejores prácticas conmigo?

eagle hardware c++ klasyc
fuente
¿Funcionaría una solución comercial?
Eugene Sh.
55
No tocaría un sistema de control de versiones comercial nunca más. Mi experiencia con ellos es un flujo de trabajo terrible que es mucho más difícil de usar que svn o incluso git.
pjc50
Independientemente del software de control de versiones que utilice, asegúrese de que esté reemplazando todo el archivo cuando trate con esquemas y no mire el texto. He tenido que ser un problema en el pasado. Nunca querrás hacer una diferencia en la mayoría de los archivos esquemáticos.
Voltaje pico

Respuestas:

19

La mayor parte 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 las tonterías Altium SVN incorporadas)

Una de mis principales razones para hacerlo es que mis clientes no creen que Dropbox sea lo suficientemente seguro y necesito un sistema de respaldo al que pueda acceder en todo el mundo, con también un contexto de versiones sobre la mayoría de lo que hago. Así que configuré un servidor Git privado y un sistema de copia de seguridad cifrado y funciona de maravilla. Tableros, esquemas, código, documentación, informes, modificaciones manuales, todo se rastrea.

Normalmente crearía un Repositorio para Hardware, uno para Software y otro para Firmware si es un proyecto grande y potencialmente largo, pero para proyectos de servicio pequeños, ejemplos o pequeños experimentos, a menudo lo pongo todo en un repositorio, ya que el resultado el caos 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 son repositorios administrados por separado.

Para los proyectos más grandes, también uso comúnmente sistemas de seguimiento de errores para realizar un seguimiento de los problemas y las resoluciones, de nuevo para HW y SW, Mantis es un buen sistema que se puede usar de forma gratuita.

Para las revisiones de hardware que genero Gerbers, o lo que sea que tenga, etiquetado con el Git Hash para esa revisión, esos Gerbers son los únicos elementos discretos "anticuados" en carpetas por R01, 02, etc. Ya que no desea regenerarlos todo el tiempo, pero son archivos resultantes, por lo que no deberían ser versionados en Git, realmente (porque su software de diseño debe ser determinista con la generación de contenido de producción, o de lo contrario ...).

Si hay algo interesante en R01 que no está sucediendo en R02 (o al revés), tiene dos Git Hashes con los que puede comparar archivos fuente, no se preocupe.

Como nota final, un ejemplo conceptual de un proyecto tendría un repositorio de hardware, que también aloja un archivo "BoardPinout.h". Este archivo se incluye como un archivo versionado de forma 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.

Es decir, cada vez que cambio algunas señales sin modificar una amplia funcionalidad, el proyecto HW "actualiza" el BoardPinout, que luego puede actualizarse y usarse en Firmware, y así sucesivamente.

Asmyldof
fuente
1
¿Es realmente nunca tiene sentido poner hardware y firmware en diferentes repositorios? ¿Cómo sería un problema tenerlos en uno? Prefiero esperar que sea un problema si necesita realizar un seguimiento de los cambios en los componentes que pertenecen juntos (por ejemplo, los pines de E / S intercambiados deben reflejarse en diferentes asignaciones de firmware, y verificar versiones incompatibles conduciría a un caos).
Leftaroundabout
@leftaroundabout En primer lugar, inflar su repositorio de FW que cambia rápidamente con la mayor parte de un diseño CAD complejo no siempre es lo que desea, pero es posible que también desee volver a leer los bits sobre los repositorios secundarios y el enlace entre ellos. No es nada difícil de hacer con Git y eso soluciona exactamente ese problema sin causar todo tipo de intimidad inapropiada entre las secciones de diseño.
Asmyldof
1
"No todos mis clientes sienten que Dropbox es lo suficientemente seguro" Para el control de versiones de archivos, tienen el 100% de razón. Es especialmente peligroso si varios usuarios pueden modificar archivos al mismo tiempo, y aún más si tiene varios archivos que realmente comprenden un solo recurso. He visto que los "conjuntos de archivos" binarios se corrompen de esta manera (geodatabases de archivos ESRI, si tiene curiosidad).
jpmc26
1
@ jpmc26 Ese fue un comentario apresurado, la versión de todo comenzó inicialmente más como un aspecto de seguridad. Con unas pocas versiones de plantillas inteligentes de GitIgnore, ahora envuelve fácilmente todo sin problemas, con todas las ventajas que ofrece. De hecho, estoy totalmente de acuerdo contigo en Dropbox compartido. En el sitio de un cliente causa problemas sin fin. Los archivos en desarrollo generan infinitas copias en conflicto en las computadoras apagadas durante las partes de desarrollo, siendo uno de los más molestos.
Asmyldof
@leftaroundabout: depende de la relación entre el hardware y el firmware. Tomemos una analogía con los proyectos de software normales. ¿Confirmarías archivos gif y jpg junto con tu sitio web? En este caso, tanto el binario como la fuente cambian entre sí, incluso si las imágenes no cambian con tanta frecuencia. Pero ... ¿comprometerías el código fuente de Apache o Nginx con tu proyecto? Para el caso, ¿comprometerías el código fuente del kernel de Linux? En este caso, Apache o Nginx, y el kernel de Linux es más análogo al hardware: cambian pero independientemente del código que escribes que se ejecuta en ellos
slebetman
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.
/ tag
/ branch
/ trunk / hardware
/ trunk / software / firmware

Si corresponde con más subcarpetas como quizás / Firmware y / ConfigTool para software y / mainboard y / hijaboard 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 serigrafía 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 tratarlo en el nivel del repositorio, excepto dejar comentarios útiles sobre los commits.
Considere codificar cambios de hardware utilizando pines de E / S de repuesto. Algo así como usar 4 pines para codificar 16 versiones de hardware diferentes. También utilizamos una sola 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 funciones específicas.

Rev1.0
fuente
Estoy de acuerdo. También he visto una buena práctica de construir un "paquete de lanzamiento" - esquemas, lista de materiales, gerbers, todo el lote - con cada lanzamiento a producción. Los llama A, B, C, etc. y luego los archiva en algún lugar donde el equipo pueda consultarlos. Además, no olvide algunos medios para rastrear qué modificaciones de cable ha realizado en qué placas prototipo.
pjc50
@ pjc50: En realidad, también "compilamos" paquetes de lanzamiento, pero fuera del control de origen (pero con una referencia de revisión). Esencialmente será una copia exacta de todo lo que obtuvo el fabricante. Si realiza el desarrollo de hardware profesionalmente con una producción de alto volumen, es muy importante tener toda la información disponible en caso de que algo salga mal. Si no recuerda si envía a la casa de juntas "este documento importante" que tal vez especifique el grosor de cobre de PCB personalizado, puede estar en problemas.
Rev1.0