Kontrola wersji schematów i kodu źródłowego


12

Zajmuję się tworzeniem urządzenia elektronicznego, które składa się z dwóch części: sprzętu (schematy Eagle) i oprogramowania układowego (kod źródłowy C ++). Chciałbym śledzić zmiany zarówno w kodzie źródłowym, jak i schematach, ale są pewne punkty, w których nie jestem pewien, jak zorganizować swoją pracę:

  • W przypadku kodu źródłowego zdecydowanie użyłbym Git. Ale czy schematy są warte wersjonowania, gdy w rzeczywistości są plikami binarnymi (nowe wersje Eagle używają jakiegoś formatu XML, ale nie są tak czytelne dla człowieka ...)?

  • Czy warto umieścić źródła i schematy w jednym repozytorium Git? To miałoby sens, ale z drugiej strony mój dziennik zawierałby zarówno zmiany oprogramowania, jak i sprzętu. Oprogramowanie może również mieć kilka oddziałów, ale sprzęt prawdopodobnie nie ...

  • Jak radzić sobie z wersjami sprzętowymi? Oznacz je lub zapisz w osobnych katalogach?

  • Mogą również występować pewne zależności między wersją sprzętową a wersją oprogramowania układowego. Jak sobie z nimi radzić?

Czy możesz podzielić się ze mną swoimi najlepszymi praktykami?


Czy rozwiązanie komercyjne zadziałałoby?
Eugene Sh.

5
Nigdy więcej nie dotknęłbym komercyjnego systemu kontroli wersji. Moje doświadczenie z nimi to straszne przepływy pracy, które są znacznie trudniejsze w użyciu niż svn, a nawet git.
pjc50

Bez względu na to, jakiego oprogramowania do wersjonowania używasz, upewnij się, że zastępuje on cały plik, gdy masz do czynienia ze schematami i nie patrzysz na tekst. W przeszłości miałem taki problem. Nigdy nie chciałbyś robić różnic w większości plików schematów.
Skok napięcia

Odpowiedzi:


19

Większość sprowadza się do osobistych preferencji.

Śledzę wszystko, co robię dla projektu w Git. Zwłaszcza, że ​​Git obsługuje wystarczająco dużo plików, nawet binarnych, z wystarczającą wydajnością. (Zamiast wbudowanych bzdur Altium SVN)

Jednym z moich głównych powodów jest to, że moi klienci nie wszyscy uważają, że Dropbox jest wystarczająco bezpieczny i potrzebuję systemu tworzenia kopii zapasowych, do którego mogę uzyskać dostęp na całym świecie, a także kontekst wersji dla większości moich działań. Więc skonfigurowałem prywatny serwer Git i zaszyfrowany system tworzenia kopii zapasowych i działa to uczta. Tablice, Schematy, Kod, Dokumentacja, Raporty, Ręczne modyfikacje, wszystko jest śledzone.

Zwykle tworzyłbym repozytorium dla sprzętu, jeden dla oprogramowania i jeden dla oprogramowania układowego, jeśli jest to duży, potencjalnie długotrwały projekt, ale dla małych projektów usługowych, przykładów lub małych eksperymentów często umieszczam to wszystko w jednym repozytorium, ponieważ wynikowe chaos nie będzie duży.

W Git możesz także używać sub-repozytoriów, aby zintegrować oprogramowanie układowe z projektem Hardware lub odwrotnie, nawet jeśli są to osobno zarządzane repozytoria.

W większych projektach często używam również systemów śledzenia błędów, aby śledzić problemy i rozwiązania, ponownie, zarówno dla HW, jak i SW, Mantis jest fajny, z którego można korzystać za darmo.

W przypadku poprawek sprzętowych generuję Gerbera lub cokolwiek innego, oznaczonego tagiem Git Hash dla tej wersji, te Gerbery są wówczas jedynymi dyskretnymi „staroświeckimi” wersjami w folderach według R01, 02 itd. Ponieważ nie chcesz generuj je cały czas, ale są to pliki wynikowe, więc nie powinno być wersjonowane w samym Git, naprawdę (ponieważ twoje oprogramowanie do projektowania powinno być deterministyczne przy generowaniu zawartości produkcyjnej, bo inaczej ...).

Jeśli w R01 jest coś interesującego, co nie dzieje się w R02 (lub na odwrót), masz dwa Git Hashe, z którymi możesz porównywać pliki źródłowe, nie martw się.

Na koniec, jednym koncepcyjnym przykładem projektu, byłoby repozytorium sprzętu, które również zawiera plik „BoardPinout.h”. Ten plik jest dołączany jako plik z wersją zdalną do repozytorium oprogramowania układowego, który zawiera kilka plików definicji interfejsu, które są zdalnie dołączane do repozytorium oprogramowania.

Oznacza to, że za każdym razem, gdy zmieniam kilka sygnałów bez modyfikowania szerokiej funkcjonalności, projekt HW „aktualizuje” BoardPinout, który następnie może być aktualizowany i używany w oprogramowaniu sprzętowym i tak dalej.


1
Czy to naprawdę kiedykolwiek sensu wkładać sprzętu i oprogramowania w różnych repo? Jak byłoby problem mieć je w jednym? Wolę oczekiwać, że będzie to problem, jeśli będziesz musiał śledzić zmiany w komponentach, które należą do siebie (np. Zamienione piny IO muszą zostać odzwierciedlone w różnych przypisaniach oprogramowania układowego, a sprawdzenie niekompatybilnych wersji doprowadziłoby do chaosu).
leftaroundabout

@leftaroundabout Po pierwsze, nadmuchiwanie szybko zmieniającego się repozytorium FW dużą ilością złożonego projektu CAD nie zawsze jest tym, czego chcesz, ale możesz także chcieć ponownie przeczytać fragmenty dotyczące sub-repo i powiązań między nimi. Z Git wcale nie jest to trudne, a to rozwiązuje dokładnie ten problem bez powodowania wszelkiego rodzaju niewłaściwej intymności między traktami projektowymi.
Asmyldof

1
„moi klienci nie wszyscy uważają, że Dropbox jest wystarczająco bezpieczny” W przypadku wersji plików mają 100% rację. Jest to szczególnie niebezpieczne, gdy wielu użytkowników może modyfikować pliki w tym samym czasie, a tym bardziej, jeśli masz kilka plików, które naprawdę stanowią jeden zasób. Widziałem, jak binarne „zestawy plików” ulegają w ten sposób uszkodzeniu (geobazy danych ESRI, jeśli jesteś ciekawy).
jpmc26

1
@ jpmc26 To był pochopny komentarz, wersjonowanie wszystkiego zaczęło się początkowo bardziej ze względów bezpieczeństwa. Dzięki kilku sprytnym szablonom wersjonowanie szablonów GitIgnore pozwala teraz bez problemu owijać wszystko i wszystkie zalety, jakie przynosi. Właściwie w pełni się z tobą zgadzam w sprawie udostępnionego Dropbox. W jednej witrynie klienta powoduje to niekończące się problemy. Pliki w trakcie tworzenia spawnują nieskończoną liczbę konfliktowych kopii na komputerach, które zostały wyłączone w czasie, gdy część deweloperów była jedną z najbardziej irytujących.
Asmyldof

@leftaroundabout: Zależy to od relacji między sprzętem a oprogramowaniem układowym. Weźmy analogię do normalnych projektów oprogramowania. Czy zgodziłbyś się na pliki gif i jpg wraz ze swoją witryną? W tym przypadku zarówno plik binarny, jak i źródło zmieniają się ze sobą, nawet jeśli obrazy nie zmieniają się tak często. Ale ... czy mógłbyś zatwierdzić kod źródłowy Apache lub Nginx w swoim projekcie. Jeśli tak, to czy zatwierdziłbyś kod źródłowy jądra Linux? W tym przypadku Apache lub Nginx i jądro Linuksa są bardziej analogiczne do sprzętu - zmieniają się, ale niezależnie od kodu, który na nich
piszesz

5

1) Zdecydowanie warto wersjonować pliki schematów / płyt. Nawet jeśli nie możesz tak łatwo śledzić różnic, masz czysty sposób na powrót do konkretnej wersji sprzętowej, jeśli musisz pracować ze starszą wersją urządzenia.

2) W naszej SVN mamy następującą strukturę.
/ tag
/ branch
/ trunk / hardware
/ trunk / software / firmware

Jeśli dotyczy, z większą liczbą podfolderów, takich jak może / Firmware i / ConfigTool dla oprogramowania i / mainboard i / daughterboard lub coś takiego dla sprzętu.

2) Tagi są tworzone z podfolderów, a nie z całego pnia, jak Tag / Mainboard-v1.2.345. Sprzęt (czyli PCB) zawsze zawiera wersję SVN na sitodruku lub w miedzi, aby mieć bezpośrednie odniesienie.

4) Zależności między sprzętem a oprogramowaniem układowym mogą być złożone. IMO nie ma większego sensu zajmowanie się nim na poziomie repozytorium, z wyjątkiem pozostawienia przydatnych komentarzy na temat zatwierdzeń.
Rozważ kodowanie zmian sprzętowych przy użyciu zapasowych styków we / wy. Coś jak użycie 4 pinów do zakodowania 16 różnych wersji sprzętowych. Do kodowania wersji wykorzystaliśmy również pojedyncze wejście ADC o różnych wartościach rezystancji. W ten sposób oprogramowanie może „wiedzieć” na jakim sprzęcie działa i zmieniać / wyłączać / włączać określone funkcje.


Zgadzam się. Widziałem też dobrą praktykę budowania „pakietu wydań” - schematów, BOM, gerbera, całej partii - przy okazji każdego wydania do produkcji. Nazywasz je A, B, C itp., A następnie archiwizujesz je w miejscu, do którego zespół może się odnieść. Nie zapomnij także o niektórych sposobach śledzenia, jakie modyfikacje drutów wykonałeś na jakich prototypowych płytkach.
pjc50

@ pjc50: Właściwie również „budujemy” pakiety wydań, ale poza kontrolą źródła (ale z odniesieniem do wersji). Zasadniczo będzie to dokładna kopia wszystkiego, co otrzymał producent. Jeśli profesjonalnie zajmujesz się projektowaniem sprzętu i produkcją na dużą skalę, bardzo ważne jest, aby wszystkie informacje były łatwo dostępne na wypadek, gdyby coś poszło nie tak. Jeśli nie pamiętasz, jeśli wyślesz do domu zarządu „ten jeden ważny dokument”, który może określać niestandardową grubość miedzi na płytce drukowanej, możesz mieć kłopoty.
Rev1.0
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.