Contrôle de version des schémas et du code source

Je développe un appareil électronique qui comprend deux parties: le matériel (schémas Eagle) et le firmware (code source C ++). Je voudrais suivre les changements dans le code source et les schémas, mais il y a certains points où je ne sais pas comment organiser mon travail:

Pour le code source, j'utiliserais certainement Git. Mais les schémas valent-ils la version alors qu'ils sont en fait des fichiers binaires (les nouvelles versions d'Eagle utilisent un certain format XML, mais ce n'est pas si lisible par l'homme ...)?
Est-ce une bonne idée de mettre les sources et les schémas dans un référentiel Git? Cela aurait du sens, mais d'un autre côté, mon journal contiendrait des modifications logicielles et matérielles. Le logiciel peut également avoir plusieurs branches, mais le matériel ne l'est probablement pas ...
Comment gérer les révisions matérielles? Les étiqueter ou les enregistrer dans des répertoires séparés?
Il pourrait également y avoir des dépendances entre la révision du matériel et la version du firmware. Comment y faire face?

Pourriez-vous s'il vous plaît partager vos meilleures pratiques avec moi?

eagle hardware c++

— klasyc
source

Une solution commerciale fonctionnerait-elle?

— Eugene Sh.

Je ne toucherais plus jamais à un système de contrôle de version commercial. Mon expérience en la matière est de terribles workflows qui sont beaucoup plus difficiles à utiliser que svn ou même git.

— pjc50

Quel que soit le logiciel de version que vous utilisez, assurez-vous qu'il remplace le fichier entier lorsque vous traitez des schémas et ne regardez pas le texte. J'ai eu un problème dans le passé. Vous ne voudriez jamais faire de différence sur la plupart des fichiers schématiques.

— Voltage Spike

Réponses:

La plupart se résument à des préférences personnelles.

Je fais le suivi de tout ce que je fais pour un projet dans Git. D'autant plus que Git gère la plupart des types de fichiers, même binaires, de manière suffisamment efficace. (Au lieu de non-sens Altium SVN intégré)

L'une de mes principales raisons pour le faire est que mes clients ne pensent pas tous que Dropbox est suffisamment sûr et j'ai besoin d'un système de sauvegarde auquel je puisse accéder à travers le monde, avec également un contexte de versioning sur la plupart de mes activités. J'ai donc mis en place un serveur Git privé et un système de sauvegarde crypté et ça marche un régal. Cartes, schémas, code, documentation, rapports, modifications manuelles, tout est suivi.

Je créerais normalement un référentiel pour le matériel, un pour le logiciel et un pour le micrologiciel s'il s'agit d'un grand projet potentiellement de longue durée, mais pour les petits projets de service, des exemples ou de petites expériences, je mets souvent le tout dans un seul référentiel, car le résultat le chaos ne sera pas grand.

Dans Git, vous pouvez également utiliser des sous-référentiels pour intégrer le micrologiciel dans le projet matériel ou inversement, même s'il s'agit de référentiels gérés séparément.

Pour les projets plus importants, j'utilise également couramment des systèmes de suivi des bogues pour garder une trace des problèmes et des résolutions, encore une fois pour HW ainsi que SW, Mantis est un bon qui peut être utilisé gratuitement.

Pour les révisions matérielles, je génère des Gerbers, ou tout ce que vous avez, étiquetés avec le Git Hash pour cette révision, ces Gerbers sont alors les seuls éléments versionnés "à l'ancienne" discrets dans les dossiers par R01, 02, etc. Puisque vous ne voulez pas les régénérer tout le temps, mais ce sont des fichiers résultants donc ne devraient pas être versionnés dans Git lui-même, vraiment (parce que votre logiciel de conception devrait être déterministe avec la génération de contenu de production, ou bien ...).

S'il y a quelque chose d'intéressant dans R01 qui ne se produit pas dans R02 (ou l'inverse), vous avez deux Git Hash avec lesquels vous pouvez comparer les fichiers source, pas de soucis.

Enfin, un exemple conceptuel d'un projet aurait un référentiel matériel, qui héberge également un fichier "BoardPinout.h". Ce fichier est inclus en tant que fichier versionné à distance dans le référentiel du micrologiciel, qui contient quelques fichiers de définition d'interface qui sont inclus à distance dans le référentiel logiciel.

Cela signifie que chaque fois que je modifie quelques signaux sans modifier les fonctionnalités générales, le projet HW "met à jour" le BoardPinout, qui peut ensuite être mis à jour et utilisé dans le micrologiciel, etc.

— Asmyldof
source

Est - il vraiment jamais judicieux de mettre le matériel et firmware dans différentes prises en pension? Comment serait-ce un problème de les avoir en un? Je préfère s'attendre à ce que ce soit un problème si vous devez suivre les changements dans les composants qui appartiennent ensemble (par exemple, les broches d'E / S échangées doivent être reflétées dans différentes affectations de micrologiciel, et la vérification de versions incomptables entraînerait un chaos).

— leftaroundabout

@leftaroundabout Tout d'abord, gonfler votre référentiel FW à évolution rapide avec la masse d'une conception CAO complexe n'est pas toujours ce que vous voulez, mais vous pouvez également vouloir relire les bits sur les sous-référentiels et les liens entre eux. Pas du tout difficile à faire avec Git et cela résout exactement ce problème sans provoquer toutes sortes d'intimité inappropriée entre les plans de conception.

— Asmyldof

"Mes clients ne pensent pas tous que Dropbox est suffisamment sûr" Pour les fichiers de version, ils ont raison à 100%. C'est particulièrement dangereux si plusieurs utilisateurs peuvent modifier des fichiers en même temps, et plus encore si vous avez plusieurs fichiers qui constituent vraiment une seule ressource. J'ai vu des "ensembles de fichiers" binaires se corrompre de cette façon (géodatabases fichier ESRI, si vous êtes curieux).

— jpmc26

@ jpmc26 C'était un commentaire précipité, le versioning de tout a commencé plus comme un aspect de sécurité. Avec quelques modèles GitIgnore intelligents, le versioning enveloppe désormais facilement tout sans tracas, avec tous les avantages qu'il apporte. En fait, je suis entièrement d'accord avec vous sur Dropbox partagée. Sur un site client, cela provoque des problèmes sans fin. Les fichiers en cours de développement engendrent des copies conflictuelles sans fin sur les ordinateurs désactivés pendant que certaines parties du développement sont parmi les plus ennuyeuses.

— Asmyldof

@leftaroundabout: Cela dépend de la relation entre le matériel et le firmware. Prenons une analogie avec les projets logiciels normaux. Souhaitez-vous engager des fichiers gif et jpg avec votre site Web? Dans ce cas, le binaire et la source changent l'un avec l'autre même si les images ne changent pas aussi souvent. Mais .. voulez-vous valider le code source Apache ou Nginx avec votre projet. D'ailleurs, voulez-vous valider le code source du noyau Linux? Dans ce cas, Apache ou Nginx et le noyau Linux sont plus analogues au matériel - ils changent mais indépendamment du code que vous écrivez qui s'exécute sur eux

— slebetman

1) Cela vaut vraiment la peine de versionner les fichiers schématiques / cartes. Même si vous ne pouvez pas suivre les différences si facilement, vous avez un moyen propre de revenir à une version matérielle spécifique si vous devez travailler avec une ancienne révision de périphérique.

2) Nous avons la structure suivante dans notre SVN.
/ tag
/ branche
/ trunk / hardware
/ trunk / software / firmware

Si applicable avec plus de sous-dossiers comme peut-être / Firmware et / ConfigTool pour le logiciel et / mainboard et / filleboard ou quelque chose comme ça pour le matériel.

2) Les balises sont créées à partir de sous-dossiers et non de l'ensemble du tronc, comme Tag / Mainboard-v1.2.345. Le matériel (à savoir le PCB) contient toujours la révision SVN dans la sérigraphie ou en cuivre pour avoir une référence directe.

4) Les dépendances entre le matériel et le micrologiciel peuvent être complexes. OMI, cela n'a pas beaucoup de sens de le traiter au niveau du référentiel, sauf en laissant des commentaires utiles sur les commits.
Envisagez de coder les modifications matérielles à l'aide de broches d'E / S de rechange. Quelque chose comme l'utilisation de 4 broches pour coder 16 versions matérielles différentes. Nous avons également utilisé une seule entrée ADC avec différentes valeurs de résistance pour coder les versions. De cette façon, le logiciel peut «savoir» sur quel matériel il s'exécute et modifier / désactiver / activer des fonctionnalités spécifiques.

— Rev1.0
source

Je suis d'accord. J'ai également vu une bonne pratique de construction d'un "ensemble de versions" - schémas, nomenclature, gerbers, le tout - à l'occasion de chaque version en production. Vous les appelez A, B, C, etc., puis les archivez quelque part où l'équipe peut s'y référer. N'oubliez pas non plus certains moyens de suivre les mods de câblage que vous avez effectués sur quelles cartes prototypes.

— pjc50

@ pjc50: En fait, nous "construisons" également des bundles de versions, mais hors du contrôle des sources (mais avec une référence de révision). Ce sera essentiellement une copie exacte de tout ce que le fabricant a obtenu. Si vous faites du développement matériel de manière professionnelle avec une production à haut volume, il est très important d'avoir toutes les informations facilement disponibles en cas de problème. Si vous ne vous souvenez pas si vous envoyez au conseil d'administration "ce seul document important" qui spécifie peut-être l'épaisseur de cuivre PCB personnalisée, vous pouvez avoir des problèmes.

— Rev1.0