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?
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.
fonte
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.
fonte