Kontrolli i Versionit për Hardware me Burim të Hapur: 10 hapa

2024 Autor: John Day | [email protected]. E modifikuara e fundit: 2024-01-30 12:23

Ekipi në Brainbow ka një numër projektesh elektronike nën rripin tonë, dhe ne donim të ndanim procesin tonë për përdorimin e kontrollit të versionit për të menaxhuar rrjedhën e punës së dizajnit tonë elektronik. Kjo rrjedhë pune është përdorur për projekte të mëdha dhe të vogla, nga tabela të thjeshta me 2 shtresa deri në behemothë komplekse me 10 shtresa, dhe bazohet në mjete me burim të hapur. Shpresojmë, të tjerët mund të adoptojnë rrjedhën tonë të punës për veten e tyre dhe të përfitojnë nga kontrolli i versioneve për projektet e tyre. Por çfarë përfitimesh mund të ofrojë një kontroll elektronik për një projekt elektronik?

Hapi 1: Pse Versioni Kontrolloni Elektronikën tuaj?

Kontrolli i Versionit (aka kontroll i burimit ose kontroll i rishikimit) është një koncept i kuptuar mirë dhe i miratuar gjerësisht në inxhinierinë e softuerit. Ideja prapa kontrollit të burimit është ndjekja sistematike e ndryshimeve të bëra në kodin burimor të një programi ose aplikacioni. Nëse ndryshimet prishin aplikacionin, mund t'i ktheni skedarët e kodit burim në një gjendje pune të njohur nga e kaluara. Në praktikë, sistemet e kontrollit burimor ju lejojnë të gjurmoni historinë e një koleksioni skedarësh (zakonisht skedarët e kodit burimor për një program kompjuterik, faqe interneti, etj.), Dhe të vizualizoni dhe menaxhoni ndryshimet në ato skedarë.

Ndjekja e historisë së ndryshimeve në një projekt duket e dobishme për projektet elektronike; nëse bëni një gabim në skemën e qarkut, ose përdorni gjurmën e gabuar të komponentit në paraqitjen e PCB, do të ishte mirë të mbani shënime se çfarë gabimesh janë bërë dhe cilat rregullime janë zbatuar në rishikime të ndryshme të një projekti. Do të ishte gjithashtu e dobishme për krijuesit e tjerë që ta shohin atë histori dhe të kuptojnë kontekstin dhe motivimet e ndryshimeve të ndryshme.

Hapi 2: Mjetet: KiCad dhe Git

Ne përdorim dy mjete kryesore në këtë projekt: sistemin e kontrollit të versionit (VCS) dhe programin e automatizimit të dizajnit elektronik (EDA ose ECAD).

Ka shumë sisteme të kontrollit të versionit atje, por ne përdorim VCS Git të shpërndarë. Ne e përdorim atë për një numër arsyesh, por kryesore janë se është me burim të hapur (kontrolloni!), I lehtë për t’u përdorur (kontrolloni!), Dhe standardi de-facto VCS për softuer me burim të hapur (kontrolloni!). Ne do të përdorim Git si VCS për të ndjekur ndryshimet në skedarët që përdor programi ynë ECAD. Ky Instructable nuk kërkon njohje me Git, por komoditeti i përgjithshëm duke përdorur vijën e komandës supozohet. Unë do të përpiqem të lidhem me burimet e dobishme si për Git ashtu edhe për përdorimin e linjës së komandës sipas nevojës.

Shumica e sistemeve të kontrollit të burimit funksionojnë veçanërisht mirë për skedarët e bazuar në tekst, kështu që një program ECAD që përdor skedarë teksti do të ishte i shkëlqyeshëm. Hyni në KiCad, burimi i hapur "Platforma Kryesore dhe Kompleti i Automatizimit të Dizajnit Elektronikë me Burim të Hapur" i mbështetur nga studiuesit në CERN. KiCad është gjithashtu me burim të hapur (kontrolloni!), I lehtë për t’u përdorur (megjithëse disa nuk do të pajtoheshin me mua për këtë), dhe shumë i aftë për punë të avancuara të dizajnit elektronik.

Hapi 3: Instalimi

Për të instaluar këto programe, ndiqni udhëzimet nga faqet e tyre të ndryshme të shkarkimit të lidhura më poshtë.

• KiCad është ndër-platformë (dhe marramendëse, faqja e tyre e shkarkimit liston 13 OS të mbështetur dhe ofron një shkarkim të kodit burimor nëse asnjë nga ato nuk ju përshtatet). Përdorni instalimin e paracaktuar të unifikuar të kicad, jo ndërtimin e zhvillimit të natës. Shihni Hapi 4 për detaje të përparuara opsionale mbi instalimin e bibliotekës.
• Git është gjithashtu ndër-platformë. Nëse përdorni Windows, unë do të rekomandoja projektin mbresëlënës Git për Windows për një përvojë më të dobishme, me karakteristika të plota.

Dokumentacioni i instalimit i disponueshëm në të dyja këto faqe do të jetë më i plotë se çdo përshkrim që mund të ofroj këtu. Pasi të dy programet të shkarkohen dhe instalohen, mund të klononi modelin e projektit të Brainbow nga depoja jonë Github. Komanda git clone merr strukturën `git clone {src directory} {directory directory}`; për projektin tonë, përdorni `git clone https://github.com/builtbybrainbow/kicad-starter.git {drejtoria e synuar}`.

Klonimi i një repo git është një formë e veçantë e kopjimit; kur klononi një projekt, ju merrni një kopje të të gjithë skedarëve të përfshirë në repo, si dhe të gjithë historinë e projektit të ndjekur nga Git. Duke klonuar repon tonë, ju merrni një drejtori projekti të strukturuar tashmë me rekomandimet tona për përdorimin e Git me KiCad. Ne do të mbulojmë më shumë për strukturën e projektit në Hapin 6, ose mund të kaloni në Hapin 7 nëse jeni duke u kruar për të filluar punën.

Disa detyra të shpejta të mbajtjes së shtëpisë - drejtoni `git remote rm origjinën` për të hequr lidhjen me projektin Github nga i cili keni klonuar. Gjithashtu, ekzekutoni `git commit --amend --author =" John Doe ", duke zëvendësuar parametrin e autorit me emrin dhe emailin tuaj. Kjo ndryshon angazhimin e fundit (i cili në këtë rast është edhe kryerja e parë) dhe ndryshon autorin tek ju, në vend të Brainbow.

Hapi 4: Shënim i instalimit: Bibliotekat KiCad

Një shënim i shpejtë në lidhje me strukturën e bibliotekës së KiCad. KiCad siguron një sërë bibliotekash të mirëmbajtura nga ekipi i zhvilluesve për një gamë të gjerë të përbërësve elektrikë. Ekzistojnë tre biblioteka kryesore:

• Simbolet skematike: Simbolet e përdorura për përfaqësimin e përbërësve elektronikë në një vizatim skematik të qarkut.
• Gjurmët e PCB: Vizatimet 2D që përfaqësojnë gjurmën aktuale (pads bakri, teksti mëndafshi, etj) që do të përdoren kur vendosni qarkun në një PCB.
• Modele 3D: Modele 3D të përbërësve elektronikë.

Këto biblioteka shkarkohen së bashku me programin e programit KiCad që sapo instaluat. Mund ta përdorni KiCad pa më shumë përpjekje. Sidoqoftë, për "përdoruesit e fuqisë", skedarët burim për bibliotekat ruhen në një depo git në Github, duke lejuar përdoruesit që duan të qëndrojnë të azhurnuar me ndryshimet e fundit për të klonuar repot e bibliotekës në makinën e tyre. Ndjekja e bibliotekave me git ka një numër përparësish - ju mund të zgjidhni kur doni të përditësoni bibliotekat tuaja, dhe përditësimet duhet të përfshijnë vetëm ndryshimet në skedarë, në vend që të shkarkoni përsëri të gjithë grupin e skedarëve të bibliotekës. Sidoqoftë, ju jeni përgjegjës për azhurnimin e bibliotekave, të cilat mund të jenë të lehta për tu harruar.

Nëse dëshironi të klononi bibliotekat, kjo faqe jep detaje për ofertat e ndryshme të Github KiCad. Git klononi bibliotekat në kompjuterin tuaj (p.sh.: `git klon https:// github.com/KiCad/kicad-symbol.git`), pastaj hapni KiCad, zgjidhni artikullin e menysë" Preferencat "dhe klikoni" Konfiguro rrugët … ". Kjo ju lejon të tregoni KiCad shtegun e drejtorisë për të kërkuar secilën bibliotekë. Këto ndryshore të mjedisit të paracaktuar në rrugën drejt bibliotekave të instaluara me instalimin KiCad; I kam marrë parasysh këto vlera në mënyrë që të kthehem në bibliotekat e paracaktuara nëse është e nevojshme. Rruga KICAD_SYMBOL_DIR duhet të tregojë në bibliotekën tuaj të klonuar të simboleve kicad, KISYSMOD në bibliotekën e klonuar të gjurmëve të këmbëve kicad dhe KISYS3DMOD në bibliotekën e klonuar kicad-packages3d.

Kur dëshironi të azhurnoni bibliotekat, mund të përdorni një komandë të thjeshtë `git pull` në repon e bibliotekës, e cila do t'i thotë Git të kontrollojë dallimet midis kopjes suaj lokale të repos së bibliotekës dhe repos" të largët "të Github, dhe të përditësojë automatikisht kopje lokale për të përfshirë ndryshimet.

Hapi 5: Bazat e Git

Git është një program kompleks dhe i shumëanshëm, me libra të tërë kushtuar zotërimit të tij. Sidoqoftë, ka disa koncepte të thjeshta që do t'ju ndihmojnë të kuptoni se si po përdorim Git në rrjedhën tonë të punës.

Git gjurmon ndryshimet në skedarë duke përdorur një seri fazash. Ndryshimet normale ndodhin në drejtorinë e punës. Kur jeni të kënaqur me ndryshimet që keni bërë në një seri skedarësh, shtoni skedarët që keni ndryshuar në zonën e skenës. Pasi të keni bërë të gjitha ndryshimet në të cilat planifikoni dhe të vendosni të gjithë skedarët që dëshironi të gjurmohen në Git, ju i bëni ato ndryshime në depo. Angazhimet janë në thelb fotografi të gjendjes së skedarëve në një repo në një kohë të caktuar. Meqenëse Git gjurmon ndryshimet në skedarë dhe ruan këto ndryshime në komisione, në çdo moment mund ta ktheni një projekt përsëri në gjendjen që ishte në çdo angazhim paraprak.

Ka tema më komplekse, si degëzimi dhe telekomanda, por ne nuk kemi nevojë t'i përdorim ato për të fituar përfitimet e kontrollit të burimit. E tëra çfarë na duhet është të gjurmojmë ndryshimet në skedarët tanë të dizajnit KiCad me një seri detyrimesh.

Hapi 6: Struktura e Projektit KiCad

Le të hedhim një vështrim më të afërt në strukturën e projektit KiCad-Starter që keni klonuar më herët. Dividedshtë e ndarë në një numër nën -drejtorish për organizim të lehtë:

• Qarku: Kjo dosje përmban skedarët aktualë të projektit KiCad (skematik, PCB, etj). Unë nuk e riemërtoj këtë dosje, por i riemërtoj të gjithë skedarët brenda me emrin e projektit (Circuit.pro => ArduinoMini.pro).

  • Circuit.pro: skedari i projektit KiCad
  • Circuit.sch: skedari skematik i KiCad.
  • Circuit.kicad_pcb: skedari i paraqitjes së KiCad PCB.
• Dokumentacioni: Kjo dosje është për ruajtjen e dokumentacionit në lidhje me projektin. Ne kemi plane për përmirësimin e kësaj hapësire në të ardhmen, por tani për tani ajo përmban një skedar të thjeshtë README. Përdoreni atë për të ruajtur shënimet mbi projektin për t'i rishikuar në të ardhmen.
• Fabrikimi: Ky dosje është vendi ku do të ruani skedarët gerber që shumica e shtëpive fabrikore do të përdorin për prodhimin e tabelës tuaj të qarkut. Ne gjithashtu e përdorim atë për të ruajtur skedarët BOM dhe dokumente të tjerë që mund të jenë të nevojshëm për prodhimin dhe montimin.
• Bibliotekat: Kjo dosje është për ruajtjen e skedarëve të bibliotekës specifike të projektit (këtë do ta mbulojmë më shumë në disa hapa).

Ju gjithashtu mund të keni vërejtur disa skedarë të tjerë (veçanërisht nëse e ls -a) drejtorinë). Drejtoria.git është vendi ku Git bën magjinë e tij, duke ruajtur historinë e depove. Skedari.gitignore përdoret për t'i treguar Git se cilat skedarë duhet të injorojë dhe të mos i ruajë në kontrollin e burimit. Këto janë kryesisht skedarë rezervë që KiCad gjeneron, ose disa skedarë të ndryshëm "të gjeneruar", si listat neto, të cilat nuk duhet të ruhen në kontrollin e burimit sepse ato gjenerohen nga burimi që është skedari skematik.

Kjo strukturë e projektit është vetëm një pikënisje. Ju duhet ta përshtatni atë për t'iu përshtatur nevojave tuaja dhe të shtoni seksione sipas nevojës. Në disa projekte ne kemi përfshirë një dosje softueri ose një dosje rrethimi, ku kemi ruajtur modele për mbyllje të printimit 3D për projektin.

Hapi 7: Përdorimi i Git për Projektet KiCad

Më në fund jemi gati të shohim se si të përdorim Git për ndjekjen e projekteve tuaja. Ky Instructable nuk ka për qëllim t'ju mësojë se si të përdorni KiCad (megjithëse unë mund ta bëj një në të ardhmen nëse ka kërkesë për të), kështu që ne do të kalojmë nëpër disa shembuj të parëndësishëm për t'ju treguar se si funksionon rrjedha e punës. Duhet të jetë e lehtë për të kuptuar se si t'i përshtatni këto ide në një projekt të vërtetë.

Hapni drejtorinë kicad-starter, më pas drejtoni `git log` për të shfaqur historinë e kryerjes. Këtu duhet të ketë një angazhim, inicimin e repos nga Brainbow. Drejtimi i `statusit git` do t'ju tregojë statusin e skedarëve në repon tuaj (të pakontrolluar, modifikuar, fshirë, vënë në skenë).

Për momentin, nuk duhet të keni ndryshime në repon tuaj. Le të bëjmë një ndryshim. Hapni projektin KiCad dhe shtoni një rezistencë në skemë, pastaj ruani. Tani duke ekzekutuar `statusin git` duhet të tregoni se keni ndryshuar skedarin skematik, por nuk i keni bërë ende ato ndryshime për kryerje. Nëse jeni kurioz se çfarë bëri saktësisht KiCad kur shtuat rezistencën, mund të ekzekutoni komandën diff në skedarin e modifikuar `git diff Circuit/Circuit.sch`. Kjo do të nxjerrë në pah ndryshimet midis versionit aktual të skedarit në drejtorinë e punës dhe gjendjes së skedarit në kryerjen e fundit.

Tani që kemi bërë një ndryshim, le të përpiqemi ta bëjmë atë ndryshim në historinë e projektit tonë. Ne duhet të zhvendosim ndryshimet nga drejtoria jonë e punës në zonën e skenës. Kjo në fakt nuk i zhvendos skedarët në sistemin e skedarëve, por është konceptualisht një mënyrë për t'i bërë të ditur Git -it se ju keni bërë të gjitha ndryshimet tuaja të planifikuara për një skedar të veçantë dhe jeni gati t'i bëni ato ndryshime. Për ndihmë, Git siguron disa sugjerime kur drejtoni `statusin git` për veprimin tjetër. Vëreni mesazhin `(përdorni" git add… "për të përditësuar atë që do të kryhet)` nën `Ndryshimet që nuk janë organizuar për kryerjen:`. Git po ju tregon se si t'i zhvendosni ndryshimet në zonën e skenës. Drejtoni `git add Circuit/Circuit.sch` për të vendosur ndryshimet, pastaj` git status` për të parë se çfarë ka ndodhur. Tani ne shohim skedarin skematik nën ndryshimet që do të kryhen. Nëse nuk doni të kryeni ende këto ndryshime, Git ofron me ndihmë një këshillë tjetër: `(përdorni" git reset HEAD … "për të hequr skenën)". Ne vërtet duam të kryejmë këto ndryshime, kështu që ne ekzekutojmë `git commit -m" Rezistencë e shtuar në skemë ". Kjo bën ndryshimet me mesazhin e dhënë. Drejtimi i git log do të tregojë këtë angazhim në historinë e kryerjes së projektit.

Disa këshilla të tjera rreth komisioneve.

1. Mos u angazhoni me çdo kursim. Angazhohuni kur ndjeni se keni arritur një pikë ku ndryshimet tuaja janë ngurtësuar disi. Unë angazhohem pasi të përfundoj një skemë, jo pas çdo shtese përbërëse. Ju gjithashtu nuk doni të angazhoheni shumë rrallë, sepse të kujtosh kontekstin pse keni bërë ndryshimet që keni bërë 3 javë më vonë mund të jetë e vështirë. Të kuptosh se kur të angazhohesh është një art, por do të ndihesh më komod kur përdor më shumë Git.
2. Vetëm burimi i dyqanit (kryesisht). Kjo përfshin projektin, skemat dhe skedarët e paraqitjes, si dhe bibliotekat specifike të projektit. Kjo gjithashtu mund të përfshijë skedarë dokumentacioni. Kini kujdes kur ruani objektet e prejardhura sepse ato mund të dalin nga sinkronizimi me burimin origjinal lehtë, dhe kjo shkakton dhimbje koke më vonë. Skedarët BOM dhe gerber de-sinkronizohen veçanërisht lehtë, kështu që shmangen më mirë (megjithëse udhëzimet më të hollësishme mbulohen në Hapin 9).
3. Mesazhet e angazhimit janë shumë të dobishme, por mesazhet e strukturuara mirë janë të paçmueshme. Ky artikull i shkëlqyer siguron disa udhëzime për të shkruar mesazhe të qarta, koncize dhe të dobishme të angazhimit. Të bësh këtë mund të kërkojë përdorimin e një redaktuesi të tekstit të vijës së komandës, i cili mund të jetë i komplikuar për fillestarët (`git commit` pa opsionin -m mesazh do të hapë një redaktues teksti). Për shumicën e njerëzve, unë rekomandoj redaktorin Nano. StackOverflow ka një shpjegim të mirë të ndryshimit të redaktorit tuaj

Hapi 8: Avancuar: Versionimi Semantik për Elektronikë

Për shpirtrat aventurierë, këshillat e mëposhtme janë ide të avancuara, të marra nga shumë orë të zhvillimit të KiCad. Ato nuk janë veçanërisht të dobishme për projektet më të vogla, por me të vërtetë mund t’ju kursejnë dhimbjen kur projektet tuaja rriten në kompleksitet.

Në softuer, ekziston një koncept i Versionimit Semantik (semver). Semver përcakton një metodologji të zakonshme të emërtimit për të identifikuar lëshimet e softuerit sipas "numrit të versionit", duke ndjekur një model të "Major. Minor. Patch". Për të cituar specifikat e semver, ju avanconi numrin e versionit sipas kategorive të mëposhtme të ndryshimit.

1. Versioni MAJOR kur bëni ndryshime të papajtueshme API,
2. Versioni MINOR kur shtoni funksionalitet në një mënyrë të pajtueshme prapa,
3. Versioni PATCH kur bëni rregullime të gabimeve të pajtueshme prapa.

Ne në Brainbow përdorim versionin tonë të semver të përshtatur për t'iu përshtatur nevojave të projekteve harduerike. Specifikimi ynë ndjek të njëjtin model "Major. Minor. Patch", megjithëse përkufizimet tona se çfarë ndryshimesh përfshihen nën cilën kategori dallojnë dukshëm.

1. Versioni MAJOR: përdoret për ndryshime të rëndësishme në funksionalitetin bazë të qarkut (psh: kalimi i procesorit nga ATmegaa në ESP8266).
2. Versioni MINOR: përdoret për shkëmbimet e komponentëve që mund të ndikojnë në funksionimin e qarkut (p.sh. shkëmbimi i blicit SPI me pjesë të përputhshme me pin që mund të ketë një grup komandash të ndryshme) ose shtimi i disa veçorive shtesë të vogla (p.sh.: një sensor shtesë i temperaturës shtesë).
3. Versioni PATCH: përdoret për korrigjimet e vogla të gabimeve që nuk do të ndryshojnë funksionimin e qarkut (p.sh.: rregullimi i ekranit të mëndafshit, rregullimi i paraqitjes së gjurmëve të vogla, ndërrimi i thjeshtë i përbërësve si kondensatori 0603 në 0805).

Në semver hardware, numri i versionit azhurnohet vetëm në prodhim (ashtu si në softuer, numrat e versioneve ndryshojnë vetëm me lëshimet, jo çdo individ angazhohet për një projekt). Si rezultat, shumë projekte kanë numra të ulët të versionit. Ende nuk kemi një projekt që përdor më shumë se 4 versione kryesore.

Përveç përfitimeve në qëndrueshmëri dhe kuptueshmëri që merrni nga kalimi në një sistem emërtimi të përcaktuar mirë, ju gjithashtu fitoni përfitime në pajtueshmërinë e firmware dhe kënaqësinë e klientit. Firmware mund të shkruhet duke marrë parasysh versionin e bordit që po synon, dhe mund të jetë më e lehtë të korrigjosh pse një program i veçantë nuk punon në një tabelë të caktuar ("e drejtë, firmware 2.4.1 nuk funksionon në 1.2 dërrasa sepse nuk kemi … "). Klientët gjithashtu kanë përfituar nga semveri ynë harduerik sepse shërbimi ndaj klientit dhe zgjidhja e problemeve është shumë më e lehtë me një standard të përcaktuar.

Hapi 9: I avancuar: Përdorimi i versioneve semantike të harduerit

Për të përdorur semver hardware në projektet tuaja, ne përdorim një veçori Git të quajtur etiketim. Kur prodhoni për herë të parë një bord, ky është versioni 1.0.0 i atij bordi. Sigurohuni që keni kryer të gjitha ndryshimet në projektin tuaj, pastaj ekzekutoni `git tag -a v1.0.0`. Kjo do të hapë një redaktues kështu që ju mund të shkruani një mesazh shënimi për këtë etiketë (shumë e ngjashme me një mesazh të kryer). Unë përfshij detaje në lidhje me prodhimin (kush e bëri PCB, i cili mblodhi bordin), i cili mund të jetë informacion i dobishëm më vonë.

Etiketa e lëshimit i shtohet historisë së kryerjes dhe tregon gjendjen e skedarëve në prodhimin 1.0.0. Kjo mund të jetë veçanërisht e dobishme për disa rishikime më vonë kur të keni nevojë t'i referoheni përsëri kësaj pike për zgjidhjen e problemeve. Pa një etiketë të caktuar të lëshimit, mund të jetë e vështirë të kuptohet se cili angazhim ishte më i fundit në kohën e prodhimit. Një etiketë 1.0.0 (dhe 1.1, 1.1.1, etj) ju lejon të specifikoni se këto skedarë burimi specifik ishin ato që u përdorën në një punë të veçantë prodhimi.

Një shënim për Gerbers. Disa shtëpi fabrike kërkojnë skedarë gerber për të bërë bordin tuaj, dhe ju mund t'i krijoni ato me KiCad. Këto janë objekte të prejardhura, të krijuara nga skedari burimor.kicad_pcb, dhe ne normalisht nuk i kontrollojmë versionet skedarët e nxjerrë. Ne në Brainbow nuk i ruajmë gerberët në kontrollin e versionit PCERVEÇ kur shënojmë një lëshim. Kur jemi gati për të ndërtuar, ne krijojmë skedarë gerber, i ruajmë në dosjen Fabrication dhe kryejmë dhe etiketojmë. Pastaj heqim gerberët dhe kryejmë fshirjen. Kjo mund të duket pak konfuze në fillim, por siguron që kryerjet normale ruajnë vetëm skedarët burim, dhe lëshimet e etiketuara gjithashtu ruajnë skedarët e saktë të përdorur për prodhimin e tabelave. Kjo ka rezultuar jashtëzakonisht e dobishme në gjurmimin e gabimeve të prodhimit javë më vonë.

Hapi 10: Hapat e ardhshëm

Shpresojmë që kjo hyrje ju ka mësuar mjaftueshëm për të filluar përdorimin e kontrollit të versionit në projektet tuaja elektronike. Ne nuk arritëm në disa nga temat më të avancuara, si kontrolli i versionit për bibliotekat e ndara midis projekteve ose degëve të veçorive. Sidoqoftë, kontrolli i versionit është si të hani perimet tuaja: mund të mos merrni atë që mendoni se duhet, por çdo grimë që bëni do të llogaritet.

Brainbow po punon në një udhëzues më të detajuar për disa nga veçoritë më të përparuara të rrjedhës sonë të punës. Shpresojmë ta botojmë diku në muajt e ardhshëm. Na ndiqni këtu në Instructables, dhe ne do të jemi të sigurtë se do t'ju njoftojmë kur ta lexoni.

Faleminderit për leximin, dhe mezi presim të shohim se çfarë bëni ju!