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?
Odpowiedzi:
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.
źródło
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.
źródło