Controle de versão de esquemas e código fonte

Estou desenvolvendo um dispositivo eletrônico que possui duas partes: hardware (esquemas Eagle) e firmware (código fonte C ++). Gostaria de acompanhar as alterações no código-fonte e nos esquemas, mas há alguns pontos em que não tenho certeza de como organizar meu trabalho:

Para o código fonte, eu definitivamente usaria o Git. Mas os esquemas valem a versão quando, na verdade, são arquivos binários (as novas versões do Eagle usam algum formato XML, mas não é tão legível por humanos ...)?
É uma boa ideia colocar fontes e esquemas em um repositório Git? Isso faria sentido, mas, por outro lado, meu registro conteria alterações de software e hardware. Além disso, o software pode ter várias ramificações, mas o hardware provavelmente não ...
Como lidar com revisões de hardware? Identifique-os ou salve-os em diretórios separados?
Também pode haver algumas dependências entre a revisão de hardware e a versão do firmware. Como lidar com eles?

Você poderia compartilhar suas melhores práticas comigo?

eagle hardware c++

— klasyc
fonte

Uma solução comercial funcionaria?

— Eugene Sh.

Eu nunca mais tocaria em um sistema de controle de versão comercial. Minha experiência com eles são terríveis fluxos de trabalho que são muito mais difíceis de usar do que o svn ou até o git.

— Pjc50

Qualquer que seja o software de controle de versão usado, verifique se ele substitui o arquivo inteiro ao lidar com esquemas e não olhar para o texto. Eu já tive esse problema no passado. Você nunca gostaria de fazer uma diferença na maioria dos arquivos esquemáticos.

— Voltage Spike

Respostas:

A maior parte se resume a preferências pessoais.

Eu rastreio tudo o que faço para um projeto no Git. Especialmente porque o Git lida com a maioria dos tipos de arquivos, mesmo binários, com eficiência suficiente. (Em vez de absurdo interno do Altium SVN)

Um dos meus principais motivos para fazer isso é que meus clientes nem todos acham que o Dropbox é seguro o suficiente e que eu preciso de um sistema de backup que eu possa acessar em todo o mundo, com também algum contexto de versão na maior parte do que faço. Então, eu configurei um servidor Git privado e um sistema de backup criptografado e isso funciona muito bem. Placas, Esquemas, Código, Documentação, Relatórios, Modificações Manuais, tudo é rastreado.

Normalmente, eu criaria um Repositório para Hardware, um para Software e outro para Firmware, se for um projeto grande e potencialmente demorado, mas para pequenos projetos de serviços, exemplos ou pequenas experiências, costumo colocar tudo em um repositório, pois os resultados o caos não será grande.

No Git, você também pode usar sub-repositórios para integrar o Firmware ao projeto de Hardware ou o contrário, mesmo que sejam repositórios gerenciados separadamente.

Para os projetos maiores, também costumo usar sistemas de rastreamento de bugs para rastrear problemas e resoluções, tanto para HW quanto para SW, o Mantis é um bom que pode ser usado gratuitamente.

Para revisões de hardware, eu gero Gerbers, ou o que você tiver, marcado com o Git Hash para essa revisão, esses Gerbers são os únicos itens com versão "antiquados" discretos nas pastas R01, 02, etc. Como você não deseja regenere-os o tempo todo, mas eles são arquivos resultantes, portanto, não devem ser versionados no próprio Git, realmente (porque seu software de design deve ser determinístico na geração de conteúdo de produção, ou então ...).

Se houver algo interessante no R01 que não esteja acontecendo no R02 (ou o contrário), você terá dois Git Hashes com os quais poderá comparar os arquivos de origem, não se preocupe.

Como observação final, um exemplo conceitual de um projeto teria um repositório de Hardware, que também hospeda um arquivo "BoardPinout.h". Este arquivo é incluído como um arquivo com versão remota no repositório de firmware, que possui alguns arquivos de definição de interface que são incluídos remotamente no repositório de software.

Ou seja, toda vez que altero alguns sinais sem modificar a ampla funcionalidade, o projeto HW "atualiza" o BoardPinout, que pode ser atualizado e usado no firmware e assim por diante.

— Asmyldof
fonte

Será que realmente nunca faz sentido colocar hardware e firmware em diferentes repos? Como seria um problema tê-los em um? Eu prefiro esperar que seja um problema se você precisar acompanhar as alterações nos componentes que pertencem um ao outro (por exemplo, pinos de E / S trocados precisam ser refletidos em diferentes atribuições de firmware, e verificar as versões incomptíveis levaria ao caos).

— leftaroundabout

@leftaroundabout Primeiro, inflar seu repositório de FW em rápida mudança com a maior parte de um projeto CAD complexo nem sempre é o que você deseja, mas também pode reler os bits sobre sub-repositórios e vínculos entre eles. Não é nada difícil de fazer com o Git e isso resolve exatamente esse problema sem causar todos os tipos de intimidade inadequada entre os setores do design.

— Asmyldof

"meus clientes nem todos acham que o Dropbox é seguro o suficiente" Para arquivos de versão, eles estão 100% certos. É especialmente perigoso se vários usuários puderem modificar arquivos ao mesmo tempo e ainda mais se você tiver vários arquivos que realmente compreendem um único recurso. Vi "conjuntos de arquivos" binários serem corrompidos dessa maneira (bancos de dados de arquivos ESRI, se você estiver curioso).

— Jpmc26

@ jpmc26 Esse foi um comentário apressado, o versionamento de tudo começou inicialmente mais como um aspecto de segurança. Com alguns modelos inteligentes do GitIgnore, a versão agora envolve facilmente tudo sem problemas, com todas as vantagens que ele traz. Na verdade, concordo plenamente com você no Dropbox compartilhado. Em um site do cliente, isso causa problemas sem fim. Os arquivos em desenvolvimento gerando infinitas cópias conflitantes nos computadores foram desativados durante partes do desenvolvimento, sendo um dos mais irritantes.

— Asmyldof 15/02

@leftaroundabout: Depende da relação entre o hardware e o firmware. Vamos fazer uma analogia com projetos de software normais. Você enviaria arquivos gif e jpg junto com seu site? Nesse caso, o binário e a fonte mudam entre si, mesmo que as imagens não mudem com tanta frequência. Mas .. você confirmaria o código-fonte Apache ou Nginx com seu projeto. Nesse caso, você confirmaria o código-fonte do kernel do Linux? Nesse caso, o Apache ou o Nginx e o kernel Linux são mais análogos ao hardware - eles mudam, mas independentemente do código que você escreve rodando neles

— slebetman

1) Definitivamente vale a pena versionar arquivos esquemáticos / de placa. Mesmo que você não consiga rastrear as diferenças com tanta facilidade, você tem uma maneira limpa de reverter para uma versão de hardware específica se precisar trabalhar com uma revisão de dispositivo antiga.

2) Temos a seguinte estrutura em nosso SVN.
/ tag
/ branch
/ trunk / hardware
/ trunk / software / firmware

Se aplicável, com mais subpastas como talvez / Firmware e / ConfigTool para software e / mainboard e / daughterboard ou algo parecido com isso para hardware.

2) Tags são criadas a partir de subpastas e não de todo o tronco, como Tag / Mainboard-v1.2.345. O hardware (ou seja, o PCB) sempre contém a revisão SVN na serigrafia ou em cobre para ter uma referência direta.

4) Dependências entre hardware e firmware podem ser complexas. Na IMO, não faz muito sentido lidar com isso no nível do repositório, exceto deixando comentários úteis sobre as confirmações.
Considere a codificação de alterações de hardware usando pinos de E / S sobressalentes. Algo como usar 4 pinos para codificar 16 versões de hardware diferentes. Também usamos uma única entrada ADC com diferentes valores de resistência para codificar versões. Dessa forma, o software pode "saber" em qual hardware ele executa e alterar / desativar / ativar recursos específicos.

— Rev1.0
fonte

Concordo. Também vi uma boa prática de criar um "pacote de lançamentos" - esquemas, BOM, gerbers, todo o lote - na ocasião de cada lançamento na produção. Você os chama de A, B, C etc e depois arquiva-os em algum lugar onde a equipe possa se referir a eles. Além disso, não esqueça de alguns meios de rastrear quais mods de fio você fez em quais placas de protótipo.

— Pjc50

@ pjc50: Na verdade, nós "construímos" pacotes de versões também, mas fora do controle de origem (mas com uma referência de revisão). Essencialmente, será uma cópia exata de tudo o que o fabricante obteve. Se você desenvolve o desenvolvimento de hardware profissionalmente com alto volume de produção, é muito importante ter todas as informações prontamente disponíveis, caso algo dê errado. Se você não se lembra de enviar a casa do conselho "este documento importante" que talvez especifique a espessura personalizada do cobre da placa de circuito impresso, você pode estar com problemas.

— 1.01 de