Контроль версій схеми та вихідного коду


12

Я розробляю електронний пристрій, який має дві частини: апаратну (схему Eagle) та прошивку (вихідний код C ++). Я хотів би відслідковувати зміни як у вихідному коді, так і в схемах, але є деякі моменти, де я не впевнений, як організувати свою роботу:

  • Для вихідного коду я б точно використовував Git. Але чи варто схематизувати версію, коли вони насправді є бінарними файлами (нові версії Eagle використовують якийсь формат XML, але це не так читабельно для людини ...)?

  • Чи добре розміщувати джерела та схеми в одному сховищі Git? Це було б сенсом, але з іншого боку, мій журнал містив би як зміни програмного забезпечення, так і апаратного забезпечення. Також програмне забезпечення може мати декілька галузей, але апаратне забезпечення, мабуть, немає ...

  • Як боротися з апаратними переглядами? Позначте їх або збережіть в окремих каталогах?

  • Також можуть бути деякі залежності між версією апаратного забезпечення та версією прошивки. Як з ними боротися?

Не могли б ви поділитися зі мною своїми найкращими практиками?


Чи працювало б комерційне рішення?
Євген Ш.

5
Я б більше не торкався системи управління комерційною версією. Мій досвід щодо них - це жахливі робочі процеси, які набагато складніше використовувати, ніж svn або навіть git.
pjc50

Незалежно від версії програмного забезпечення, яке ви використовуєте, переконайтесь, що воно замінює весь файл під час роботи зі схемами та не дивлячись на текст. У мене раніше це було проблемою. Ви ніколи не хочете робити різницю для більшості схемних файлів.
Спайк напруги

Відповіді:


19

Більшість це зводиться до особистих уподобань.

Я відслідковую все, що роблю для проекту в Git. Тим більше, що Git обробляє більшість типів файлів, навіть бінарних, досить ефективно. (Замість вбудованої дурниці Altium SVN)

Однією з моїх головних причин цього є те, що всі мої клієнти не вважають, що Dropbox є достатньо безпечним, і мені потрібна резервна система, до якої я можу отримати доступ по всьому світу, а також деякий контекст версій щодо більшості того, що я роблю. Тож я створив приватний сервер Git і зашифровану систему резервного копіювання, і це спрацює приємно. Дошки, схеми, код, документація, звіти, ручні зміни, все відстежується.

Я б зазвичай створив сховище для апаратного забезпечення, одне для програмного забезпечення та одне для прошивки, якщо це великий, потенційно тривалий проект, але для невеликих сервісних проектів, прикладів або невеликих експериментів я часто розміщую все це в одному сховищі, оскільки результат хаос не буде великим.

У Git ви можете використовувати підрепозиторії, а також для інтеграції вбудованого програмного забезпечення в проект апаратного забезпечення або навпаки, навіть якщо це окремо керовані сховища.

Для великих проектів я також часто використовую системи відстеження помилок, щоб відстежувати проблеми та рішення, знову ж таки для HW, а також SW, Mantis - це приємний, який можна використовувати безкоштовно.

Для апаратних версій я генерую Gerbers, або будь-який інший ви, позначений Git Hash для цієї редакції, ці Gerbers тоді є єдиними дискретними "старомодними" версіями в папках на R01, 02 тощо. Оскільки ви не хочете регенеруйте їх весь час, але вони отримують файли, тому насправді не слід впорядковувати у самій Git (адже ваше програмне забезпечення для дизайну повинно бути детермінованим із створенням виробничого контенту чи ще ...).

Якщо в R01 є щось цікаве, що не відбувається в R02 (або навпаки), у вас є два Git хеші, з якими ви можете порівнювати вихідні файли, без побоювань.

На завершення, один концептуальний приклад проекту мав би сховище апаратури, яке також розміщує файл "BoardPinout.h". Цей файл включений як файл з віддаленою версією у сховище прошивки, який має декілька файлів визначення інтерфейсу, які віддалено включаються у сховище програмного забезпечення.

Що означає щоразу, коли я змінюю декілька сигналів, не змінюючи широкої функціональності, проект HW "оновлює" BoardPinout, який потім може бути оновлений і використаний у прошивці тощо.


1
Чи насправді коли-небудь має сенс розміщувати апаратне забезпечення та прошивку в різних репозиціях? Як було б проблемою мати їх в одному? Я б швидше очікував, що це буде проблемою, якщо вам потрібно буде відслідковувати зміни компонентів, що належать разом (наприклад, поміняні штифти вводу-виводу повинні бути відображені в різних призначеннях вбудованого програмного забезпечення, а перевірка некомплектних версій призведе до хаосу).
близько

@leftaroundabout Перш за все, надуваючи швидко змінюється репортаж FW великою частиною складної конструкції CAD - це не завжди те, що ви хочете, але ви також можете перечитати біти про повторну репост і зв'язок між ними. Це зовсім не складно з Git, і це вирішує саме цю проблему, не викликаючи всілякої невідповідної близькості між дизайнерськими трактами.
Асмільдоф

1
"Мої клієнти не всі вважають, що Dropbox достатньо безпечний". Для файлів версій вони мають 100% рацію. Особливо небезпечно, якщо кілька користувачів можуть змінювати файли одночасно, і навіть більше, якщо у вас є кілька файлів, які дійсно містять один ресурс. Я бачив, як двійкові "набори файлів" пошкоджуються таким чином (бази даних геодезичних файлів ESRI, якщо вам цікаво).
jpmc26

1
@ jpmc26 Це був бурхливий коментар, але все почалося з версії, як аспект безпеки. За допомогою декількох розумних шаблонів GitIgnore версія тепер легко охоплює все без клопоту, з усіма перевагами, які він приносить. Я фактично повністю згоден з вами щодо спільного Dropbox. На одному сайті клієнта це викликає нескінченні проблеми. Файли, що знаходяться в стадії розробки, створюють нескінченні конфліктні копії на комп’ютерах, вимкнені під час роботи розробників, які є одними з найбільш дратівливих.
Асмільдоф

@leftaroundabout: Це залежить від взаємозв'язку між апаратним і програмним забезпеченням. Візьмемо аналогію із звичайними програмними проектами. Чи можете ви створювати файли gif та jpg разом із своїм веб-сайтом? У цьому випадку і двійкові, і джерела змінюються один з одним, навіть якщо зображення не змінюються так часто. Але .. чи дозволите ви скористатися вихідним кодом Apache або Nginx зі своїм проектом. З цього приводу ви б зв'язали вихідний код ядра Linux? У цьому випадку Apache або Nginx та ядро ​​Linux є більш аналогічними апаратному - вони змінюються, але незалежно від
написаного

5

1) Це, безумовно, варто модифікувати схематичні / дошки файлів. Навіть якщо ви не можете відстежувати відмінності так легко, у вас є чистий спосіб повернутися до певної версії обладнання, якщо вам доведеться працювати зі старою версією пристрою.

2) У нашому SVN є така структура.
/ тег
/ гілка
/ магістраль / апаратне забезпечення
/ магістраль / програмне забезпечення / прошивка

Якщо застосуємо з більшою кількістю папок, наприклад, / Прошивка та / ConfigTool для програмного забезпечення та / материнської плати та / дощової плати або щось подібне до обладнання.

2) Теги створюються з підпапок, а не з усієї магістралі, як-от Tag / Mainboard-v1.2.345. Апаратне забезпечення (а саме друкована плата) завжди містить редакцію SVN у шовковому екрані або у міді, щоб мати пряме посилання.

4) Залежності між апаратними та програмними засобами можуть бути складними. IMO не має такого сенсу займатися цим на рівні сховища, за винятком корисних коментарів до комітетів.
Подумайте про кодування апаратних змін за допомогою запасних штифтів вводу / виводу. Щось на зразок використання 4-контактних штифтів для кодування 16 різних апаратних версій. Ми також використовували один вхід АЦП з різними значеннями опору для кодування версій. Таким чином програмне забезпечення може "знати" про те, яке апаратне забезпечення воно працює, і змінювати / відключати / включати конкретні функції.


Я згоден. Я також бачив хорошу практику побудови "випускного пакета" - схеми, BOM, гербер, цілу партію - з нагоди кожного виходу у виробництво. Ви викликаєте ці A, B, C тощо, а потім архівуєте їх десь там, де команда може посилатися на них. Крім того, не забувайте про деякі способи відстеження, які провідники ви робили на яких прототипах плат.
pjc50

@ pjc50: Насправді ми також "будуємо" версії випусків, але поза контролем джерела (але з посиланням на перегляд). По суті це буде точна копія всього, що отримав виробник. Якщо ви професійно розробляєте обладнання з високим обсягом виробництва, дуже важливо мати всю інформацію, доступну у випадку, якщо щось піде не так. Якщо ви не пам’ятаєте, чи надсилаєте ви дошці будинку «цей важливий документ», який, можливо, вказує на власну товщину міді на друкованій платі, ви можете потрапити в біду.
Rev1.0
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.