Kontrol versi skema dan kode sumber

Saya mengembangkan perangkat elektronik yang memiliki dua bagian: perangkat keras (skema Elang) dan firmware (kode sumber C ++). Saya ingin melacak perubahan dalam kode sumber dan skema, tetapi ada beberapa poin di mana saya tidak yakin bagaimana mengatur pekerjaan saya:

Untuk kode sumber saya pasti akan menggunakan Git. Tetapi apakah skematik layak versi ketika mereka sebenarnya adalah file biner (versi Eagle baru menggunakan beberapa format XML, tetapi tidak bisa dibaca oleh manusia ...)?
Apakah ide yang baik untuk menempatkan sumber dan skema ke dalam satu repositori Git? Itu masuk akal, tetapi di sisi lain log saya akan berisi perubahan perangkat lunak dan perangkat keras. Juga perangkat lunak dapat memiliki beberapa cabang, tetapi perangkat keras mungkin tidak ...
Bagaimana cara menangani revisi perangkat keras? Beri tag atau simpan di direktori terpisah?
Juga mungkin ada beberapa dependensi antara revisi perangkat keras dan versi firmware. Bagaimana cara menghadapinya?

Bisakah Anda berbagi praktik terbaik Anda dengan saya?

eagle hardware c++ klasyc
sumber

Apakah solusi komersial akan berhasil?

Eugene Sh.

Saya tidak akan menyentuh sistem kontrol versi komersial lagi. Pengalaman saya tentang mereka adalah alur kerja yang mengerikan yang jauh lebih sulit untuk digunakan daripada svn atau bahkan git.

pjc50

Apapun versi perangkat lunak yang Anda gunakan, pastikan itu mengganti seluruh file ketika berhadapan dengan skema dan tidak melihat teks. Saya pernah mengalami itu di masa lalu. Anda tidak akan pernah ingin melakukan diff pada sebagian besar file skematik.

Voltage Spike

Jawaban:

Sebagian besar tergantung pada preferensi pribadi.

Saya melacak semua yang saya lakukan untuk proyek di Git. Terutama karena Git menangani sebagian besar jenis file, bahkan biner, cukup efisien. (Sebagai pengganti built-in Altium SVN omong kosong)

Salah satu alasan utama saya untuk melakukannya adalah bahwa pelanggan saya tidak semua merasa Dropbox cukup aman dan saya membutuhkan sistem cadangan yang dapat saya akses di seluruh dunia, dengan juga beberapa konteks versi pada sebagian besar dari apa yang saya lakukan. Jadi saya mengatur server Git pribadi dan sistem cadangan terenkripsi dan berfungsi dengan baik. Papan, Skema, Kode, Dokumentasi, Laporan, Modifikasi Manual, semuanya dilacak.

Saya biasanya akan membuat Repositori untuk Perangkat Keras, satu untuk Perangkat Lunak dan satu untuk Firmware jika itu adalah proyek besar yang berpotensi berjalan lama, tetapi untuk proyek layanan kecil, contoh atau eksperimen kecil, saya sering memasukkan semuanya ke dalam satu repositori, karena hasilnya kekacauan tidak akan besar.

Di Git Anda dapat menggunakan sub-repositori juga untuk mengintegrasikan Firmware ke proyek Perangkat Keras atau sebaliknya, bahkan jika repositori dikelola secara terpisah.

Untuk proyek yang lebih besar saya juga biasanya menggunakan sistem pelacakan bug untuk melacak masalah dan resolusi, sekali lagi untuk HW dan juga SW, Mantis adalah yang bagus yang dapat digunakan secara gratis.

Untuk revisi perangkat keras yang saya hasilkan Gerbers, atau apa pun yang Anda, ditandai dengan Git Hash untuk revisi itu, Gerbers kemudian adalah satu-satunya hal yang diskrit "kuno" versi dalam folder oleh R01, 02, dll. Karena Anda tidak ingin regenerasi mereka sepanjang waktu, tetapi mereka menghasilkan file sehingga tidak boleh diversi dalam Git sendiri, sungguh (karena perangkat lunak desain Anda harus deterministik dengan menghasilkan konten produksi, atau yang lain ...).

Jika ada sesuatu yang menarik di R01 yang tidak terjadi di R02 (atau sebaliknya), Anda memiliki dua Git Hash yang dapat digunakan untuk membandingkan file sumber, jangan khawatir.

Sebagai catatan akhir, salah satu contoh konseptual proyek, akan memiliki repositori Perangkat Keras, yang juga menampung file "BoardPinout.h". File ini dimasukkan sebagai file versi jauh ke dalam repositori Firmware, yang memiliki beberapa file definisi antarmuka yang dimasukkan dari jarak jauh ke dalam repositori Perangkat Lunak.

Berarti setiap kali saya mengubah beberapa sinyal tanpa memodifikasi fungsionalitas luas proyek HW "memperbarui" BoardPinout, yang kemudian dapat diperbarui dan digunakan dalam Firmware, dan seterusnya.

Asmyldof
sumber

Apakah itu benar-benar pernah masuk akal untuk menempatkan hardware dan firmware di repo yang berbeda? Bagaimana itu menjadi masalah untuk memilikinya dalam satu? Saya lebih suka berharap itu menjadi masalah jika Anda perlu melacak perubahan pada komponen yang dimiliki bersama (misalnya pin IO yang ditukar harus tercermin dalam tugas firmware yang berbeda, dan memeriksa versi yang tidak dapat digunakan akan menyebabkan kekacauan).

leftaroundabout

@leftaroundabout Pertama-tama, menggembungkan repo FW Anda yang cepat berubah dengan sebagian besar desain CAD kompleks tidak selalu seperti yang Anda inginkan, tetapi Anda mungkin juga ingin membaca ulang bit tentang sub-repo dan keterkaitan di antara mereka. Sama sekali tidak sulit untuk dilakukan dengan Git dan itu memperbaiki masalah itu dengan tepat tanpa menyebabkan semua jenis keintiman yang tidak pantas antara saluran desain.

Asmyldof

"Pelanggan saya tidak semua merasa Dropbox cukup aman" Untuk file versi, mereka 100% benar. Ini sangat berbahaya jika banyak pengguna dapat memodifikasi file pada saat bersamaan, dan terlebih lagi jika Anda memiliki beberapa file yang benar-benar terdiri dari satu sumber daya. Saya telah melihat biner "set file" rusak dengan cara ini (ESRI file geodatabases, jika Anda penasaran).

jpmc26

@ jpmc26 Itu adalah komentar yang terburu-buru, semua versi awalnya dimulai lebih sebagai aspek keamanan. Dengan beberapa versi pintar GitIgnore template sekarang dengan mudah menyelubungi semuanya tanpa kerumitan, dengan semua kelebihan yang dimilikinya. Saya sebenarnya sepenuhnya setuju dengan Anda di Dropbox yang dibagikan. Di satu situs pelanggan itu menyebabkan masalah tak berujung. File yang sedang dikembangkan memunculkan salinan konflik yang tak berujung pada komputer yang dimatikan selama bagian dev menjadi salah satu yang paling menyebalkan.

Asmyldof

@leftaroundabout: Tergantung pada hubungan antara perangkat keras dan firmware. Mari kita ambil analogi dengan proyek perangkat lunak normal. Apakah Anda melakukan file gif dan jpg bersama dengan situs web Anda? Dalam hal ini biner dan sumber berubah satu sama lain walaupun gambarnya tidak sering berubah. Tapi .. apakah Anda melakukan kode sumber Apache atau Nginx dengan proyek Anda. Dalam hal ini, apakah Anda akan mengkomit kode sumber kernel Linux? Dalam hal ini Apache atau Nginx dan kernel Linux lebih analog dengan perangkat keras - mereka berubah tetapi secara independen dari kode yang Anda tulis yang dijalankan pada mereka

slebetman

1) Ini jelas layak versi skematik / file papan. Bahkan jika Anda tidak dapat melacak perbedaan dengan begitu mudah, Anda memiliki cara yang bersih untuk kembali ke rilis perangkat keras tertentu jika Anda harus bekerja dengan revisi perangkat yang lama.

2) Kami memiliki struktur berikut dalam SVN kami.
/ tag
/ branch
/ trunk / hardware
/ trunk / software / firmware

Jika berlaku dengan lebih banyak sub-folder seperti mungkin / Firmware dan / ConfigTool untuk perangkat lunak dan / mainboard dan / papan anak atau sesuatu seperti itu untuk perangkat keras.

2) Tag dibuat dari sub-folder bukan dari keseluruhan trunk, seperti Tag / Mainboard-v1.2.345. Perangkat keras (yaitu PCB) selalu berisi revisi SVN di sablon sutra atau tembaga untuk memiliki referensi langsung.

4) Ketergantungan antara perangkat keras dan firmware bisa rumit. IMO itu tidak masuk akal untuk menghadapinya di tingkat repositori kecuali meninggalkan komentar yang berguna saat melakukan.
Pertimbangkan untuk mengkodekan perubahan perangkat keras menggunakan pin I / O cadangan. Sesuatu seperti menggunakan 4 pin untuk mengkodekan 16 versi perangkat keras yang berbeda. Kami juga menggunakan input ADC tunggal dengan nilai resistansi berbeda untuk menyandikan versi. Dengan cara ini perangkat lunak dapat "mengetahui" perangkat keras apa yang dijalankannya dan mengubah / menonaktifkan / mengaktifkan fitur tertentu.

Rev1.0
sumber

Saya setuju. Saya juga telah melihat praktik yang baik untuk membangun "bundel rilis" - skema, BOM, gerbers, semuanya - pada setiap rilis ke produksi. Anda memanggil ini A, B, C dll dan kemudian mengarsipkannya di suatu tempat di mana tim dapat merujuk mereka. Juga, jangan lupa beberapa cara melacak mod kawat apa yang telah Anda lakukan di papan prototipe mana.

pjc50

@ pjc50: Sebenarnya kami juga membuat "rilis" bundel, tetapi di luar kendali sumber (tetapi dengan referensi revisi). Pada dasarnya itu akan menjadi salinan tepat dari semua yang didapat pabrikan. Jika Anda melakukan pengembangan perangkat keras secara profesional dengan produksi volume tinggi, sangat penting untuk memiliki semua informasi yang tersedia jika terjadi kesalahan. Jika Anda tidak ingat apakah Anda mengirim papan tulis "dokumen penting ini" yang mungkin menentukan ketebalan tembaga PCB khusus, Anda dapat berada dalam masalah.

Rev1.0