สารบัญ:

การควบคุมเวอร์ชันสำหรับฮาร์ดแวร์โอเพ่นซอร์ส: 10 ขั้นตอน
การควบคุมเวอร์ชันสำหรับฮาร์ดแวร์โอเพ่นซอร์ส: 10 ขั้นตอน

วีดีโอ: การควบคุมเวอร์ชันสำหรับฮาร์ดแวร์โอเพ่นซอร์ส: 10 ขั้นตอน

วีดีโอ: การควบคุมเวอร์ชันสำหรับฮาร์ดแวร์โอเพ่นซอร์ส: 10 ขั้นตอน
วีดีโอ: Crater Invoices - Open Source, Self Hosted Invoicing and Billing software with Power! 2024, พฤศจิกายน
Anonim
การควบคุมเวอร์ชันสำหรับฮาร์ดแวร์โอเพ่นซอร์ส
การควบคุมเวอร์ชันสำหรับฮาร์ดแวร์โอเพ่นซอร์ส

ทีมงานที่ Brainbow มีโครงการด้านอิเล็กทรอนิกส์จำนวนหนึ่งภายใต้สายงานของเรา และเราต้องการแบ่งปันขั้นตอนของเราในการใช้การควบคุมเวอร์ชันเพื่อจัดการเวิร์กโฟลว์การออกแบบอุปกรณ์อิเล็กทรอนิกส์ของเรา เวิร์กโฟลว์นี้ใช้สำหรับโครงการขนาดใหญ่และขนาดเล็ก ตั้งแต่บอร์ด 2 เลเยอร์ธรรมดาไปจนถึง 10 เลเยอร์ที่ซับซ้อน และใช้เครื่องมือโอเพนซอร์ส หวังว่าคนอื่นๆ จะสามารถนำเวิร์กโฟลว์ของเราไปใช้เองได้ และได้รับประโยชน์จากการควบคุมเวอร์ชันสำหรับโปรเจ็กต์ของตนเอง แต่การควบคุมเวอร์ชันจะมีประโยชน์อะไรสำหรับโครงการอิเล็กทรอนิกส์?

ขั้นตอนที่ 1: ทำไมเวอร์ชันจึงควบคุมอุปกรณ์อิเล็กทรอนิกส์ของคุณ

การควบคุมเวอร์ชัน (หรือที่เรียกว่าการควบคุมแหล่งที่มาหรือการควบคุมการแก้ไข) เป็นแนวคิดที่เข้าใจกันดีและนำมาใช้กันอย่างแพร่หลายในด้านวิศวกรรมซอฟต์แวร์ แนวคิดเบื้องหลังการควบคุมแหล่งที่มาคือการติดตามการเปลี่ยนแปลงที่ทำกับซอร์สโค้ดของโปรแกรมหรือแอปพลิเคชันอย่างเป็นระบบ หากการเปลี่ยนแปลงทำให้แอปพลิเคชันเสียหาย คุณสามารถเปลี่ยนไฟล์ซอร์สโค้ดกลับเป็นสถานะการทำงานที่รู้จักในอดีตได้ ในทางปฏิบัติ ระบบควบคุมแหล่งที่มาช่วยให้คุณสามารถติดตามประวัติของคอลเลกชันของไฟล์ (โดยปกติคือไฟล์ซอร์สโค้ดสำหรับโปรแกรมคอมพิวเตอร์ เว็บไซต์ ฯลฯ) และแสดงภาพและจัดการการเปลี่ยนแปลงของไฟล์เหล่านั้น

การติดตามประวัติการเปลี่ยนแปลงโครงการดูเหมือนจะเป็นประโยชน์สำหรับโครงการอิเล็กทรอนิกส์ หากคุณทำผิดพลาดในแผนผังวงจร หรือใช้ส่วนประกอบที่ไม่ถูกต้องในเลย์เอาต์ PCB จะเป็นการดีที่จะติดตามว่ามีข้อผิดพลาดใดเกิดขึ้นและการแก้ไขใดบ้างที่นำมาใช้ในการแก้ไขต่างๆ ของโปรเจ็กต์ นอกจากนี้ยังเป็นประโยชน์สำหรับผู้ผลิตรายอื่นในการดูประวัติศาสตร์นั้น และเข้าใจบริบทและแรงจูงใจของการเปลี่ยนแปลงต่างๆ

ขั้นตอนที่ 2: เครื่องมือ: KiCad และ Git

เครื่องมือ: KiCad และ Git
เครื่องมือ: KiCad และ Git

เราใช้เครื่องมือหลักสองอย่างในโครงการนี้: ระบบควบคุมเวอร์ชัน (VCS) และโปรแกรมออกแบบอิเล็กทรอนิกส์อัตโนมัติ (EDA หรือ ECAD)

มีระบบควบคุมเวอร์ชันมากมาย แต่เราใช้ VCS Git แบบกระจาย เราใช้มันด้วยเหตุผลหลายประการ แต่ที่สำคัญคือมันเป็นโอเพ่นซอร์ส (ตรวจสอบ!) ใช้งานง่าย (ตรวจสอบ!) และ VCS มาตรฐานโดยพฤตินัยสำหรับซอฟต์แวร์โอเพ่นซอร์ส (ตรวจสอบ!) เราจะใช้ Git เป็น VCS เพื่อติดตามการเปลี่ยนแปลงของไฟล์ที่โปรแกรม ECAD ของเราใช้ คำแนะนำนี้ไม่ต้องการความคุ้นเคยกับ Git แต่ถือว่าสะดวกสบายทั่วไปโดยใช้บรรทัดคำสั่ง ฉันจะพยายามเชื่อมโยงไปยังแหล่งข้อมูลที่เป็นประโยชน์สำหรับทั้ง Git และการใช้บรรทัดคำสั่งตามความจำเป็น

ระบบควบคุมต้นทางส่วนใหญ่ทำงานได้ดีกับไฟล์แบบข้อความ ดังนั้นโปรแกรม ECAD ที่ใช้ไฟล์ข้อความจึงเหมาะอย่างยิ่ง เข้าสู่ KiCad ซึ่งเป็นโอเพ่นซอร์ส "Cross Platform และ Open Source Electronics Design Automation Suite" ซึ่งได้รับการสนับสนุนโดยนักวิจัยที่ CERN KiCad ยังเป็นโอเพ่นซอร์ส (ตรวจสอบ!) ใช้งานง่าย (แม้ว่าบางคนอาจไม่เห็นด้วยกับฉันในเรื่องนี้) และมีความสามารถสูงสำหรับงานออกแบบอิเล็กทรอนิกส์ขั้นสูง

ขั้นตอนที่ 3: การติดตั้ง

การติดตั้ง
การติดตั้ง
การติดตั้ง
การติดตั้ง

ในการติดตั้งโปรแกรมเหล่านี้ ให้ทำตามคำแนะนำจากเว็บไซต์ดาวน์โหลดต่างๆ ที่ลิงก์ด้านล่าง

  • KiCad เป็นแพลตฟอร์มข้ามแพลตฟอร์ม (และเวียนหัวดังนั้นหน้าดาวน์โหลดของพวกเขาแสดงระบบปฏิบัติการที่รองรับ 13 รายการและเสนอการดาวน์โหลดซอร์สโค้ดหากไม่มีสิ่งที่คุณต้องการ) ใช้การติดตั้งเริ่มต้นแบบรวม kicad ไม่ใช่บิลด์การพัฒนาทุกคืน ดูขั้นตอนที่ 4 สำหรับรายละเอียดเพิ่มเติมเกี่ยวกับการติดตั้งไลบรารี
  • Git ยังเป็นแพลตฟอร์มข้ามแพลตฟอร์มอีกด้วย หากใช้ Windows ฉันขอแนะนำโปรเจ็กต์ Git สำหรับ Windows ที่น่าประทับใจสำหรับประสบการณ์ที่มีประโยชน์และมีคุณสมบัติครบถ้วนมากขึ้น

เอกสารการติดตั้งที่มีอยู่ในไซต์ทั้งสองนี้จะมีความสมบูรณ์มากกว่าคำอธิบายใดๆ ที่ฉันสามารถนำเสนอได้ที่นี่ เมื่อดาวน์โหลดและติดตั้งทั้งสองโปรแกรมแล้ว คุณสามารถโคลนเทมเพลตโปรเจ็กต์ของ Brainbow ได้จากที่เก็บ Github ของเรา คำสั่ง git clone ใช้โครงสร้าง `git clone {src directory} {target directory}`; สำหรับโครงการของเรา ให้ใช้ `git clone https://github.com/builtbybrainbow/kicad-starter.git {target directory}`

การโคลน repo git เป็นรูปแบบพิเศษของการคัดลอก เมื่อคุณโคลนโปรเจ็กต์ คุณจะได้รับสำเนาของไฟล์ทั้งหมดที่รวมอยู่ใน repo รวมถึงประวัติการติดตาม Git ทั้งหมดของโปรเจ็กต์ โดยการโคลน repo ของเรา คุณจะได้ไดเร็กทอรีโปรเจ็กต์ที่มีโครงสร้างพร้อมคำแนะนำในการใช้ Git กับ KiCad แล้ว เราจะอธิบายเพิ่มเติมเกี่ยวกับโครงสร้างโครงการในขั้นตอนที่ 6 หรือคุณสามารถข้ามไปยังขั้นตอนที่ 7 หากคุณต้องการทำงาน

งานทำความสะอาดด่วนสองสามงาน - เรียกใช้ `git remote rm origin` เพื่อลบลิงก์ไปยังโครงการ Github ที่คุณโคลน นอกจากนี้ ให้เรียกใช้ `git commit --amend --author="John Doe "` โดยแทนที่พารามิเตอร์ผู้เขียนด้วยชื่อและอีเมลของคุณ นี่เป็นการแก้ไขการคอมมิตล่าสุด (ซึ่งในกรณีนี้เป็นการคอมมิตแรกด้วย) และเปลี่ยนผู้แต่งเป็นคุณ แทนที่จะเป็น Brainbow

ขั้นตอนที่ 4: หมายเหตุการติดตั้ง: KiCad Libraries

หมายเหตุการติดตั้ง: KiCad Libraries
หมายเหตุการติดตั้ง: KiCad Libraries

บันทึกย่อสั้นๆ เกี่ยวกับโครงสร้างไลบรารีของ KiCad KiCad มีชุดไลบรารีที่ดูแลโดยทีมนักพัฒนาสำหรับส่วนประกอบทางไฟฟ้าที่หลากหลาย มีห้องสมุดหลักสามแห่ง:

  • Schematic Symbols: สัญลักษณ์ที่ใช้สำหรับแสดงส่วนประกอบอิเล็กทรอนิกส์ในการวาดแผนผังวงจร
  • รอยเท้า PCB: ภาพวาด 2 มิติที่แสดงถึงรอยเท้าจริง (แผ่นทองแดง ข้อความซิลค์สกรีน ฯลฯ) ที่จะใช้เมื่อวางวงจรบน PCB
  • โมเดล 3 มิติ: โมเดล 3 มิติของชิ้นส่วนอิเล็กทรอนิกส์

ไลบรารีเหล่านี้ถูกดาวน์โหลดพร้อมกับชุดโปรแกรม KiCad ที่คุณเพิ่งติดตั้ง คุณสามารถใช้ KiCad ได้โดยไม่ต้องใช้ความพยายามอีกต่อไป อย่างไรก็ตาม สำหรับ "ผู้ใช้ระดับสูง" ไฟล์ต้นฉบับสำหรับไลบรารีจะถูกเก็บไว้ในที่เก็บ git บน Github ทำให้ผู้ใช้ที่ต้องการติดตามการเปลี่ยนแปลงล่าสุดในการโคลน repo ของไลบรารีไปยังเครื่องของตนเอง การติดตามไลบรารีด้วย git มีข้อดีหลายประการ - คุณสามารถเลือกเวลาที่คุณต้องการอัปเดตไลบรารีของคุณ และการอัปเดตจำเป็นต้องรวมการเปลี่ยนแปลงในไฟล์เท่านั้น แทนที่จะดาวน์โหลดไฟล์ไลบรารีทั้งชุดอีกครั้ง อย่างไรก็ตาม คุณมีหน้าที่รับผิดชอบในการอัปเดตไลบรารี ซึ่งสามารถลืมได้ง่าย

หากคุณต้องการโคลนไลบรารี ไซต์นี้มีรายละเอียดเกี่ยวกับข้อเสนอ Github repos KiCad ต่างๆ Git โคลนไลบรารีไปยังคอมพิวเตอร์ของคุณ (เช่น `git clone https://github.com/KiCad/kicad-symbols.git`) จากนั้นเปิด KiCad เลือกรายการ "Preferences" ของแถบเมนู แล้วคลิก "กำหนดค่าเส้นทาง… ". ซึ่งช่วยให้คุณบอกเส้นทางไดเรกทอรีของ KiCad เพื่อค้นหาแต่ละไลบรารีได้ ตัวแปรสภาพแวดล้อมเหล่านี้มีค่าเริ่มต้นเป็นพาธไปยังไลบรารีที่ติดตั้งด้วยการติดตั้ง KiCad ฉันจดบันทึกค่าเหล่านี้เพื่อที่ฉันจะได้เปลี่ยนกลับไปใช้ไลบรารีเริ่มต้นได้หากจำเป็น เส้นทาง KICAD_SYMBOL_DIR ควรชี้ไปที่ไลบรารี kicad-symbols ที่โคลนของคุณ KISYSMOD ไปยังไลบรารี kicad-footprints ที่โคลน และ KISYS3DMOD ไปยังไลบรารี kicad-packages3d ที่โคลน

เมื่อคุณต้องการอัปเดตไลบรารี คุณสามารถเรียกใช้คำสั่ง `git pull` ง่ายๆ ใน repo ของไลบรารี ซึ่งจะบอกให้ Git ตรวจสอบความแตกต่างระหว่างสำเนา repo ของไลบรารีในเครื่องและ repo "remote" ของ Github และอัปเดตของคุณโดยอัตโนมัติ สำเนาท้องถิ่นเพื่อรวมการเปลี่ยนแปลง

ขั้นตอนที่ 5: Git Fundamentals

พื้นฐาน Git
พื้นฐาน Git

Git เป็นโปรแกรมที่ซับซ้อนและมีหลายแง่มุม โดยมีหนังสือทั้งเล่มที่ทุ่มเทให้กับการเรียนรู้มัน อย่างไรก็ตาม มีแนวคิดง่ายๆ สองสามข้อที่จะช่วยให้คุณเข้าใจว่าเราใช้ Git ในกระบวนการทำงานอย่างไร

Git ติดตามการเปลี่ยนแปลงของไฟล์โดยใช้ชุดของขั้นตอน การเปลี่ยนแปลงปกติเกิดขึ้นในไดเร็กทอรีการทำงาน เมื่อคุณพอใจกับการเปลี่ยนแปลงที่คุณทำกับชุดของไฟล์ คุณจะเพิ่มไฟล์ที่คุณได้เปลี่ยนแปลงไปยังพื้นที่จัดเตรียม เมื่อคุณได้ทำการเปลี่ยนแปลงทั้งหมดที่คุณวางแผนและจัดฉากไฟล์ทั้งหมดที่คุณต้องการติดตามใน Git คุณจะยอมรับการเปลี่ยนแปลงเหล่านั้นไปยังที่เก็บ คอมมิตนั้นเป็นสแนปชอตของสถานะของไฟล์ใน repo ในเวลาที่กำหนด เนื่องจาก Git ติดตามการเปลี่ยนแปลงของไฟล์และจัดเก็บการเปลี่ยนแปลงเหล่านี้ในการคอมมิต คุณจึงสามารถเปลี่ยนโปรเจ็กต์กลับเป็นสถานะเดิมได้ทุกเมื่อ

มีหัวข้อที่ซับซ้อนมากขึ้น เช่น การแตกแขนงและรีโมต แต่เราไม่จำเป็นต้องใช้สิ่งเหล่านี้เพื่อให้ได้รับประโยชน์จากการควบคุมแหล่งที่มา ทั้งหมดที่เราต้องการคือการติดตามการเปลี่ยนแปลงในไฟล์การออกแบบ KiCad ของเราด้วยชุดการคอมมิต

ขั้นตอนที่ 6: โครงสร้างโครงการ KiCad

โครงสร้างโครงการ KiCad
โครงสร้างโครงการ KiCad

มาดูโครงสร้างของโครงการ KiCad-Starter ที่คุณโคลนไว้ก่อนหน้านี้อย่างละเอียด แบ่งออกเป็นไดเร็กทอรีย่อยจำนวนหนึ่งสำหรับการจัดระเบียบที่ง่าย:

  • วงจร: โฟลเดอร์นี้มีไฟล์โครงการ KiCad จริง (แผนผัง, PCB, ฯลฯ) ฉันไม่เปลี่ยนชื่อโฟลเดอร์นี้ แต่ฉันเปลี่ยนชื่อไฟล์ทั้งหมดภายในด้วยชื่อโครงการ (Circuit.pro => ArduinoMini.pro)

    • Circuit.pro: ไฟล์โครงการ KiCad
    • Circuit.sch: ไฟล์แผนผัง KiCad
    • Circuit.kicad_pcb: ไฟล์เค้าโครง KiCad PCB
  • เอกสารประกอบ: โฟลเดอร์นี้ใช้สำหรับจัดเก็บเอกสารเกี่ยวกับโครงการ เรามีแผนที่จะปรับปรุงพื้นที่นี้ในอนาคต แต่ตอนนี้มีไฟล์ README แบบง่าย ใช้เพื่อจัดเก็บบันทึกย่อเกี่ยวกับโครงการเพื่อให้คุณทบทวนในอนาคต
  • การประดิษฐ์: โฟลเดอร์นี้เป็นที่ที่คุณจะเก็บไฟล์เกอร์เบอร์ที่ fab house ส่วนใหญ่จะใช้สำหรับการผลิตแผงวงจรของคุณ เรายังใช้เพื่อจัดเก็บไฟล์ BOM และเอกสารอื่นๆ ที่อาจจำเป็นสำหรับการผลิตและการประกอบ
  • ไลบรารี: โฟลเดอร์นี้ใช้สำหรับจัดเก็บไฟล์ไลบรารีเฉพาะโปรเจ็กต์ (เราจะอธิบายเพิ่มเติมในไม่กี่ขั้นตอน)

คุณอาจสังเกตเห็นไฟล์อื่นๆ สองสามไฟล์ (โดยเฉพาะถ้าคุณ `ls -a` ไดเร็กทอรี) ไดเร็กทอรี.git เป็นที่ที่ Git ทำหน้าที่เสมือนเวทมนตร์ โดยจัดเก็บประวัติของที่เก็บ ไฟล์.gitignore ใช้เพื่อบอก Git ว่าไฟล์ใดควรละเว้นและไม่จัดเก็บไว้ในการควบคุมแหล่งที่มา ไฟล์เหล่านี้ส่วนใหญ่เป็นไฟล์สำรองที่ KiCad สร้าง หรือไฟล์ "สร้าง" ที่แตกต่างกันสองสามไฟล์ เช่น netlists ซึ่งไม่ควรจัดเก็บไว้ในการควบคุมต้นทาง เนื่องจากไฟล์เหล่านี้สร้างขึ้นจากแหล่งที่มาที่เป็นไฟล์แผนผัง

โครงสร้างโครงการนี้เป็นเพียงจุดเริ่มต้น คุณควรปรับให้เข้ากับความต้องการของคุณ และเพิ่มส่วนต่างๆ ตามความจำเป็น ในบางโปรเจ็กต์ เราได้รวมโฟลเดอร์ซอฟต์แวร์หรือโฟลเดอร์ของเคส ซึ่งเราจัดเก็บโมเดลสำหรับเคสการพิมพ์ 3 มิติสำหรับโปรเจ็กต์

ขั้นตอนที่ 7: การใช้ Git สำหรับโครงการ KiCad

การใช้ Git สำหรับโครงการ KiCad
การใช้ Git สำหรับโครงการ KiCad
การใช้ Git สำหรับโครงการ KiCad
การใช้ Git สำหรับโครงการ KiCad
การใช้ Git สำหรับโครงการ KiCad
การใช้ Git สำหรับโครงการ KiCad

ในที่สุด เราก็พร้อมที่จะดูวิธีใช้ Git เพื่อติดตามโครงการของคุณแล้ว คำแนะนำนี้ไม่ได้มีวัตถุประสงค์เพื่อสอนวิธีใช้ KiCad ให้คุณ (แม้ว่าฉันอาจทำอย่างใดอย่างหนึ่งในอนาคตหากมีความต้องการ) ดังนั้นเราจะเรียกใช้ตัวอย่างเล็กน้อยเพื่อแสดงให้คุณเห็นว่าเวิร์กโฟลว์ทำงานอย่างไร ควรทำความเข้าใจวิธีปรับแนวคิดเหล่านี้ให้เข้ากับโครงการจริงได้ง่าย

เปิดไดเร็กทอรี kicad-starter จากนั้นเรียกใช้ `git log` เพื่อแสดงประวัติการคอมมิต ควรมีหนึ่งคอมมิตที่นี่ การเริ่มต้นของ repo โดย Brainbow การเรียกใช้ "สถานะ git" จะบอกสถานะของไฟล์ใน repo ของคุณ (ไม่ถูกติดตาม แก้ไข ลบ จัดฉาก)

ในขณะนี้ คุณไม่ควรจะมีการเปลี่ยนแปลงใน repo ของคุณ มาทำการเปลี่ยนแปลงกันเถอะ เปิดโครงการ KiCad และเพิ่มตัวต้านทานให้กับแผนผัง จากนั้นบันทึก ขณะนี้การเรียกใช้ "สถานะ git" ควรแสดงว่าคุณได้แก้ไขไฟล์แผนผังแล้ว แต่ยังไม่ได้จัดฉากการเปลี่ยนแปลงเหล่านั้นสำหรับการคอมมิต หากคุณสงสัยว่า KiCad ทำอะไรเมื่อคุณเพิ่มตัวต้านทาน คุณสามารถเรียกใช้คำสั่ง diff บนไฟล์ที่แก้ไข `git diff Circuit/Circuit.sch` สิ่งนี้จะเน้นการเปลี่ยนแปลงระหว่างเวอร์ชันปัจจุบันของไฟล์ในไดเร็กทอรีการทำงานและสถานะของไฟล์เมื่อคอมมิตครั้งล่าสุด

ตอนนี้เราได้ทำการเปลี่ยนแปลงแล้ว ให้ลองทำการเปลี่ยนแปลงนั้นกับประวัติโครงการของเรา เราจำเป็นต้องย้ายการเปลี่ยนแปลงจากไดเร็กทอรีการทำงานของเราไปยังพื้นที่การแสดงละคร การดำเนินการนี้ไม่ได้ย้ายไฟล์ในระบบไฟล์ แต่เป็นแนวคิดเพื่อให้ Git รู้ว่าคุณได้ทำการเปลี่ยนแปลงที่วางแผนไว้ทั้งหมดสำหรับไฟล์หนึ่งๆ และพร้อมที่จะยอมรับการเปลี่ยนแปลงเหล่านั้น มีประโยชน์ Git ให้คำแนะนำบางอย่างเมื่อคุณเรียกใช้ "สถานะ git" สำหรับการดำเนินการถัดไป สังเกตข้อความ `(ใช้ "git add …" เพื่ออัปเดตสิ่งที่จะคอมมิต)` ใต้ `การเปลี่ยนแปลงที่ไม่ได้จัดฉากสำหรับการคอมมิต:` Git กำลังบอกคุณถึงวิธีย้ายการเปลี่ยนแปลงไปยังพื้นที่การแสดงละคร เรียกใช้ `git add Circuit/Circuit.sch` เพื่อกำหนดการเปลี่ยนแปลง จากนั้น `สถานะ git' เพื่อดูว่าเกิดอะไรขึ้น ตอนนี้เราเห็นไฟล์แผนผังภายใต้การเปลี่ยนแปลงที่จะคอมมิต หากคุณยังไม่ต้องการยืนยันการเปลี่ยนแปลงเหล่านี้ Git ก็ได้เสนอเคล็ดลับอื่นๆ ที่เป็นประโยชน์: `(ใช้ "git reset HEAD …" เพื่อยกเลิกสเตจ)` เราต้องการยืนยันการเปลี่ยนแปลงเหล่านี้ ดังนั้นเราจึงเรียกใช้ `git commit -m "Added resistor to schematic"` สิ่งนี้ยืนยันการเปลี่ยนแปลงด้วยข้อความที่ให้ไว้ การรัน git log จะแสดงการคอมมิตนี้ในประวัติการคอมมิตของโปรเจ็กต์

เคล็ดลับเพิ่มเติมเล็กน้อยเกี่ยวกับการคอมมิต

  1. อย่าผูกมัดกับทุกการบันทึก มุ่งมั่นเมื่อคุณรู้สึกว่าคุณได้มาถึงจุดที่การเปลี่ยนแปลงของคุณค่อนข้างมั่นคงแล้ว ฉันยอมรับหลังจากที่ฉันทำแผนผังเสร็จ ไม่ใช่หลังจากเพิ่มส่วนประกอบทุกครั้ง คุณไม่ต้องการที่จะคอมมิตบ่อยเกินไป เพราะการจำบริบทว่าทำไมคุณทำการเปลี่ยนแปลงที่คุณทำใน 3 สัปดาห์ต่อมาอาจเป็นเรื่องยาก การพิจารณาว่าเมื่อใดควรกระทำการนั้นเป็นเรื่องเล็กน้อย แต่คุณจะรู้สึกสบายใจขึ้นเมื่อใช้ Git มากขึ้น
  2. แหล่งที่มาของร้านค้าเท่านั้น (ส่วนใหญ่) ซึ่งรวมถึงโปรเจ็กต์ ไฟล์แผนผัง และเลย์เอาต์ ตลอดจนไลบรารีเฉพาะโปรเจ็กต์ นอกจากนี้ยังรวมถึงไฟล์เอกสาร โปรดใช้ความระมัดระวังเมื่อจัดเก็บอ็อบเจ็กต์ที่ได้รับ เนื่องจากอ็อบเจ็กต์ที่ได้รับจะไม่ตรงกับต้นฉบับได้ง่าย และทำให้ปวดหัวในภายหลัง ไฟล์ BOM และ gerber จะยกเลิกการซิงโครไนซ์ได้ง่ายเป็นพิเศษ ดังนั้นจึงควรหลีกเลี่ยง (แม้ว่าจะมีคำแนะนำโดยละเอียดเพิ่มเติมในขั้นตอนที่ 9)
  3. ข้อความคอมมิตมีประโยชน์มาก แต่ข้อความคอมมิตที่มีโครงสร้างดีนั้นมีค่ามาก บทความที่ยอดเยี่ยมนี้ให้แนวทางในการเขียนข้อความยืนยันที่ชัดเจน กระชับ และมีประโยชน์ การทำเช่นนี้อาจต้องใช้โปรแกรมแก้ไขข้อความบรรทัดคำสั่ง ซึ่งอาจทำให้ซับซ้อนสำหรับผู้เริ่มต้น (`git commit` โดยไม่มีตัวเลือกข้อความ -m จะเปิดโปรแกรมแก้ไขข้อความ) สำหรับคนส่วนใหญ่ ฉันแนะนำตัวแก้ไข Nano StackOverflow มีคำอธิบายที่ดีเกี่ยวกับการเปลี่ยนตัวแก้ไขของคุณ

ขั้นตอนที่ 8: ขั้นสูง: การกำหนดเวอร์ชันเชิงความหมายสำหรับอุปกรณ์อิเล็กทรอนิกส์

ขั้นสูง: การกำหนดเวอร์ชันเชิงความหมายสำหรับอุปกรณ์อิเล็กทรอนิกส์
ขั้นสูง: การกำหนดเวอร์ชันเชิงความหมายสำหรับอุปกรณ์อิเล็กทรอนิกส์

สำหรับจิตวิญญาณแห่งการผจญภัย คำแนะนำต่อไปนี้เป็นแนวคิดขั้นสูง ซึ่งรวบรวมมาจากการพัฒนา KiCad เป็นเวลาหลายชั่วโมง พวกมันไม่ได้มีประโยชน์อย่างยิ่งกับโปรเจ็กต์ขนาดเล็ก แต่พวกมันสามารถช่วยให้คุณไม่ต้องปวดใจเมื่อโปรเจ็กต์ของคุณมีความซับซ้อนมากขึ้น

ในซอฟต์แวร์มีแนวคิดของ Semantic Versioning (semver) Semver กำหนดวิธีการตั้งชื่อทั่วไปเพื่อระบุซอฟต์แวร์ที่เผยแพร่โดย "หมายเลขเวอร์ชัน" ตามรูปแบบของ "Major. Minor. Patch" หากต้องการเสนอราคาข้อมูลจำเพาะของ semver คุณต้องเลื่อนหมายเลขเวอร์ชันตามหมวดหมู่การเปลี่ยนแปลงต่อไปนี้

  1. เวอร์ชัน MAJOR เมื่อคุณทำการเปลี่ยนแปลง API ที่เข้ากันไม่ได้
  2. รุ่น MINOR เมื่อคุณเพิ่มฟังก์ชันการทำงานในลักษณะที่เข้ากันได้แบบย้อนหลัง
  3. เวอร์ชัน PATCH เมื่อคุณแก้ไขข้อบกพร่องที่เข้ากันได้แบบย้อนหลัง

พวกเราที่ Brainbow ใช้เวอร์ชันของเราเองที่ปรับให้เข้ากับความต้องการของโครงการฮาร์ดแวร์ ข้อมูลจำเพาะของเราเป็นไปตามรูปแบบ "Major. Minor. Patch" เดียวกัน แม้ว่าคำจำกัดความของเราเกี่ยวกับการเปลี่ยนแปลงใดจะอยู่ภายใต้หมวดหมู่ที่แตกต่างกันอย่างเห็นได้ชัด

  1. เวอร์ชัน MAJOR: ใช้สำหรับการเปลี่ยนแปลงการทำงานหลักของวงจรอย่างมีนัยสำคัญ (เช่น: การสลับโปรเซสเซอร์จาก ATmegaa เป็น ESP8266)
  2. เวอร์ชัน MINOR: ใช้สำหรับการแลกเปลี่ยนส่วนประกอบที่อาจส่งผลต่อการทำงานของวงจร (เช่น: SPI flash swap กับชิ้นส่วนที่เข้ากันได้กับพินที่อาจมีชุดคำสั่งที่แตกต่างกัน) หรือการเพิ่มคุณสมบัติเพิ่มเติมเล็กน้อย (เช่น: เพิ่มเซ็นเซอร์อุณหภูมิเพิ่มเติม)
  3. เวอร์ชัน PATCH: ใช้สำหรับแก้ไขข้อผิดพลาดเล็กน้อยที่จะไม่เปลี่ยนการทำงานของวงจร (เช่น การปรับซิลค์สกรีน การปรับเลย์เอาต์เล็กน้อย การสลับส่วนประกอบอย่างง่าย เช่น ตัวเก็บประจุ 0603 เป็น 0805)

ในเซิร์ฟเวอร์ฮาร์ดแวร์ หมายเลขเวอร์ชันจะได้รับการอัปเดตในการผลิตเท่านั้น (เช่นเดียวกับในซอฟต์แวร์ หมายเลขเวอร์ชันจะเปลี่ยนเฉพาะเมื่อมีการเผยแพร่เท่านั้น ไม่ใช่ทุกคนที่ยอมรับในโปรเจ็กต์) ส่งผลให้หลายโครงการมีหมายเลขเวอร์ชันต่ำ เรายังไม่มีโปรเจ็กต์ที่ใช้เวอร์ชันหลักมากกว่า 4 เวอร์ชัน

นอกจากประโยชน์ในด้านความสม่ำเสมอและความเข้าใจที่คุณได้รับจากการเปลี่ยนไปใช้ระบบการตั้งชื่อที่กำหนดไว้อย่างดีแล้ว คุณยังได้รับประโยชน์ในด้านความเข้ากันได้ของเฟิร์มแวร์และความพึงพอใจของลูกค้าอีกด้วย สามารถเขียนเฟิร์มแวร์ได้โดยคำนึงถึงเวอร์ชันของบอร์ดที่เป็นเป้าหมาย และสามารถดีบักได้ง่ายกว่าเพราะเหตุใดโปรแกรมใดโปรแกรมหนึ่งจึงไม่ทำงานบนบอร์ดใดบอร์ดหนึ่ง ( ใช่แล้ว เฟิร์มแวร์ 2.4.1 ไม่ทำงานบน 1.2 บอร์ดเพราะเราไม่มี…..”) ลูกค้ายังได้รับประโยชน์จากการใช้ฮาร์ดแวร์ของเราอีกด้วย เนื่องจากการบริการลูกค้าและการแก้ไขปัญหานั้นง่ายกว่ามากด้วยมาตรฐานที่กำหนดไว้

ขั้นตอนที่ 9: ขั้นสูง: การใช้ Hardware Semantic Versioning

ขั้นสูง: การใช้การกำหนดเวอร์ชันความหมายของฮาร์ดแวร์
ขั้นสูง: การใช้การกำหนดเวอร์ชันความหมายของฮาร์ดแวร์

ในการใช้ hardware semver ในโครงการของคุณเอง เราใช้คุณลักษณะ Git ที่เรียกว่าการแท็ก เมื่อคุณสร้างบอร์ดครั้งแรก นั่นคือเวอร์ชัน 1.0.0 ของบอร์ดนั้น ตรวจสอบให้แน่ใจว่าคุณได้ทำการเปลี่ยนแปลงทั้งหมดในโปรเจ็กต์ของคุณแล้ว จากนั้นเรียกใช้ `git tag -a v1.0.0` การดำเนินการนี้จะเปิดตัวแก้ไขเพื่อให้คุณสามารถเขียนข้อความคำอธิบายประกอบสำหรับแท็กนี้ (คล้ายกับข้อความยืนยันมาก) ฉันรวมรายละเอียดเกี่ยวกับการผลิต (ใครทำ PCB ใครประกอบบอร์ด) ซึ่งสามารถเป็นข้อมูลที่เป็นประโยชน์ในภายหลัง

แท็กการวางจำหน่ายจะถูกเพิ่มในประวัติการคอมมิตและระบุสถานะของไฟล์ที่การผลิต 1.0.0 สิ่งนี้มีประโยชน์อย่างยิ่งในการแก้ไขหลายๆ ครั้งในภายหลัง เมื่อคุณต้องการย้อนกลับไปที่จุดนี้เพื่อแก้ไขปัญหา หากไม่มีการระบุแท็กการวางจำหน่าย อาจเป็นเรื่องยากที่จะทราบว่าคอมมิตใดเป็นคอมมิตล่าสุดในขณะที่ทำการผลิต แท็ก 1.0.0 (และ 1.1, 1.1.1 เป็นต้น) ให้คุณระบุว่าไฟล์ต้นฉบับเหล่านี้เป็นไฟล์ที่ใช้ในการผลิตเฉพาะ

หมายเหตุเกี่ยวกับ Gerbers บ้าน fab บางหลังต้องการไฟล์ gerber เพื่อสร้างบอร์ดของคุณ และคุณสามารถสร้างได้ด้วย KiCad สิ่งเหล่านี้เป็นอ็อบเจ็กต์ที่ได้รับ ซึ่งสร้างขึ้นจากไฟล์.kicad_pcb ต้นทาง และปกติแล้วเราจะไม่ใช้ไฟล์ที่ได้รับการควบคุมเวอร์ชัน พวกเราที่ Brainbow จะไม่เก็บ gerbers ไว้ในการควบคุมเวอร์ชัน ยกเว้นเมื่อเราแท็กการเปิดตัว เมื่อเราพร้อมที่จะสร้าง เราจะสร้างไฟล์ gerber เก็บไว้ในโฟลเดอร์ Fabrication และคอมมิตและแท็ก จากนั้นเราลบ gerbers และทำการลบ สิ่งนี้อาจดูสับสนเล็กน้อยในตอนแรก แต่ช่วยให้แน่ใจว่าการคอมมิตปกติเก็บเฉพาะไฟล์ต้นฉบับเท่านั้น และรุ่นที่ติดแท็กจะเก็บไฟล์ที่แน่นอนที่ใช้ในการผลิตบอร์ด สิ่งนี้พิสูจน์แล้วว่ามีประโยชน์อย่างมากในการติดตามข้อผิดพลาดในการผลิตในสัปดาห์ต่อมา

ขั้นตอนที่ 10: ขั้นตอนถัดไป

หวังว่าบทนำนี้จะสอนคุณมากพอที่จะเริ่มใช้การควบคุมเวอร์ชันในโครงการอิเล็กทรอนิกส์ของคุณเอง เราไม่ได้พูดถึงหัวข้อขั้นสูงบางอย่าง เช่น การควบคุมเวอร์ชันสำหรับไลบรารีที่แชร์ระหว่างโปรเจ็กต์หรือสาขาของฟีเจอร์ การควบคุมเวอร์ชันก็เหมือนกับการกินผักของคุณ คุณอาจไม่ได้สิ่งที่คุณคิดว่าควร แต่ทุก ๆ บิตที่คุณได้รับนั้นมีค่า

Brainbow กำลังทำงานเกี่ยวกับคำแนะนำโดยละเอียดเพิ่มเติมเกี่ยวกับคุณลักษณะขั้นสูงบางอย่างของเวิร์กโฟลว์ของเรา เราหวังว่าจะเผยแพร่ได้ในอีกไม่กี่เดือนข้างหน้า ติดตามเราที่นี่ใน Instructables และเราจะแจ้งให้คุณทราบเมื่อคุณสามารถอ่านได้

ขอขอบคุณที่อ่านและเราแทบรอไม่ไหวที่จะได้เห็นสิ่งที่คุณทำ!

แนะนำ: