ვერსიის კონტროლი ღია აპარატურისთვის: 10 ნაბიჯი

2024 ავტორი: John Day | [email protected]. ბოლოს შეცვლილი: 2024-01-30 10:19

Brainbow– ს გუნდს აქვს მრავალი ელექტრონიკის პროექტი ჩვენს სარტყელში და ჩვენ გვსურს გავუზიაროთ ჩვენი ვერსია ვერსიის კონტროლის გამოყენებისათვის, ჩვენი ელექტრონიკის დიზაინის სამუშაო პროცესის სამართავად. ეს ნაკადი გამოიყენება დიდი და მცირე ზომის პროექტებისთვის, მარტივი 2 ფენის დაფებიდან დაწყებული კომპლექსური 10 ფენის ბეჰემოთებით და ემყარება ღია კოდის ინსტრუმენტებს. ვიმედოვნებთ, რომ სხვებს შეუძლიათ მიიღონ ჩვენი სამუშაო პროცესი საკუთარი თავისთვის და მიიღონ უპირატესობა ვერსიის კონტროლისთვის საკუთარი პროექტებისთვის. მაგრამ რა სარგებლობა შეიძლება მოჰყვეს ვერსიის კონტროლს ელექტრონიკის პროექტზე?

ნაბიჯი 1: რატომ აკონტროლებს ვერსია თქვენს ელექტრონიკას?

ვერსიის კონტროლი (ანუ წყაროს კონტროლი ან გადახედვის კონტროლი) არის კარგად გაგებული და ფართოდ გავრცელებული კონცეფცია პროგრამული უზრუნველყოფის ინჟინერიაში. წყაროს კონტროლის იდეა სისტემატურად აკონტროლებს პროგრამის ან პროგრამის კოდის ცვლილებებს. თუ ცვლილებები არღვევს პროგრამას, შეგიძლიათ დააბრუნოთ კოდის ფაილები წარსულის ცნობილ სამუშაო მდგომარეობაში. პრაქტიკაში, წყაროს კონტროლის სისტემები საშუალებას გაძლევთ თვალყური ადევნოთ ფაილების კოლექციის ისტორიას (ჩვეულებრივ წყაროს კოდის ფაილებს კომპიუტერული პროგრამისთვის, ვებსაიტისთვის და ა.შ.) და ამ ფაილების ცვლილებების ვიზუალიზაციას და მართვას.

პროექტის ცვლილებების ისტორიის თვალყურის დევნება სასარგებლოა ელექტრონიკის პროექტებისთვის; თუ თქვენ დაუშვებთ შეცდომას სქემატურ სქემაში, ან იყენებთ PCB– ის განლაგებაში არასწორი კომპონენტის ნაკვალევს, კარგი იქნება თვალყური ადევნოთ რა შეცდომებს დაუშვა და რა გამოსწორებები განხორციელდა პროექტის სხვადასხვა გადახედვაში. სხვა შემქმნელებისთვის ასევე სასარგებლო იქნება ამ ისტორიის დანახვა და სხვადასხვა ცვლილებების კონტექსტისა და მოტივაციის გაგება.

ნაბიჯი 2: ინსტრუმენტები: KiCad და Git

ჩვენ ვიყენებთ ორ მთავარ ინსტრუმენტს ამ პროექტში: ვერსიის კონტროლის სისტემა (VCS) და ელექტრონიკის დიზაინის ავტომატიზაციის პროგრამა (EDA ან ECAD).

არსებობს მრავალი ვერსიის კონტროლის სისტემა, მაგრამ ჩვენ ვიყენებთ განაწილებულ VCS Git- ს. ჩვენ ვიყენებთ მას მრავალი მიზეზის გამო, მაგრამ მთავარი ის არის, რომ ეს არის ღია წყარო (შემოწმება!), მარტივი გამოსაყენებლად (შემოწმება!) და დე-ფაქტო სტანდარტული VCS ღია კოდის პროგრამული უზრუნველყოფისთვის (შემოწმება!). ჩვენ ვიყენებთ Git– ს, როგორც VCS– ს, რათა თვალყური ადევნოს იმ ფაილების ცვლილებებს, რომლებსაც ჩვენი ECAD პროგრამა იყენებს. ეს ინსტრუქცია არ საჭიროებს Git– ის გაცნობას, მაგრამ ზოგადი კომფორტი ბრძანების ხაზის გამოყენებით არის გათვალისწინებული. შევეცდები საჭიროებისამებრ დავკავშირო Git და ბრძანების ხაზის გამოსადეგი რესურსები.

წყაროს კონტროლის სისტემების უმეტესობა განსაკუთრებით კარგად მუშაობს ტექსტზე დაფუძნებულ ფაილებზე, ამიტომ ECAD პროგრამა, რომელიც იყენებს ტექსტურ ფაილებს, შესანიშნავი იქნება. შეიყვანეთ KiCad, ღია კოდის "Cross Platform and Open Source Electronics Design Automation Suite", რომელსაც მხარს უჭერს CERN მკვლევარები. KiCad ასევე არის ღია წყარო (შეამოწმეთ!), ადვილად გამოსაყენებელი (თუმცა ზოგი არ დამეთანხმება ამაში) და ძალზედ ეფექტურია ელექტრონიკის დიზაინის მოწინავე სამუშაოებისთვის.

ნაბიჯი 3: ინსტალაცია

ამ პროგრამების დასაყენებლად მიჰყევით ქვემოთ მოცემულ ბმულებს ჩამოტვირთვის სხვადასხვა საიტების მითითებებს.

• KiCad არის მრავალ პლატფორმა (და თავბრუდამხვევიც; მათი გადმოტვირთვის გვერდი ჩამოთვლილია 13 მხარდაჭერილი ოპერაციული სისტემა და გთავაზობთ წყაროს კოდის გადმოტვირთვას, თუ არცერთი მათგანი არ გამოგადგებათ). გამოიყენეთ kicad- ერთიანი ნაგულისხმევი ინსტალაცია და არა ღამის განვითარების მშენებლობა. ბიბლიოთეკის დაყენების დამატებითი სურვილისამებრ იხილეთ ნაბიჯი 4.
• Git ასევე არის cross-platform. Windows- ის გამოყენებისას, მე გირჩევთ შთამბეჭდავ Git for Windows პროექტს უფრო სასარგებლო, სრულად გამორჩეული გამოცდილებისთვის.

ორივე ამ საიტზე არსებული ინსტალაციის დოკუმენტაცია იქნება უფრო სრულყოფილი ვიდრე ნებისმიერი აღწერილობა, რომელსაც შემიძლია აქ შემოგთავაზოთ. მას შემდეგ რაც ორივე პროგრამა გადმოწერილი და დაინსტალირებული იქნება, შეგიძლიათ კლონირება მოახდინოთ Brainbow– ს პროექტის შაბლონზე ჩვენი Github საცავიდან. Git clone ბრძანება იღებს სტრუქტურას `git clone {src directory} {target directory}`; ჩვენი პროექტისთვის გამოიყენეთ `git clone https://github.com/builtbybrainbow/kicad-starter.git {სამიზნე დირექტორია}.

Git repo– ს კლონირება კოპირების სპეციალური ფორმაა; როდესაც კლონირებთ პროექტს, თქვენ იღებთ რეპოში შემავალი ყველა ფაილის ასლს, ასევე პროექტის მთელ ისტორიას Git. ჩვენი რეპოს კლონირებით, თქვენ მიიღებთ პროექტის კატალოგს, რომელიც უკვე სტრუქტურირებულია ჩვენი რეკომენდაციებით Git KiCad– ით გამოყენებისათვის. ჩვენ უფრო მეტს გავაანალიზებთ პროექტის სტრუქტურაზე მე –6 ნაბიჯში, ან შეგიძლიათ გადახვიდეთ მე –7 საფეხურზე, თუ მუშაობის დაწყებისთანავე გტკივათ.

რამოდენიმე სწრაფი საშინაო დავალება - გაუშვით „git remote rm origin“, რათა ამოიღოთ ბმული Github პროექტთან, საიდანაც კლონირებული ხართ. ასევე, გაუშვით `git commit --amend --author =" John Doe ", შეცვალეთ ავტორის პარამეტრი თქვენი სახელით და ელ.ფოსტით. ეს ცვლის ბოლო ვალდებულებას (რომელიც ამ შემთხვევაში ასევე პირველია) და ცვლის ავტორს თქვენზე, ვიდრე Brainbow.

ნაბიჯი 4: ინსტალაციის შენიშვნა: KiCad ბიბლიოთეკები

ერთი სწრაფი შენიშვნა KiCad- ის ბიბლიოთეკის სტრუქტურის შესახებ. KiCad გთავაზობთ ბიბლიოთეკების კომპლექტს, რომელსაც ინახავს დეველოპერი გუნდი ელექტრო კომპონენტების ფართო სპექტრისთვის. არსებობს სამი ძირითადი ბიბლიოთეკა:

• სქემატური სიმბოლოები: სიმბოლოები, რომლებიც გამოიყენება ელექტრონული კომპონენტების წარმოსადგენად წრიულ სქემატურ ნახაზში.
• PCB ნაკვალევი: 2D ნახატები წარმოადგენს ნამდვილ ნაკვალევს (სპილენძის ბალიშები, აბრეშუმის ეკრანის ტექსტი და ა.შ.), რომელიც უნდა იქნას გამოყენებული PCB- ზე მიკროსქემის განლაგებისას.
• 3D მოდელები: ელექტრონული კომპონენტების 3D მოდელები.

ეს ბიბლიოთეკები გადმოწერილია თქვენ მიერ დაინსტალირებული KiCad პროგრამის პაკეტთან ერთად. თქვენ შეგიძლიათ გამოიყენოთ KiCad ყოველგვარი ძალისხმევის გარეშე. თუმცა, "მძლავრი მომხმარებლებისთვის", ბიბლიოთეკების საწყისი ფაილები ინახება Gitub– ის git საცავში, რაც საშუალებას აძლევს მომხმარებლებს, რომლებსაც სურთ უახლესი ცვლილებების განახლება, მოახდინონ ბიბლიოთეკის რეპოს საკუთარი მოწყობილობის კლონირება. Git ბიბლიოთეკებს თვალყურს ადევნებს უამრავ უპირატესობას - თქვენ შეგიძლიათ აირჩიოთ როდის გსურთ თქვენი ბიბლიოთეკების განახლება და განახლებებს მხოლოდ ფაილების ცვლილებები უნდა შეიცავდეს, ვიდრე ბიბლიოთეკის ფაილების მთელი ნაკრების ხელახლა გადმოტვირთვას. ამასთან, თქვენ პასუხისმგებელი ხართ ბიბლიოთეკების განახლებაზე, რომელთა დავიწყებაც ადვილი იქნება.

თუ გსურთ ბიბლიოთეკების კლონირება, ეს საიტი ასახავს სხვადასხვა Github საცავებს KiCad. Git დააკლონ ბიბლიოთეკები თქვენს კომპიუტერში (მაგ.: `git clone https:// github.com/KiCad/kicad-symbol.git`), შემდეგ გახსენით KiCad, შეარჩიეთ მენიუს ზოლი" პარამეტრები "და დააწკაპუნეთ" გზების კონფიგურაცია … ". ეს საშუალებას გაძლევთ უთხრათ KiCad– ს დირექტორია, რომ მოძებნოთ თითოეული ბიბლიოთეკა. გარემოს ეს ცვლადები ნაგულისხმევია KiCad ინსტალაციით დაინსტალირებული ბიბლიოთეკების გზაზე; მე გავითვალისწინე ეს ღირებულებები, რათა საჭიროების შემთხვევაში შევძლო ნაგულისხმევ ბიბლიოთეკებზე დაბრუნება. KICAD_SYMBOL_DIR გზა უნდა მიუთითებდეს თქვენს კლონირებულ კიკად-სიმბოლოების ბიბლიოთეკაზე, KISYSMOD კლონირებული კიკად-ნაკვალევის ბიბლიოთეკაზე და KISYS3DMOD კლონირებულ კიკად-პაკეტებზე 3 ბიბლიოთეკას.

როდესაც გსურთ ბიბლიოთეკების განახლება, შეგიძლიათ ბიბლიოთეკის რეპში გაუშვათ მარტივი ბრძანება `git pull`, რომელიც Git- ს მოუწოდებს შეამოწმოს განსხვავებები ბიბლიოთეკის რეპოს ადგილობრივ ასლსა და Github“დისტანციურ”რეპოს შორის და ავტომატურად განაახლოთ თქვენი ადგილობრივი ასლი, რათა შეიტანოს ცვლილებები.

ნაბიჯი 5: Git საფუძვლები

Git არის რთული და მრავალმხრივი პროგრამა, მთელი წიგნები ეძღვნება მის დაუფლებას. ამასთან, არსებობს რამდენიმე მარტივი კონცეფცია, რომელიც დაგეხმარებათ გაიგოთ, თუ როგორ ვიყენებთ Git– ს სამუშაო პროცესში.

Git თვალყურს ადევნებს ფაილების ცვლილებებს მთელი რიგი ეტაპების გამოყენებით. ნორმალური ცვლილებები ხდება სამუშაო დირექტორიაში. როდესაც კმაყოფილი იქნებით ფაილების სერიაში შეტანილი ცვლილებებით, თქვენ დაამატებთ თქვენს შეცვლილ ფაილებს დადგმის არეზე. მას შემდეგ რაც თქვენ განახორციელეთ ყველა ის ცვლილება, რასაც გეგმავთ და დადგამთ ყველა იმ ფაილს, რომლის ნახვა გსურთ Git– ში, თქვენ განახორციელებთ ამ ცვლილებებს საცავში. საკომისიო არის არსებითად გადაღებული ფაილების მდგომარეობა რეპოში კონკრეტულ დროს. მას შემდეგ, რაც Git აკონტროლებს ფაილების ცვლილებებს და ინახავს ამ ცვლილებებს საკომისიოებში, ნებისმიერ მომენტში შეგიძლიათ დააბრუნოთ პროექტი იმ მდგომარეობაში, როგორიც იყო ნებისმიერ წინა ვალდებულებაში.

არსებობს უფრო რთული თემები, როგორიცაა განშტოება და დისტანციური მართვა, მაგრამ ჩვენ არ გვჭირდება მათი გამოყენება წყაროს კონტროლის სარგებლის მოსაპოვებლად. ყველაფერი რაც ჩვენ გვჭირდება არის თვალყური ვადევნოთ KiCad დიზაინის ფაილების ცვლილებებს მთელი რიგი ვალდებულებებით.

ნაბიჯი 6: KiCad პროექტის სტრუქტურა

მოდით უფრო ახლოს განვიხილოთ KiCad-Starter პროექტის სტრუქტურა, რომელიც თქვენ ადრე კლონირებული გაქვთ. იგი იყოფა რამდენიმე ქვე დირექტორიაში მარტივი ორგანიზაციისათვის:

• წრე: ეს საქაღალდე შეიცავს KiCad პროექტის რეალურ ფაილებს (სქემატური, PCB და სხვა). მე არ ვასახელებ ამ საქაღალდეს, მაგრამ ვასახელებ ყველა ფაილს შიგნით პროექტის სახელით (Circuit.pro => ArduinoMini.pro).

  • Circuit.pro: KiCad პროექტის ფაილი
  • Circuit.sch: KiCad სქემატური ფაილი.
  • Circuit.kicad_pcb: KiCad PCB განლაგების ფაილი.
• დოკუმენტაცია: ეს საქაღალდე არის პროექტთან დაკავშირებული დოკუმენტაციის შესანახად. ჩვენ გვაქვს გეგმები მომავალში ამ სივრცის გასაუმჯობესებლად, მაგრამ ჯერჯერობით ის შეიცავს მარტივ README ფაილს. გამოიყენეთ იგი შენიშვნების შესანახად პროექტზე, რათა მომავალში გადახედოთ.
• დამზადება: ეს საქაღალდე არის იქ, სადაც თქვენ შეინახავთ გერბერის ფაილებს, რომლებსაც ბევრი სახლის სახლი გამოიყენებს თქვენი მიკროსქემის დაფის დასამზადებლად. ჩვენ ასევე ვიყენებთ მას BOM ფაილების და სხვა დოკუმენტების შესანახად, რომლებიც შეიძლება საჭირო იყოს წარმოებისა და შეკრებისთვის.
• ბიბლიოთეკები: ეს საქაღალდე განკუთვნილია პროექტის სპეციფიკური ბიბლიოთეკის ფაილების შესანახად (ჩვენ ამას უფრო მეტს განვიხილავთ რამდენიმე ნაბიჯში).

თქვენ შეიძლება ასევე შენიშნეთ რამდენიმე სხვა ფაილი (განსაკუთრებით თუ თქვენ ls –a) დირექტორია).. Git დირექტორია, სადაც Git აკეთებს მაგიას, ინახავს საცავის ისტორიას.. Gitignore ფაილი გამოიყენება Git– ის სათქმელად, რომელი ფაილების იგნორირება უნდა მოახდინოს და არ შეინახოს წყაროს კონტროლში. ეს არის ძირითადად სარეზერვო ფაილები, რომლებსაც KiCad ქმნის, ან რამდენიმე განსხვავებული "გენერირებული" ფაილი, როგორიცაა ნეტლისტები, რომლებიც არ უნდა იყოს შენახული წყაროს კონტროლში, რადგან ისინი წარმოიქმნება სქემატური ფაილის წყაროდან.

პროექტის სტრუქტურა მხოლოდ ამოსავალი წერტილია. თქვენ უნდა მოერგოთ იგი თქვენს საჭიროებებს და საჭიროების შემთხვევაში დაამატოთ სექციები. ზოგიერთ პროექტში ჩვენ შევიტანეთ პროგრამული უზრუნველყოფის საქაღალდე ან დანართის საქაღალდე, სადაც ჩვენ ვინახავთ მოდელებს პროექტის 3D ბეჭდვისთვის.

ნაბიჯი 7: Git- ის გამოყენება KiCad პროექტებისთვის

ჩვენ საბოლოოდ მზად ვართ ვნახოთ, როგორ გამოვიყენოთ Git თქვენი პროექტების თვალთვალისთვის. ეს ინსტრუქცია არ ნიშნავს იმას, რომ გასწავლოთ KiCad– ის გამოყენება (თუმცა მომავალში შემიძლია ამის გაკეთება, თუკი მასზე მოთხოვნაა), ამიტომ ჩვენ განვიხილავთ რამდენიმე უმნიშვნელო მაგალითს, რათა გაჩვენოთ როგორ მუშაობს სამუშაო პროცესი. ადვილი უნდა იყოს იმის გაგება, თუ როგორ უნდა მოერგოს ეს იდეები რეალურ პროექტს.

გახსენით kicad-starter დირექტორია, შემდეგ გაუშვით `git log` ვალდებულების ისტორიის საჩვენებლად. აქ უნდა იყოს ერთი ვალდებულება, ბრეინბოუს მიერ რეპოს ინიციალიზაცია. გაშვებული `git status` გეტყვით ფაილების სტატუსს თქვენს რეპოში (დაუკვირვებელი, შეცვლილი, წაშლილი, დადგმული).

ამ დროისთვის, თქვენ არ უნდა გქონდეთ ცვლილებები თქვენს რეპოში. მოდით შევცვალოთ. გახსენით KiCad პროექტი და დაამატეთ რეზისტორი სქემაში, შემდეგ შეინახეთ. ახლა გაშვებული `git სტატუსი should უნდა აჩვენებდეს, რომ თქვენ შეცვალეთ სქემატური ფაილი, მაგრამ ჯერ არ დადგათ ეს ცვლილებები ჩადენისთვის. თუ გაინტერესებთ რა გააკეთა KiCad რეზისტორის დამატებისას, შეგიძლიათ გაუშვათ diff ბრძანება შეცვლილ ფაილზე `git diff Circuit/Circuit.sch`. ეს ხაზს უსვამს ცვლილებებს სამუშაო დირექტორიაში არსებული ფაილის მიმდინარე ვერსიასა და ფაილის ბოლო მდგომარეობას შორის.

ახლა, როდესაც ჩვენ გავაკეთეთ ცვლილება, შევეცადოთ შევიტანოთ ეს ცვლილება ჩვენი პროექტის ისტორიაში. ჩვენ უნდა გადავიტანოთ ცვლილებები ჩვენი სამუშაო დირექტორიადან დადგმის არეზე. ეს ფაქტობრივად არ გადააქვს ფაილები ფაილურ სისტემაში, მაგრამ კონცეპტუალურად არის საშუალება აცნობოს Git– ს, რომ თქვენ გააკეთეთ ყველა დაგეგმილი ცვლილება კონკრეტული ფაილისთვის და მზად ხართ განახორციელოთ ეს ცვლილებები. დამხმარედ, Git გთავაზობთ რამდენიმე მინიშნებას, როდესაც თქვენ აწარმოებთ `git სტატუსს next შემდეგი მოქმედებისთვის. ყურადღება მიაქციეთ შეტყობინებას `(გამოიყენეთ" git add… ", რათა განაახლოთ რა იქნება ჩადენილი)` `ჩადენისთვის დადგმული ცვლილებები:`. Git გეუბნებათ, როგორ გადაიტანოთ ცვლილებები დადგმის არეზე. გაუშვით `git add Circuit/Circuit.sch` ცვლილებების დასადგმელად, შემდეგ` git status` რომ ნახოთ რა მოხდა. ახლა ჩვენ ვხედავთ სქემატურ ფაილს ცვლილებების ქვეშ. თუ თქვენ ჯერ არ გსურთ ამ ცვლილებების განხორციელება, Git დამხმარედ გვთავაზობს სხვა რჩევას: `(unstage to use“git reset HEAD…”). ჩვენ ნამდვილად გვინდა ამ ცვლილებების განხორციელება, ამიტომ ჩვენ ვაწარმოებთ `git commit -m" დამატებულია რეზისტორი სქემატურში ". ეს იწვევს ცვლილებებს მოწოდებული შეტყობინებით. გაშვებული git log აჩვენებს ამ ვალდებულებას პროექტის ჩადენის ისტორიაში.

კიდევ რამდენიმე რჩევა ვალდებულებების შესახებ.

1. ნუ ჩაიდენთ ყოველ დაზოგვას. შეასრულეთ ვალდებულება, როდესაც იგრძნობთ, რომ მიაღწიეთ იმ დონეს, როდესაც თქვენი ცვლილებები გარკვეულწილად გამყარდა. მე ვალდებულებას ვიღებ სქემატური დასრულების შემდეგ და არა ყოველი კომპონენტის დამატების შემდეგ. თქვენ ასევე არ გინდათ ძალიან იშვიათად ჩაიდინოთ ვალდებულება, რადგან ძნელია დაიმახსოვროთ ის კონტექსტი, თუ რატომ შეიტანეთ ცვლილებები 3 კვირის შემდეგ. იმის გარკვევა, თუ როდის უნდა ჩაიდინოთ ეს არის გარკვეული ხელოვნება, მაგრამ თქვენ უფრო კომფორტულად იგრძნობთ თავს Git- ს უფრო მეტად გამოყენებისას.
2. მხოლოდ მაღაზიის წყარო (ძირითადად). ეს მოიცავს პროექტის, სქემატური და განლაგების ფაილებს, ასევე პროექტის სპეციფიკურ ბიბლიოთეკებს. ეს ასევე შეიძლება შეიცავდეს დოკუმენტაციის ფაილებს. ფრთხილად იყავით წარმოებული საგნების შენახვისას, რადგან მათ ადვილად შეუძლიათ სინქრონიზაცია გაუწიონ საწყის წყაროსთან და ეს იწვევს თავის ტკივილს მოგვიანებით. BOM და გერბერის ფაილები განსაკუთრებით მარტივად ხდება დე-სინქრონიზებული, ამიტომ უკეთესია მათი თავიდან აცილება (თუმცა უფრო დეტალური მითითებები მოცემულია მე –9 ნაბიჯში).
3. ჩადენილი შეტყობინებები ძალიან სასარგებლოა, მაგრამ კარგად სტრუქტურირებული ჩადენილი შეტყობინებები ფასდაუდებელია. ეს შესანიშნავი სტატია გთავაზობთ რამდენიმე მითითებას მკაფიო, ლაკონური, სასარგებლო შეტყობინებების დასაწერად. ამის გაკეთება შეიძლება მოითხოვდეს ბრძანების ხაზის ტექსტური რედაქტორის გამოყენებას, რაც დამწყებთათვის გართულებულია (`git commit` -m შეტყობინების ვარიანტის გარეშე ტექსტის რედაქტორს გახსნის). ადამიანების უმეტესობისთვის ვურჩევ ნანოს რედაქტორს. StackOverflow– ს აქვს კარგი ახსნა თქვენი რედაქტორის შეცვლის შესახებ

ნაბიჯი 8: გაფართოებული: სემანტიკური ვერსია ელექტრონიკისთვის

ავანტიურისტი სულებისთვის, შემდეგი რჩევები არის მოწინავე იდეები, რომლებიც მოპოვებულია KiCad– ის განვითარების მრავალი საათის განმავლობაში. ისინი არ არიან განსაკუთრებით გამოსადეგი მცირე პროექტებზე, მაგრამ მათ ნამდვილად შეუძლიათ გადაარჩინონ თქვენი გულისტკივილი, როდესაც თქვენი პროექტები იზრდება სირთულეში.

პროგრამულ უზრუნველყოფაში არსებობს სემანტიკური ვერსიის (სემვერის) კონცეფცია. სემვერი განსაზღვრავს დასახელების საერთო მეთოდოლოგიას პროგრამული უზრუნველყოფის გამოშვების იდენტიფიცირებისათვის "ვერსიის ნომრით", "Major. Minor. Patch" - ის ნიმუშის მიხედვით. სემვერის სპეციფიკაციის ციტირებისთვის, თქვენ ამატებთ ვერსიის ნომერს შემდეგი ცვლილებების კატეგორიების მიხედვით.

1. ძირითადი ვერსია, როდესაც თქვენ შეუთავსებთ API ცვლილებებს,
2. უმნიშვნელო ვერსია, როდესაც დაამატებთ ფუნქციონირებას უკანა თავსებადი გზით,
3. PATCH ვერსია, როდესაც თქვენ აკეთებთ უკანა მხარეს თავსებადი შეცდომების გამოსწორებას.

ჩვენ Brainbow- ში ვიყენებთ სემვერის საკუთარ ვერსიას, რომელიც ადაპტირებულია ტექნიკური პროექტების საჭიროებებზე. ჩვენი სპეციფიკა მიჰყვება იგივე "Major. Minor. Patch" შაბლონს, თუმცა ჩვენი განმარტებები რა ცვლილებებს მიეკუთვნება რომელ კატეგორიას აშკარად განსხვავდება.

1. ძირითადი ვერსია: გამოიყენება სქემის ძირითადი ფუნქციონირების მნიშვნელოვანი ცვლილებებისთვის (მაგ.: პროცესორის გადართვა ATmegaa– დან ESP8266– ზე).
2. მცირე ვერსია: გამოიყენება კომპონენტების გაცვლისთვის, რამაც შეიძლება გავლენა მოახდინოს მიკროსქემის მუშაობაზე (მაგ.: SPI ფლეშ სვოპი პინ-თავსებადი ნაწილით, რომელსაც შეიძლება ჰქონდეს განსხვავებული ბრძანება) ან რაიმე დამატებითი დამატებითი ფუნქციის დამატება (მაგ.: დამატებითი ტემპერატურის სენსორი).
3. PATCH ვერსია: გამოიყენება უმნიშვნელო ხარვეზების გამოსასწორებლად, რომლებიც არ შეცვლიან მიკროსქემის მუშაობას (მაგ.: აბრეშუმის ეკრანის მორგება, მცირე ზომის კვალის განლაგება, მარტივი კომპონენტის შეცვლა 0603 კონდენსატორის მსგავსად 0805).

აპარატურულ სემვერში, ვერსიის ნომერი განახლებულია მხოლოდ წარმოების პროცესში (ისევე როგორც პროგრამულ უზრუნველყოფაში, ვერსიის ნომრები იცვლება მხოლოდ გამოშვებით, ყველა ინდივიდუალური არ ასრულებს პროექტს). შედეგად, ბევრ პროექტს აქვს დაბალი ვერსიის ნომრები. ჩვენ ჯერ არ გვაქვს პროექტი, რომელიც გამოიყენებს 4 -ზე მეტ ძირითად ვერსიას.

თანმიმდევრულობისა და გასაგები სარგებლის გარდა, თქვენ იღებთ დასახელებული დასახელების სისტემაზე გადასვლას, თქვენ ასევე მიიღებთ სარგებელს firmware- ის თავსებადობით და მომხმარებლის კმაყოფილებით. Firmware შეიძლება დაიწეროს დაფის ვერსიის გათვალისწინებით, რომელსაც ის მიზნად ისახავს და უფრო ადვილი იქნება მისი გამართვა, თუ რატომ არ მუშაობს კონკრეტული პროგრამა კონკრეტულ დაფაზე ("მართალია, 2.4.1 firmware არ მუშაობს 1.2 -ზე დაფები, რადგან ჩვენ არ გვაქვს … "). მომხმარებლებმა ასევე ისარგებლეს ჩვენი აპარატურის სემვერით, რადგან მომხმარებელთა მომსახურება და პრობლემების მოგვარება ბევრად უფრო ადვილია განსაზღვრული სტანდარტით.

ნაბიჯი 9: მოწინავე: აპარატურის სემანტიკური ვერსიის გამოყენება

აპარატურის სემვერის გამოსაყენებლად საკუთარ პროექტებში, ჩვენ ვიყენებთ Git ფუნქციას სახელწოდებით tagging. როდესაც თქვენ პირველად აწარმოებთ დაფას, ეს არის ამ დაფის 1.0.0 ვერსია. დარწმუნდით, რომ თქვენ განახორციელეთ ყველა ცვლილება თქვენს პროექტში, შემდეგ გაუშვით `git tag -a v1.0.0`. ეს გახსნის რედაქტორს, ასე რომ თქვენ შეგიძლიათ დაწეროთ ანოტაციის შეტყობინება ამ ტეგზე (ძალიან ჰგავს ჩადენის შეტყობინებას). მე ვამატებ დეტალებს წარმოების შესახებ (ვინ გააკეთა PCB, ვინ შეიკრიბა დაფა), რაც მოგვიანებით სასარგებლო ინფორმაცია იქნება.

გამოშვების ნიშანი ემატება ჩადენის ისტორიას და მიუთითებს 1.0.0 წარმოების ფაილების მდგომარეობაზე. ეს შეიძლება იყოს განსაკუთრებით სასარგებლო რამდენიმე გადასინჯვა მოგვიანებით, როდესაც თქვენ უნდა მიმართოთ ამ წერტილს პრობლემების აღმოსაფხვრელად. გათავისუფლების მითითებული ნიშნის გარეშე, ძნელი იქნება იმის გარკვევა, თუ რომელი ჩადენა იყო უახლესი წარმოების დროს. 1.0.0 (და 1.1, 1.1.1 და ა.შ.) ტეგი გაძლევთ საშუალებას მიუთითოთ, რომ ეს კონკრეტული წყაროს ფაილები იყო ის, რაც გამოიყენებოდა წარმოების კონკრეტულ პერიოდში.

შენიშვნა გერბერზე. ზოგიერთი ფანტასტიკური სახლი მოითხოვს გერბერის ფაილებს თქვენი დაფის დასამზადებლად და თქვენ შეგიძლიათ შექმნათ ისინი KiCad– ით. ეს არის მიღებული ობიექტები, რომლებიც წარმოიქმნება.kicad_pcb ფაილიდან და ჩვენ ჩვეულებრივ არ ვაკონტროლებთ მიღებული ფაილებს. ჩვენ Brainbow– ში არ ვინახავთ გერბერებს ვერსიის კონტროლში, გარდა იმ შემთხვევისა, როდესაც გამოშვებას მონიშნავთ. როდესაც ჩვენ მზად ვართ ასაშენებლად, ჩვენ ვქმნით გერბერის ფაილებს, ვინახავთ მათ Fabrication საქაღალდეში და ვაკეთებთ ჩანაწერს. შემდეგ ჩვენ ამოვიღებთ გერბერებს და ვაკეთებთ წაშლას. ეს შეიძლება თავიდან ცოტა გაუგებრად მოგეჩვენოთ, მაგრამ ის უზრუნველყოფს, რომ ნორმალური ჩანაწერები ინახავს მხოლოდ წყაროს ფაილებს, ხოლო მონიშნული რელიზები ასევე ინახავს ზუსტ ფაილებს, რომლებიც გამოიყენება დაფების დასამზადებლად. ეს საოცრად სასარგებლო აღმოჩნდა რამდენიმე კვირის შემდეგ წარმოების შეცდომების დასადგენად.

ნაბიჯი 10: შემდეგი ნაბიჯები

ვიმედოვნებთ, რომ ეს შესავალი საკმარისად გასწავლით, რომ დაიწყოთ ვერსიის კონტროლის გამოყენება საკუთარ ელექტრონიკურ პროექტებზე. ჩვენ არ მივედით ზოგიერთ უფრო მოწინავე თემასთან, როგორიცაა ბიბლიოთეკების ვერსიის კონტროლი პროექტებსა თუ მხატვრულ ფილიალებს შორის. მიუხედავად ამისა, ვერსიის კონტროლი ჰგავს თქვენი ბოსტნეულის ჭამას: თქვენ შეიძლება არ მიიღოთ ის, რაც თქვენ გგონიათ, მაგრამ ყოველი ის, რასაც აკეთებთ, ითვლის.

Brainbow მუშაობს უფრო დეტალურ სახელმძღვანელოზე ჩვენი მუშაობის ნაკადის ზოგიერთი უფრო მოწინავე მახასიათებლისთვის. ვიმედოვნებთ, რომ გამოქვეყნდება მომდევნო რამდენიმე თვის განმავლობაში. მოგვყევით აქ ინსტრუქციებზე და ჩვენ აუცილებლად შეგატყობინებთ, როდესაც წაიკითხავთ.

გმადლობთ კითხვისთვის და ჩვენ ვერ დაველოდებით, თუ რას გააკეთებთ!