Controllo della versione di schemi e codice sorgente

Sto sviluppando un dispositivo elettronico che ha due parti: hardware (schemi di Eagle) e firmware (codice sorgente C ++). Vorrei tenere traccia delle modifiche sia nel codice sorgente che negli schemi, ma ci sono alcuni punti in cui non sono sicuro di come organizzare il mio lavoro:

Per il codice sorgente utilizzerei sicuramente Git. Ma gli schemi valgono la versione quando sono in realtà file binari (le nuove versioni di Eagle usano un formato XML, ma non è così leggibile dall'uomo ...)?
È una buona idea mettere fonti e schemi in un repository Git? Avrebbe senso, ma d'altra parte il mio registro conterrebbe sia le modifiche software che hardware. Inoltre il software può avere diversi rami, ma probabilmente l'hardware non ...
Come gestire le revisioni hardware? Taggarli o salvarli in directory separate?
Inoltre, potrebbero esserci alcune dipendenze tra la revisione dell'hardware e la versione del firmware. Come gestirli?

Potresti condividere le tue migliori pratiche con me?

eagle hardware c++

— klasyc
fonte

Una soluzione commerciale funzionerebbe?

— Eugene Sh.

Non toccherei mai più un sistema di controllo della versione commerciale. La mia esperienza con questi è terribili flussi di lavoro che sono molto più difficili da usare rispetto a svn o persino git.

— pjc50,

Qualunque sia il software di controllo delle versioni che usi, assicurati che sostituisca l'intero file quando gestisci gli schemi e non guardi il testo. Ho avuto questo problema in passato. Non vorrai mai fare una diff sulla maggior parte dei file schematici.

— Picco di tensione

Risposte:

La maggior parte dipende dalle preferenze personali.

Traccio tutto ciò che faccio per un progetto in Git. Soprattutto dal momento che Git gestisce la maggior parte dei tipi di file, anche binari, in modo sufficientemente efficiente. (Al posto del nonsense Altium SVN incorporato)

Uno dei miei principali motivi per farlo è che i miei clienti non pensano tutti che Dropbox sia abbastanza sicuro e ho bisogno di un sistema di backup a cui posso accedere in tutto il mondo, con anche un po 'di contesto di versione sulla maggior parte di ciò che faccio. Quindi ho impostato un server Git privato e un sistema di backup crittografato e funziona a meraviglia. Schede, schemi, codice, documentazione, rapporti, modifiche manuali, tutto è tracciato.

Normalmente creerei un repository per hardware, uno per software e uno per firmware se si tratta di un progetto di grandi dimensioni, potenzialmente di lunga durata, ma per progetti di servizi di piccole dimensioni, esempi o piccoli esperimenti spesso inserisco tutto in un repository, poiché il risultato il caos non sarà grande.

In Git è possibile utilizzare anche repository per integrare il firmware nel progetto Hardware o viceversa, anche se sono repository gestiti separatamente.

Per i progetti più grandi uso comunemente anche i sistemi di tracciamento dei bug per tenere traccia di problemi e risoluzioni, sempre per HW e SW, Mantis è uno che può essere utilizzato gratuitamente.

Per le revisioni hardware che ho generato Gerbers, o qualsiasi altra cosa tu abbia, etichettato con Git Hash per quella revisione, quei Gerbers sono quindi le uniche cose discrete "vecchio stile" nelle cartelle di R01, 02, ecc. Dato che non vuoi rigenerarli continuamente, ma sono file risultanti, quindi non dovrebbero essere sottoposti a versione in Git stesso, in realtà (perché il software di progettazione dovrebbe essere deterministico con la generazione di contenuti di produzione, oppure ...).

Se c'è qualcosa di interessante in R01 che non sta accadendo in R02 (o viceversa), hai due Git Hash con cui puoi confrontare i file di origine, senza preoccupazioni.

Come nota finale, un esempio concettuale di un progetto avrebbe un repository Hardware, che ospita anche un file "BoardPinout.h". Questo file è incluso come file con versione remota nel repository Firmware, che ha alcuni file di definizione dell'interfaccia che vengono inclusi in remoto nel repository Software.

Significa che ogni volta che cambio alcuni segnali senza modificare un'ampia funzionalità, il progetto HW "aggiorna" BoardPinout, che può quindi essere aggiornato e utilizzato in Firmware e così via.

— Asmyldof
fonte

E 'davvero mai senso mettere hardware e firmware in diversi pronti contro termine? Come sarebbe un problema averli in uno? Preferirei che fosse un problema se fosse necessario tenere traccia delle modifiche nei componenti che si uniscono (ad esempio, i pin IO cambiati devono riflettersi in diverse assegnazioni del firmware e il controllo di versioni incomplete porterebbe al caos).

— circa il

@leftaroundabout Innanzitutto, gonfiare il repository FW in rapida evoluzione con la maggior parte di un progetto CAD complesso non è sempre quello che desideri, ma potresti anche rileggere i bit relativi ai repository e al collegamento tra di essi. Non è affatto difficile avere a che fare con Git e questo risolve esattamente quel problema senza causare ogni tipo di intimità inappropriata tra i tratti del design.

— Asmyldof,

"I miei clienti non pensano tutti che Dropbox sia abbastanza sicuro" Per i file di controllo delle versioni, hanno ragione al 100%. È particolarmente pericoloso se più utenti possono modificare i file contemporaneamente, e ancora di più se si dispone di più file che comprendono realmente una singola risorsa. Ho visto "set di file" binari corrompere in questo modo (geodatabase di file ESRI, se sei curioso).

— jpmc26,

@ jpmc26 Questo è stato un commento affrettato, il controllo delle versioni è iniziato inizialmente più come un aspetto di sicurezza. Con alcuni modelli intelligenti di GitIgnore, il controllo delle versioni ora avvolge facilmente tutto senza problemi, con tutti i vantaggi che offre. In realtà sono pienamente d'accordo con te su Dropbox condiviso. In un sito cliente provoca problemi senza fine. I file in fase di sviluppo generano infinite copie in conflitto sui computer spenti durante le fasi di sviluppo di una delle più fastidiose.

— Asmyldof,

@leftaroundabout: dipende dalla relazione tra hardware e firmware. Facciamo un'analogia con i normali progetti software. Impegneresti file gif e jpg insieme al tuo sito web? In questo caso sia il binario che l'origine cambiano l'uno con l'altro anche se le immagini non cambiano spesso. Ma .. vorresti impegnare il codice sorgente Apache o Nginx con il tuo progetto. Del resto, vorresti impegnare il codice sorgente del kernel Linux? In questo caso Apache o Nginx e il kernel Linux sono più analoghi all'hardware - cambiano ma indipendentemente dal codice che scrivi su di loro

— slebetman

1) Vale sicuramente la pena revisionare i file schematici / board. Anche se non riesci a tenere traccia delle differenze così facilmente, hai un modo chiaro per ripristinare una versione hardware specifica se devi lavorare con una vecchia versione del dispositivo.

2) Abbiamo la seguente struttura nel nostro SVN.
/ tag
/ branch
/ trunk / hardware
/ trunk / software / firmware

Se applicabile con più sottocartelle come forse / Firmware e / ConfigTool per software e / scheda madre e / scheda figlia o qualcosa del genere per l'hardware.

2) I tag vengono creati da sottocartelle non dall'intero trunk, come Tag / Mainboard-v1.2.345. L'hardware (vale a dire il PCB) contiene sempre la revisione SVN nella serigrafia o in rame per avere un riferimento diretto.

4) Le dipendenze tra hardware e firmware possono essere complesse. IMO non ha molto senso affrontarlo a livello di repository se non lasciare commenti utili sugli commit.
Valuta la possibilità di codificare le modifiche hardware utilizzando pin I / O di riserva. Qualcosa come usare 4 pin per codificare 16 diverse versioni hardware. Abbiamo anche usato un singolo ingresso ADC con diversi valori di resistenza per codificare le versioni. In questo modo il software può "sapere" su quale hardware viene eseguito e modificare / disabilitare / abilitare funzionalità specifiche.

— Rev1.0
fonte

Sono d'accordo. Ho anche visto una buona pratica di costruzione di un "bundle di release" - schemi, DBA, gerber, l'intero lotto - in occasione di ogni rilascio alla produzione. Chiamate queste A, B, C ecc. E poi le archiviate da qualche parte dove il team può fare riferimento a loro. Inoltre, non dimenticare alcuni mezzi per tracciare quali mod di filo hai fatto su quali schede prototipo.

— pjc50,

@ pjc50: In realtà "creiamo" anche bundle di rilascio, ma fuori dal controllo del codice sorgente (ma con un riferimento di revisione). Essenzialmente sarà una copia esatta di tutto ciò che il produttore ha ottenuto. Se si esegue lo sviluppo hardware in modo professionale con produzione ad alto volume, è molto importante avere tutte le informazioni prontamente disponibili nel caso in cui qualcosa vada storto. Se non ricordi se invii alla scheda "questo importante documento" che forse specifica lo spessore del rame PCB personalizzato, potresti avere dei problemi.

— Rev.1.0