Şemaların ve kaynak kodunun sürüm kontrolü


12

İki bölümden oluşan bir elektronik cihaz geliştiriyorum: donanım (Eagle şemaları) ve bellenim (C ++ kaynak kodu). Hem kaynak kodu hem de şemalardaki değişiklikleri izlemek istiyorum, ancak işimi nasıl organize edeceğimden emin olmadığım bazı noktalar var:

  • Kaynak kodu için kesinlikle Git'i kullanırdım. Ancak şemalar aslında ikili dosyalar olduklarında sürümlemeye değer mi (yeni Eagle sürümleri bazı XML formatlarını kullanır, ancak insan tarafından okunabilir değildir ...)?

  • Kaynakları ve şemaları bir Git deposuna koymak iyi bir fikir mi? Bu mantıklı olurdu, ancak diğer yandan günlüğüm hem yazılım hem de donanım değişiklikleri içerecektir. Ayrıca yazılım birkaç şubesi olabilir, ancak donanım muhtemelen ...

  • Donanım revizyonlarıyla nasıl başa çıkılır? Etiketleyin veya ayrı dizinlere kaydedilsin mi?

  • Ayrıca donanım revizyonu ile bellenim sürümü arasında bazı bağımlılıklar olabilir. Onlarla nasıl başa çıkılır?

En iyi uygulamalarınızı benimle paylaşır mısınız?


Ticari bir çözüm işe yarar mı?
Eugene Sh.

5
Bir daha ticari versiyon kontrol sistemine dokunmam. Benim deneyimlerim, svn ve hatta git'ten çok daha zor olan korkunç iş akışları.
pjc50

Hangi sürümleme yazılımını kullanırsanız kullanın, şemalarla uğraşırken metne bakmadan dosyanın tamamını değiştirdiğinden emin olun. Bu geçmişte bir sorun vardı. Çoğu şematik dosyada hiçbir zaman fark yaratmak istemezsiniz.
Gerilim Spike

Yanıtlar:


19

Çoğu kişisel tercihlere bağlı.

Git'teki bir proje için yaptığım her şeyi takip ediyorum. Özellikle Git, ikili bile olsa, çoğu dosya türünü yeterince verimli bir şekilde işlediğinden. (Yerleşik Altium SVN saçmalıklarının yerine)

Bunu yapmamın temel nedenlerinden biri, müşterilerimin Dropbox'ın yeterince güvenli olduğunu hissetmemeleri ve dünya çapında erişebileceğim bir yedekleme sistemine ihtiyacım olması ve ayrıca yaptığım işlerin çoğunda bazı versiyonlama bağlamına ihtiyacım var. Bu yüzden özel bir Git sunucusu ve şifreli yedekleme sistemi kurdum ve bir tedavi çalışıyor. Panolar, Şemalar, Kod, Dokümantasyon, Raporlar, Manuel Değişiklikler, her şey takip edilir.

Normalde büyük, potansiyel olarak uzun süredir devam eden bir proje ise Donanım için bir Yazılım için ve diğeri Firmware için bir Depo oluşturacağım, ancak küçük hizmet projeleri, örnekler veya küçük deneyler için genellikle hepsini tek bir depoya koydum. kaos büyük olmayacak.

Git'te, ayrı ayrı yönetilen havuzlar olsalar bile, Donanım Yazılımını Donanım projesine veya başka bir yolla entegre etmek için alt havuzları da kullanabilirsiniz.

Daha büyük projeler için, genellikle HW ve SW için sorunları ve çözünürlükleri takip etmek için yaygın olarak hata izleme sistemleri kullanıyorum, Mantis ücretsiz olarak kullanılabilecek hoş bir sistem.

Donanım revizyonları için Gerbers'i üretiyorum, ya da her neyse, bu revizyon için Git Hash ile etiketledim, o zaman bu Gerbers, R01, 02 vb. bunları her zaman yeniden oluşturun, ancak sonuç olarak dosyalar ortaya çıkıyor, bu yüzden Git'in kendisinde sürümlendirilmemelidir, çünkü (tasarım yazılımınız üretim içeriği oluşturma konusunda deterministik olmalı, yoksa ...).

R01'de ilginç bir şey varsa, R02'de (veya başka bir şekilde) gerçekleşmeyen bir şey varsa, endişelenmeyin, kaynak dosyaları karşılaştırabileceğiniz iki Git Hash'iniz var.

Son bir not olarak, bir projenin kavramsal bir örneği, bir "BoardPinout.h" dosyasını da barındıran bir Donanım deposuna sahip olacaktır. Bu dosya, Yazılım havuzuna uzaktan eklenen birkaç arabirim tanım dosyasına sahip olan Firmware deposuna uzaktan sürümlendirilmiş bir dosya olarak eklenir.

Yani, geniş işlevselliği değiştirmeden birkaç sinyali her değiştirdiğimde, HW projesi BoardPinout'u "günceller" ve daha sonra Firmware'de güncellenebilir ve kullanılabilir.


1
Gerçekten mu hiç farklı depolarındakii donanım ve firmware koymak için mantıklı? Bunları bir arada tutmak nasıl bir sorun olurdu? Birbirine ait bileşenlerdeki değişiklikleri izlemeniz gerekiyorsa bir sorun olmasını bekliyorum (örneğin, takas IO pinlerinin farklı bellenim atamalarına yansıtılması gerekir ve uyumsuz sürümleri kontrol etmek kargaşaya neden olur).
leftaroundabout

@leftaroundabout Her şeyden önce, hızlı değişen FW repo'nuzu karmaşık bir CAD tasarımının büyük bir kısmı ile şişirmek her zaman istediğiniz şey değildir, ancak alt depolar ve aralarındaki bağlantı hakkındaki bitleri tekrar okumak isteyebilirsiniz. Git ile hiç de zor değil ve bu, tasarım yolları arasında her türlü uygunsuz yakınlığa neden olmadan tam olarak bu sorunu çözüyor.
Asmyldof

1
"Müşterilerim Dropbox'ın yeterince güvenli olduğunu düşünmüyor" Dosyaları sürümlemek için% 100 doğru. Birden çok kullanıcının dosyaları aynı anda değiştirebilmesi ve hatta daha da fazlası, gerçekten de tek bir kaynağı içeren birkaç dosyanız varsa özellikle tehlikelidir. İkili "dosya kümelerinin" bu şekilde bozulduğunu gördüm (merak ediyorsanız ESRI dosyası coğrafi veritabanları).
jpmc26

1
@ jpmc26 Bu aceleci bir yorumdu, versiyonlama her şeyden önce bir güvenlik yönü olarak başladı. Birkaç akıllı GitIgnore şablonu sürümüyle artık her şeyi sorunsuz bir şekilde, sağladığı tüm avantajlarla sarar. Aslında paylaşılan Dropbox'ta tamamen katılıyorum. Bir müşteri sitesinde sonsuz sorunlara neden olur. Geliştirme sırasında dosyalar bilgisayarlarda sonsuz çatışan kopyalar üretiyor ve dev'in en can sıkıcı olanlarından biri olarak kapatıldı.
Asmyldof

@ leftaroundabout: Donanım ve bellenim arasındaki ilişkiye bağlıdır. Normal yazılım projelerine benzetelim. Web sitenizle birlikte gif ve jpg dosyaları taahhüt eder misiniz? Bu durumda, resimler sık ​​sık değişmese bile ikili ve kaynak birbiriyle değişir. Fakat ..Projenizle Apache veya Nginx kaynak kodunu verir misiniz? Bu nedenle, Linux çekirdeğinin kaynak kodunu uygular mısınız? Bu durumda Apache veya Nginx ve Linux çekirdeği donanıma daha benzerdir - bunlar, üzerinde çalışan koddan bağımsız olarak değişir
slebetman

5

1) Kesinlikle değer şematik / tahta dosyaları değerlemeye. Farklılıkları bu kadar kolay izleyemeseniz bile, eski bir cihaz revizyonuyla çalışmak zorunda kalırsanız belirli bir donanım sürümüne geri dönmenin temiz bir yoluna sahipsiniz.

2) SVN'de aşağıdaki yapıya sahibiz.
/ tag
/ branch
/ trunk / donanım
/ trunk / yazılım / bellenim

Yazılım ve / anakart ve / anakart için belki / Bellenim ve / ConfigTool gibi başka alt klasörlerle veya donanım için böyle bir şeyle uygulanabilirse.

2) Etiketler, Tag / Mainboard-v1.2.345 gibi tüm gövdeden olmayan alt klasörlerden oluşturulur. Donanım (yani PCB) her zaman doğrudan referans olması için serigraf baskıda veya bakırda SVN revizyonunu içerir.

4) Donanım ve bellenim arasındaki bağımlılıklar karmaşık olabilir. IMO, taahhütlerle ilgili faydalı yorumlar bırakmak dışında, depo düzeyinde bununla başa çıkmak için pek mantıklı değildir.
Yedek G / Ç pinlerini kullanarak donanım değişikliklerini kodlamayı düşünün. 16 farklı donanım versiyonunu kodlamak için 4 pin kullanmak gibi bir şey. Ayrıca sürümleri kodlamak için farklı direnç değerlerine sahip tek bir ADC girişi kullandık. Bu şekilde yazılım, hangi donanımı çalıştırdığını "bilebilir" ve belirli özellikleri değiştirebilir / devre dışı bırakabilir / etkinleştirebilir.


Katılıyorum. Ayrıca, üretime yönelik her sürümün vesilesiyle şemalar, BOM, gerber'ler, bütün bunlar gibi bir "sürüm paketi" oluşturmak için iyi bir uygulama gördüm. Bu A, B, C vb. Olarak adlandırırsınız ve daha sonra bunları ekibin başvurabileceği bir yerde arşivlersiniz. Ayrıca, hangi prototip kartlarında hangi tel modlarını yaptığınızı takip etmenin bazı yollarını da unutmayın.
pjc50

@ pjc50: Aslında sürüm paketlerini de "derliyoruz", ancak kaynak kontrolü dışındayız (ancak bir revizyon referansı ile). Esasen, üreticinin sahip olduğu her şeyin tam bir kopyası olacaktır. Yüksek hacimli üretim ile profesyonel olarak donanım geliştirme yaparsanız, bir şeylerin yanlış gitmesi durumunda tüm bilgilerin hazır olması çok önemlidir. Tahta evini "bu tek önemli belge" gönderdiğinizde hatırlamıyorsanız, belki özel PCB bakır kalınlığını belirtebilirsiniz, başınız belada olabilir.
Rev1.0
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.