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

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

Для исходного кода я бы определенно использовал Git. Но стоит ли создавать версии, если они на самом деле являются двоичными файлами (в новых версиях Eagle используется какой-то формат XML, но он не так удобен для чтения человеком ...)?
Хорошая идея поместить источники и схемы в один Git-репозиторий? Это имело бы смысл, но с другой стороны, мой журнал будет содержать как программные, так и аппаратные изменения. Также программное обеспечение может иметь несколько ветвей, но аппаратное обеспечение, вероятно, не ...
Как бороться с аппаратными ревизиями? Отметить их или сохранить в отдельных каталогах?
Также могут быть некоторые зависимости между версией аппаратного обеспечения и версией прошивки. Как с ними бороться?

Не могли бы вы поделиться своими лучшими практиками со мной?

eagle hardware c++ klasyc
источник

Будет ли работать коммерческое решение?

Евгений Ш.

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

pjc50

Какой бы версионной программой вы ни пользовались, убедитесь, что она заменяет весь файл, когда имеет дело со схемами, а не смотрит на текст. У меня была такая проблема в прошлом. Вы никогда не захотите делать различие для большинства файлов схемы.

напряжения

Ответы:

Большая часть этого сводится к личным предпочтениям.

Я отслеживаю все, что я делаю для проекта в Git. Тем более, что Git обрабатывает большинство типов файлов, даже двоичных, достаточно эффективно. (Взамен встроенной ерунды Altium SVN)

Одна из моих главных причин сделать это заключается в том, что мои клиенты не все считают, что Dropbox достаточно безопасен, и мне нужна резервная система, к которой я могу получить доступ по всему миру, а также некоторый контекст управления версиями большинства моих действий. Поэтому я настроил частный сервер Git и зашифрованную систему резервного копирования, и это работает. Платы, схемы, код, документация, отчеты, ручные модификации, все отслеживается.

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

В Git вы также можете использовать вложенные репозитории для интеграции Прошивки в проект Hardware или наоборот, даже если они являются отдельно управляемыми репозиториями.

Для более крупных проектов я также обычно использую системы отслеживания ошибок, чтобы отслеживать проблемы и решения, опять же для HW, а также для SW, Mantis - это хорошая программа, которую можно использовать бесплатно.

Для аппаратных ревизий, которые я генерирую Gerbers, или что там у вас, помеченные Git Hash для этой ревизии, эти Gerbers являются единственными дискретными «старомодными» версиями в папках по R01, 02 и т. Д. Так как вы не хотите обновляйте их все время, но они являются результирующими файлами, поэтому не следует создавать версии в самом Git (потому что ваше программное обеспечение для разработки должно быть детерминированным при создании производственного контента, или иначе ...).

Если в R01 есть что-то интересное, чего нет в R02 (или наоборот), у вас есть два Git-хэша, с которыми вы можете сравнивать исходные файлы, не беспокойтесь.

В заключение, один концептуальный пример проекта будет иметь аппаратный репозиторий, который также содержит файл «BoardPinout.h». Этот файл включен в качестве файла с удаленной версией в хранилище прошивки, в котором есть несколько файлов определения интерфейса, которые удаленно включаются в хранилище программного обеспечения.

То есть каждый раз, когда я изменяю несколько сигналов без изменения широкого функционала, проект HW «обновляет» BoardPinout, который затем можно обновлять и использовать в прошивке и так далее.

Asmyldof
источник

Действительно ли это когда - либо имеет смысл поставить оборудование и микропрограммное обеспечение в различных РЕПО? Как было бы проблемой иметь их в одном? Я предпочел бы ожидать, что это будет проблемой, если вам нужно отслеживать изменения в компонентах, которые принадлежат друг другу (например, поменявшиеся выводы ввода-вывода должны отражаться в разных назначениях встроенного ПО, а проверка несовместимых версий может привести к беспорядкам).

оставил около

@leftaroundabout Прежде всего, раздувание вашего быстро меняющегося репозитория FW основной частью сложной конструкции САПР - это не всегда то, что вам нужно, но вы также можете перечитать информацию о суб-репо и связи между ними. В Git нет ничего сложного, и это решает именно эту проблему, не вызывая всевозможной неуместной близости между проектами.

Asmyldof

«Мои клиенты не все считают, что Dropbox достаточно безопасен». Для версий файлов они на 100% правы. Это особенно опасно, если несколько пользователей могут изменять файлы одновременно, и даже более того, если у вас есть несколько файлов, которые действительно составляют один ресурс. Я видел, как двоичные «наборы файлов» были повреждены таким образом (файловые базы геоданных ESRI, если вам интересно).

jpmc26

@ jpmc26 Это был поспешный комментарий, управление версиями изначально начиналось скорее с точки зрения безопасности. Благодаря нескольким продуманным версиям шаблонов GitIgnore теперь можно легко обернуть все без лишних хлопот со всеми преимуществами, которые оно приносит. Я на самом деле полностью согласен с вами в общедоступном Dropbox. На одном сайте клиента это вызывает бесконечные проблемы. Разрабатываемые файлы, порождающие бесконечные конфликтующие копии на компьютерах, отключаются, когда части dev являются одними из самых раздражающих.

Asmyldof

@leftaroundabout: Это зависит от отношений между оборудованием и прошивкой. Давайте возьмем аналогию с обычными программными проектами. Будете ли вы передавать файлы GIF и JPG вместе с вашим сайтом? В этом случае двоичный файл и исходный код меняются друг с другом, даже если изображения меняются не так часто. Но ... вы бы добавили исходный код Apache или Nginx в свой проект. В связи с этим, вы бы передали исходный код ядра Linux? В этом случае Apache или Nginx и ядро Linux более похожи на аппаратное обеспечение - они изменяются, но независимо от кода, который вы пишете на них,

slebetman

1) Это определенно стоит версий файлов схемы / платы. Даже если вы не можете так легко отследить различия, у вас есть чистый способ вернуться к определенной версии оборудования, если вам приходится работать со старой версией устройства.

2) У нас есть следующая структура в нашем SVN.
/ tag
/ ветка
/ trunk / hardware
/ trunk / software / firmware

Если применимо, с большим количеством подпапок, таких как, возможно, / Firmware и / ConfigTool для программного обеспечения и / mainboard и / дочерняя плата или что-то подобное для аппаратного обеспечения.

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

4) Зависимости между оборудованием и прошивкой могут быть сложными. ИМО, не имеет особого смысла иметь дело с этим на уровне хранилища, кроме как оставлять полезные комментарии по коммитам.
Рассмотрим изменения аппаратного кодирования с помощью запасных выводов ввода / вывода. Что-то вроде использования 4-х контактов для кодирования 16 различных версий оборудования. Мы также использовали один вход АЦП с различными значениями сопротивления для кодирования версий. Таким образом, программа может «знать», на каком оборудовании оно работает, и изменять / отключать / включать определенные функции.

rev1.0
источник

Согласен. Я также видел хорошую практику создания «комплекта релизов» - схемы, спецификации, герберы, вся партия - по случаю каждого выпуска в производство. Вы называете их A, B, C и т. Д., А затем архивируете их где-нибудь, где команда может обратиться к ним. Кроме того, не забудьте некоторые средства отслеживания того, какие проводные моды вы делали на каких платах прототипов.

pjc50

@ pjc50: На самом деле мы также "собираем" релизы, но без контроля версий (но со ссылкой на ревизию). По сути это будет точная копия всего, что получил производитель. Если вы профессионально занимаетесь разработкой аппаратного обеспечения с большим объемом производства, очень важно иметь всю доступную информацию на случай, если что-то пойдет не так. Если вы не помните, отправляете ли вы в совет директоров «этот важный документ», в котором, возможно, указана толщина медной печатной платы, вы можете столкнуться с проблемами.

1.0