Բաց կոդով սարքավորման տարբերակի վերահսկում. 10 քայլ

2024 Հեղինակ: John Day | [email protected]. Վերջին փոփոխված: 2024-01-30 09:49

Brainbow- ի թիմը մի շարք էլեկտրոնային նախագծեր ունի մեր գոտու տակ, և մենք ցանկանում էինք կիսել տարբերակների վերահսկման օգտագործման մեր ընթացքը `էլեկտրոնիկայի դիզայնի աշխատանքային հոսքը կառավարելու համար: Այս աշխատանքային հոսքն օգտագործվել է մեծ ու փոքր նախագծերի համար ՝ պարզ 2 շերտանի տախտակներից մինչև բարդ 10 շերտանոց բեհեմոթներ և հիմնված է բաց կոդով գործիքների վրա: Հուսանք, որ ուրիշները կարող են մեր աշխատանքային հոսքն ընդունել իրենց համար և ձեռք բերել տարբերակների վերահսկման առավելությունները սեփական նախագծերի համար: Բայց ի՞նչ առավելություններ կարող է ունենալ տարբերակի վերահսկումը էլեկտրոնիկայի նախագծի համար:

Քայլ 1. Ինչու՞ է տարբերակը վերահսկում ձեր էլեկտրոնիկան:

Տարբերակի վերահսկում (նույն աղբյուրի վերահսկում կամ վերանայման հսկողություն) լավ հասկացված և լայնորեն ընդունված հասկացություն է ծրագրային ապահովման ճարտարագիտության մեջ: Աղբյուրի վերահսկողության գաղափարը համակարգված կերպով հետևում է ծրագրի կամ ծրագրի աղբյուրի կոդի փոփոխություններին: Եթե փոփոխությունները խախտում են ծրագիրը, կարող եք աղբյուրի կոդի ֆայլերը վերադարձնել անցյալից հայտնի աշխատանքային վիճակին: Գործնականում աղբյուրների կառավարման համակարգերը թույլ են տալիս հետևել ֆայլերի հավաքածուի պատմությանը (սովորաբար համակարգչային ծրագրի, կայքի և այլնի աղբյուրի կոդերի ֆայլերը) և պատկերացնել և կառավարել այդ ֆայլերի փոփոխությունները:

Projectրագրի փոփոխությունների պատմությանը հետևելը օգտակար է թվում էլեկտրոնային նախագծերի համար. եթե սխալի սխեմայի մեջ սխալի դեպքում կամ PCB- ի դասավորության մեջ սխալ բաղադրիչ հետք եք օգտագործում, լավ կլիներ հետևել, թե ինչ սխալներ են թույլ տրվել և ինչ շտկումներ են իրականացվել նախագծի տարբեր վերանայումներում: Այլ ստեղծողների համար նույնպես օգտակար կլինի տեսնել այդ պատմությունը և հասկանալ տարբեր փոփոխությունների ենթատեքստը և շարժառիթները:

Քայլ 2: Գործիքներ. KiCad և Git

Այս նախագծում մենք օգտագործում ենք երկու հիմնական գործիք ՝ տարբերակի կառավարման համակարգը (VCS) և էլեկտրոնիկայի նախագծման ավտոմատացման ծրագիրը (EDA կամ ECAD):

Կան բազմաթիվ տարբերակների կառավարման համակարգեր, բայց մենք օգտագործում ենք բաշխված VCS Git- ը: Մենք այն օգտագործում ենք մի շարք պատճառներով, բայց առանցքայինն այն է, որ այն բաց կոդով է (ստուգեք), հեշտ է օգտագործել (ստուգեք) և դե-ֆակտո ստանդարտ VCS բաց կոդով ծրագրակազմի համար (ստուգեք): Մենք կօգտագործենք Git- ը որպես VCS ՝ մեր ECAD ծրագրի օգտագործած ֆայլերի փոփոխություններին հետևելու համար: Այս Instructable- ը չի պահանջում Git- ի հետ ծանոթություն, բայց ենթադրվում է, որ ընդհանուր հարմարավետությունը `օգտագործելով հրամանի տողը: Ես կփորձեմ անհրաժեշտության դեպքում կապել ինչպես Git- ի, այնպես էլ հրամանի տողի օգտագործման օգտակար ռեսուրսների հետ:

Աղբյուրի կառավարման համակարգերի մեծ մասը հատկապես լավ է աշխատում տեքստային ֆայլերի համար, ուստի ECAD ծրագիրը, որն օգտագործում է տեքստային ֆայլեր, հիանալի կլինի: Մուտքագրեք KiCad- ը ՝ բաց կոդով «Cross Platform and Open Source Electronics Design Automation Suite», որն ապահովված է CERN- ի հետազոտողների կողմից: KiCad- ը նաև բաց կոդով է (ստուգեք!), Օգտագործման համար դյուրին (չնայած ոմանք դրանում կհամաձայնվեն ինձ հետ) և բարձր ունակություն էլեկտրոնիկայի դիզայնի առաջադեմ աշխատանքի համար:

Քայլ 3: Տեղադրում

Այս ծրագրերը տեղադրելու համար հետևեք դրանց ներբեռնման տարբեր կայքերից տրված հրահանգներին ՝ ստորև նշված հղումով:

• KiCad- ը բազմաֆունկցիոնալ է (և գլխապտույտ առաջացնող. Նրանց ներբեռնման էջը թվարկում է 13 օժանդակ ՕՀ-եր և առաջարկում է կոդի ներբեռնում, եթե դրանցից ոչ մեկը ձեզ չի համապատասխանում): Օգտագործեք kicad- ի միասնական կանխադրված տեղադրումը, այլ ոչ թե գիշերային զարգացման կառուցվածքը: Գրադարանի տեղադրման լրացուցիչ ընտրովի մանրամասների համար տե՛ս 4 -րդ քայլը:
• Git- ը նաև խաչաձեւ հարթակ է: Եթե օգտագործում եք 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- ի հետ Git- ի օգտագործման մեր առաջարկություններով: Moreրագրի կառուցվածքի մասին ավելի մանրամասն կանդրադառնանք Քայլ 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- ը առանց այլ ջանքերի: Այնուամենայնիվ, «հզոր օգտվողների» համար գրադարանների սկզբնական ֆայլերը պահվում են Github- ի git պահոցում ՝ թույլ տալով այն օգտվողներին, ովքեր ցանկանում են ամենավերջին տեղեկացված լինել, գրադարանային ռեպոները սեփական մեքենայի վրա կլոնավորեն: Git- ով գրադարաններին հետևելը մի շարք առավելություններ ունի. Դուք կարող եք ընտրել, թե երբ եք ցանկանում թարմացնել ձեր գրադարանները, և թարմացումները պետք է ներառեն միայն ֆայլերի փոփոխություններ, այլ ոչ թե նորից ներբեռնեն գրադարանային ֆայլերի ամբողջ փաթեթը: Այնուամենայնիվ, դուք պատասխանատու եք գրադարանները թարմացնելու համար, որոնց մասին մոռանալը հեշտ է:

Եթե ցանկանում եք կլոնավորել գրադարանները, այս կայքը մանրամասնում է KiCad- ի Github- ի տարբեր ռեպո առաջարկները: Git- ը գրադարանները կլոնավորի ձեր համակարգչին (օր. ՝ git clone https:// github.com/KiCad/kicad -mbol.git`), այնուհետև բացեք KiCad- ը, ընտրեք «Նախապատվություններ» ցանկի տողը և կտտացրեք «Կարգավորել ուղիներ… . Սա թույլ է տալիս KiCad- ին ասել գրացուցակի ուղին ՝ յուրաքանչյուր գրադարան փնտրելու համար: Այս միջավայրի փոփոխականները կանխադրված են KiCad- ի տեղադրմամբ տեղադրված գրադարանների ճանապարհին: Ես ուշադրություն դարձրի այս արժեքներին, որպեսզի անհրաժեշտության դեպքում կարողանամ վերադառնալ կանխադրված գրադարաններին: KICAD_SYMBOL_DIR ուղին պետք է մատնանշի ձեր կլոնավորված քիքադ-խորհրդանիշների գրադարանը, KISYSMOD- ը ՝ դեպի կլիկավորված քիքադ-ոտնահետքերի գրադարանը և KISYS3DMOD- ը դեպի կլոնավորված kicad-packages3d գրադարանը:

Երբ ցանկանում եք գրադարանները թարմացնել, կարող եք գրադարանի repo- ում գործարկել մի պարզ «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- ը, կամ մի քանի տարբեր «գեներացված» ֆայլեր, ինչպիսիք են ցանցացանկերը, որոնք չպետք է պահվեն աղբյուրի վերահսկողության ներքո, քանի որ դրանք գեներացվում են սխեմատիկ ֆայլ հանդիսացող աղբյուրից:

Projectրագրի այս կառուցվածքը պարզապես մեկնակետ է: Դուք պետք է այն հարմարեցնեք ձեր կարիքներին համապատասխան և ըստ անհրաժեշտության ավելացրեք հատվածներ: Որոշ նախագծերում մենք ներառել ենք ծրագրային ապահովման թղթապանակ կամ պարիսպի թղթապանակ, որտեղ մենք նախագծի համար պահում էինք մոդելներ 3D տպագրության պատյանների համար:

Քայլ 7: Git- ի օգտագործումը KiCad նախագծերի համար

Մենք վերջապես պատրաստ ենք տեսնել, թե ինչպես օգտագործել Git- ը ՝ ձեր նախագծերին հետևելու համար: Այս Instructable- ը նախատեսված չէ ձեզ սովորեցնել, թե ինչպես օգտագործել KiCad- ը (չնայած ես կարող եմ դա անել ապագայում, եթե դրա պահանջարկը լինի), ուստի մենք կներկայացնենք մի քանի աննշան օրինակներ ՝ ցույց տալու համար, թե ինչպես է ընթանում աշխատանքային հոսքը: Պետք է հեշտ լինի հասկանալ, թե ինչպես կարելի է այդ գաղափարները հարմարեցնել իրական նախագծին:

Բացեք kicad-starter գրացուցակը, այնուհետև գործարկեք `git log` ՝ կատարման պատմությունը ցուցադրելու համար: Այստեղ պետք է լինի մեկ պարտավորություն ՝ Brainbow- ի կողմից ռեպոյի նախաստորագրումը: «Git status» - ի գործարկումը ձեզ կպատմի ձեր ռեպոյի ֆայլերի կարգավիճակը (չստուգված, փոփոխված, ջնջված, բեմադրված):

Այս պահին դուք չպետք է փոփոխություններ ունենաք ձեր ռեպոում: Եկեք փոփոխություն կատարենք: Բացեք KiCad նախագիծը և սխեմային ավելացրեք դիմադրություն, այնուհետև պահեք: Այժմ «git status» - ի գործարկումը պետք է ցույց տա, որ դուք փոփոխել եք սխեմատիկ ֆայլը, բայց դեռ չեք կատարել այդ փոփոխությունները կատարման համար: Եթե ձեզ հետաքրքրում է, թե կոնկրետ ինչ արեց KiCad- ը ՝ դիմադրիչն ավելացնելիս, կարող եք գործարկել diff հրամանը ՝ git diff Circuit/Circuit.sch փոփոխված ֆայլի վրա: Սա ընդգծելու է փոփոխությունները աշխատանքային գրացուցակում առկա ֆայլի տարբերակի և վերջին կատարման ֆայլի վիճակի միջև:

Այժմ, երբ մենք փոփոխություն ենք կատարել, եկեք փորձենք այդ փոփոխությունը կատարել մեր նախագծի պատմության մեջ: Մենք պետք է փոփոխությունները մեր աշխատանքային գրացուցակից տեղափոխենք բեմադրության տարածք: Սա իրականում չի տեղափոխում ֆայլերի ֆայլային համակարգը, այլ հայեցակարգային եղանակ է, որը թույլ է տալիս Git- ին իմանալ, որ դուք կատարել եք ձեր ծրագրած բոլոր փոփոխությունները որոշակի ֆայլի համար և պատրաստ եք կատարել դրանք: Օգտակար է, Git- ը տալիս է որոշ հուշումներ, երբ հաջորդ գործողության համար գործարկում եք «git կարգավիճակը»: Ուշադրություն դարձրեք ՝ Git- ը ձեզ պատմում է, թե ինչպես տեղափոխել փոփոխությունները բեմադրության տարածք: Գործարկեք «git add Circuit/Circuit.sch» ՝ փոփոխությունները բեմադրելու համար, այնուհետև ՝ «git status» ՝ տեսնելու, թե ինչ է տեղի ունեցել: Այժմ մենք տեսնում ենք, որ սխեմատիկ ֆայլը ենթակա է փոփոխությունների: Եթե դեռ չեք ցանկանում կատարել այս փոփոխությունները, Git- ը օգտակար կերպով առաջարկում է ևս մեկ հուշում. Մենք իսկապես ցանկանում ենք կատարել այս փոփոխությունները, ուստի մենք գործարկում ենք `git commit -m« Ավելացված դիմադրություն սխեմատիկին »: Սա փոփոխություններ է կատարում տրամադրված հաղորդագրության հետ: Գործող git log- ը ցույց կտա այս պարտավորությունը նախագծի կատարման պատմության մեջ:

Եվս մի քանի խորհուրդ կոմիտեի մասին:

1. Մի հանձնվեք յուրաքանչյուր խնայողությամբ: Պարտավորվեք, երբ զգում եք, որ հասել եք մի կետի, երբ ձեր փոփոխությունները որոշակիորեն ամրապնդվել են: Ես պարտավորվում եմ սխեմատիկ ավարտելուց հետո, ոչ թե յուրաքանչյուր բաղադրիչ հավելումից հետո: Դուք նաև չեք ցանկանում շատ հազվադեպ կատարել պարտավորությունները, քանի որ դժվար է հիշել այն ենթատեքստը, թե ինչու եք կատարել այն փոփոխությունները, որոնք կատարել եք 3 շաբաթ անց: Գտնել, թե երբ պարտավորվել կատարել, մի փոքր արվեստ է, բայց ավելի հարմարավետ կդառնաք, քանի որ ավելի շատ եք օգտագործում Git- ը:
2. Միայն խանութի աղբյուրը (հիմնականում): Սա ներառում է նախագծի, սխեմատիկ և դասավորության ֆայլերը, ինչպես նաև նախագծին հատուկ գրադարանները: Սա կարող է ներառել նաև փաստաթղթերի ֆայլեր: Derivedգույշ եղեք ստացված առարկաները պահելիս, քանի որ դրանք կարող են հեշտությամբ չհամաժամանալ սկզբնական աղբյուրի հետ, և դա հետագայում գլխացավեր է առաջացնում: BOM և gerber ֆայլերը հատկապես հեշտությամբ են սինխրոնիզացվում, ուստի ավելի լավ է խուսափել դրանցից (չնայած ավելի մանրամասն ուղեցույցը ներառված է Քայլ 9-ում):
3. Պարտավորության մասին հաղորդագրությունները շատ օգտակար են, բայց լավ կառուցված պարտավորությունների կատարման հաղորդագրություններն անգնահատելի են: Այս հիանալի հոդվածը տալիս է որոշ ուղեցույցներ հստակ, հակիրճ, օգտակար պարտավորությունների մասին հաղորդագրություններ գրելու համար: Դա անելու համար կարող է պահանջվել օգտագործել տողի տեքստային խմբագրիչ, ինչը կարող է ինձ համար բարդ լինել սկսնակների համար («git commit» առանց -m հաղորդագրության տարբերակի միջոցով կբացվի տեքստային խմբագիր): Մարդկանց մեծամասնության համար ես խորհուրդ եմ տալիս Nano խմբագիր: StackOverflow- ը լավ բացատրություն ունի ձեր խմբագիրը փոխելու մասին

Քայլ 8: Ընդլայնված. Էլեկտրոնիկայի իմաստաբանական տարբերակ

Արկածախնդիր հոգիների համար հետևյալ խորհուրդները առաջադեմ գաղափարներ են, որոնք քաղված են KiCad- ի զարգացման բազմաթիվ ժամերից: Դրանք հատկապես օգտակար չեն փոքր նախագծերի համար, բայց դրանք իսկապես կարող են ձեզ փրկել սրտի ցավից, երբ ձեր նախագծերը բարդանում են:

Softwareրագրային ապահովման մեջ գոյություն ունի Սեմալտ տարբերակի հասկացություն (սեմվեր): Սեմվերը սահմանում է անվանակոչման ընդհանուր մեթոդաբանություն `ծրագրաշարի թողարկումները« տարբերակի համարով »նույնականացնելու համար` հետևելով «Major. Minor. Patch» - ի օրինակին: Սեմվերի բնութագիրը մեջբերելու համար դուք առաջ եք քաշում տարբերակի համարը ՝ համաձայն հետևյալ փոփոխությունների կատեգորիաների:

1. MAJOR տարբերակ, երբ անհամատեղելի API փոփոխություններ եք կատարում,
2. ՓՈՔՐ տարբերակ, երբ ֆունկցիոնալություն եք ավելացնում հետընթաց համատեղելի եղանակով,
3. PATCH տարբերակը, երբ հետընթաց համատեղելի սխալների շտկումներ եք կատարում:

Մենք Brainbow- ում օգտագործում ենք կիսամյակի մեր սեփական տարբերակը, որը հարմարեցված է ապարատային նախագծերի կարիքներին: Մեր բնութագիրը հետևում է նույն «Major. Minor. Patch» - ի նույն օրինակին, թեև մեր սահմանումները, թե որ փոփոխությունների որ կատեգորիայի տակ է ընկած, ակնհայտորեն տարբերվում են:

1. MAJOR տարբերակ. Օգտագործվում է շղթայի հիմնական գործառույթների էական փոփոխությունների համար (օր. ՝ ATmegaa- ից պրոցեսորի անցում դեպի ESP8266):
2. ՓՈՔՐ տարբերակ. Օգտագործվում է բաղադրիչների փոխանակման համար, որոնք կարող են ազդել միացման սխեմայի վրա (օր. ՝ SPI ֆլեշ փոխանակում քորոցին համատեղելի մասով, որը կարող է ունենալ այլ հրամանատարական հավաքածու) կամ որոշ աննշան լրացուցիչ գործառույթի ավելացում (օրինակ ՝ լրացուցիչ ջերմաստիճանի տվիչ):
3. PATCH տարբերակ. Օգտագործվում է աննշան վրիպակների շտկման համար, որոնք չեն փոխի սխեմայի աշխատանքը (օր. ՝ մետաքսի էկրանի ճշգրտում, փոքր հետքերի դասավորության կարգավորում, բաղադրիչի պարզ փոխանակում, ինչպես 0603 կոնդենսատորը 0805 -ով):

Սարքավորման կիսամյակում տարբերակի համարը թարմացվում է միայն արտադրության ժամանակ (ճիշտ այնպես, ինչպես ծրագրային ապահովման դեպքում, տարբերակների համարները փոխվում են միայն թողարկումների հետ մեկտեղ, ոչ թե յուրաքանչյուրն է պարտավորվում նախագծին): Արդյունքում, շատ նախագծեր ունեն ցածր տարբերակների համարներ: Մենք դեռ պետք է ունենանք նախագիծ, որն օգտագործում է ավելի քան 4 հիմնական տարբերակ:

Բացի հետևողականության և ընկալելիության առավելություններից, որոնք դուք ստանում եք հստակ սահմանված անվանման համակարգին անցնելուց, դուք նաև օգուտներ եք ստանում որոնվածի համատեղելիության և հաճախորդների գոհունակության մեջ: Irmրագրաշարը կարող է գրվել ՝ հաշվի առնելով այն թիրախավորված տախտակի տարբերակը, և ավելի հեշտ կլինի կարգաբերել, թե ինչու կոնկրետ ծրագիրը չի աշխատում տվյալ տախտակի վրա («ճիշտ է, 2.4.1 որոնվածը չի աշխատում 1.2 -ի վրա տախտակներ, քանի որ մենք չունենք … »): Հաճախորդները նաև օգտվել են մեր ապարատային սեմվերից, քանի որ սահմանված չափանիշներով հաճախորդների սպասարկումը և խնդիրների լուծումը շատ ավելի հեշտ է:

Քայլ 9: Ընդլայնված. Օգտագործելով ապարատային իմաստաբանական տարբերակ

Ձեր սեփական նախագծերում ապարատային սեմվեր օգտագործելու համար մենք օգտագործում ենք Git գործառույթը, որը կոչվում է պիտակավորում: Երբ առաջին անգամ եք պատրաստում տախտակ, դա այդ տախտակի 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- ում գերբերները չենք պահում տարբերակի վերահսկման մեջ, բացառությամբ այն բանի, երբ մենք նշում ենք թողարկումը: Երբ մենք պատրաստ ենք կառուցել, մենք ստեղծում ենք gerber ֆայլեր, պահում դրանք Fabrication թղթապանակում և կատարում և պիտակավորում: Այնուհետև մենք հեռացնում ենք գերբերները և կատարում ջնջումը: Սա կարող է սկզբում մի փոքր շփոթեցուցիչ թվալ, բայց դա ապահովում է, որ սովորական պարտավորությունները պահեն միայն աղբյուրի ֆայլերը, իսկ պիտակավորված թողարկումները նաև պահում են տախտակները պատրաստելու համար օգտագործվող ճշգրիտ ֆայլերը: Սա ապացուցեց, որ զգալիորեն օգտակար է արտադրական սխալները շաբաթներ անց հետևելու համար:

Քայլ 10: Հաջորդ քայլերը

Հուսով եմ, որ այս ներածությունը ձեզ բավականաչափ սովորեցրեց սկսել ձեր սեփական էլեկտրոնիկայի նախագծերի տարբերակների վերահսկումը: Մենք չհասանք որոշ առավել առաջադեմ թեմաների, օրինակ `նախագծերի կամ խաղարկային մասնաճյուղերի միջև համօգտագործվող գրադարանների տարբերակների վերահսկմանը: Այնուամենայնիվ, տարբերակների վերահսկումը նման է բանջարեղեն ուտելուն. Հնարավոր է, որ չստանաք այն, ինչ կարծում եք, որ պետք է, բայց ամեն մի բանի համար հաշիվ է հաշվարկվում:

Brainbow- ն աշխատում է ավելի մանրամասն ուղեցույցի վրա `մեր աշխատանքային հոսքի որոշ առավել առաջադեմ առանձնահատկությունների վերաբերյալ: Հուսով ենք, որ այն կհրապարակենք առաջիկա մի քանի ամիսների ընթացքում: Հետևեք մեզ այստեղ Instructables- ում, և մենք անպայման կտեղեկացնենք ձեզ, երբ կարող եք կարդալ այն:

Շնորհակալություն կարդալու համար, և մենք անհամբերությամբ սպասում ենք տեսնել, թե ինչ եք պատրաստում: