Weergawe -beheer vir open source -hardeware: 10 stappe

2025 Outeur: John Day | [email protected]. Laas verander: 2025-01-13 06:56

Die span van Brainbow het 'n aantal elektroniese projekte onder ons band, en ons wou ons proses met die gebruik van weergawe -beheer deel om ons werkstroom vir elektroniese ontwerp te bestuur. Hierdie werkstroom is gebruik vir groot en klein projekte, van eenvoudige tweelaags planke tot komplekse 10-laags behemotte, en is gebaseer op open source-gereedskap. Hopelik kan ander ons werkstroom vir hulself aanneem en die voordele van weergawe -beheer vir hul eie projekte kry. Maar watter voordele kan weergawe -beheer 'n elektroniese projek bied?

Stap 1: Waarom weergawe -beheer van u elektronika?

Weergawe-beheer (ook bekend as bronbeheer of hersieningsbeheer) is 'n goed verstaanbare en algemeen aangeneem konsep in sagteware-ingenieurswese. Die idee agter bronbeheer is om stelselmatig die veranderinge aan die bronkode van 'n program of toepassing op te spoor. As veranderinge die toepassing breek, kan u die bronkode -lêers terugkeer na 'n bekende werkende toestand uit die verlede. In die praktyk stel bronbeheerstelsels u in staat om die geskiedenis van 'n versameling lêers op te spoor (gewoonlik die bronkode -lêers vir 'n rekenaarprogram, webwerf, ens.), En veranderings aan die lêers te visualiseer en te bestuur.

Om die geskiedenis van veranderinge aan 'n projek by te hou, blyk nuttig vir elektroniese projekte; As u 'n fout in die stroombaan maak, of as u die verkeerde komponent se voetspoor in die PCB -uitleg gebruik, sal dit goed wees om by te hou watter foute gemaak is en watter regstellings in verskillende hersienings van 'n projek geïmplementeer is. Dit sou ook nuttig wees vir ander makers om die geskiedenis te sien en die konteks en motiverings van verskillende veranderinge te verstaan.

Stap 2: Die gereedskap: KiCad en Git

Ons gebruik twee hoofgereedskap in hierdie projek: die weergawe -beheerstelsel (VCS) en die elektroniese ontwerp -outomatiseringsprogram (EDA of ECAD).

Daar is BAIE weergawe -beheerstelsels, maar ons gebruik die verspreide VCS Git. Ons gebruik dit om 'n aantal redes, maar die belangrikste is dat dit open source (check!), Maklik om te gebruik (check!) En die de-facto standaard VCS vir open source sagteware (check!). Ons sal Git as die VCS gebruik om die veranderinge aan die lêers wat ons ECAD -program gebruik, op te spoor. Hierdie instruksies vereis nie vertroudheid met Git nie, maar algemene gemak met die opdragreël word aanvaar. Ek sal probeer om te skakel na nuttige hulpbronne vir beide Git- en opdragreëlgebruik, indien nodig.

Die meeste bronbeheerstelsels werk veral goed vir teksgebaseerde lêers, dus 'n ECAD-program wat tekslêers gebruik, sal goed wees. Voer KiCad in, die open source "Cross Platform and Open Source Electronics Design Automation Suite", ondersteun deur navorsers van CERN. KiCad is ook 'n open source (tjek!), Maklik om te gebruik (alhoewel sommige dit nie met my saamstem nie) en is baie geskik vir gevorderde elektroniese ontwerpwerk.

Stap 3: Installasie

Om hierdie programme te installeer, volg die instruksies van hul verskillende aflaaiplekke wat hieronder gekoppel is.

• KiCad is 'n platform-platform (en duiselingwekkend; hulle aflaai-bladsy bevat 13 ondersteunde bedryfstelsels en bied 'n bronkode-aflaai as dit nie by u pas nie). Gebruik die kicad-verenigde standaardinstallasie, nie die nagtelike ontwikkelingsopbou nie. Sien stap 4 vir gevorderde opsionele besonderhede oor die installering van biblioteke.
• Git is ook 'n platform-platform. As ek Windows gebruik, sou ek die indrukwekkende Git for Windows-projek aanbeveel vir 'n meer nuttige, volledige ervaring.

Die installasie dokumentasie wat op beide hierdie webwerwe beskikbaar is, sal meer volledig wees as enige beskrywing wat ek hier kan bied. Sodra albei programme afgelaai en geïnstalleer is, kan u die projeksjabloon van Brainbow uit ons Github -bewaarplek kloon. Die git clone -opdrag neem die struktuur `git clone {src directory} {target directory}`; Gebruik 'git-kloon https://github.com/builtbybrainbow/kicad-starter.git {target directory}' vir ons projek.

Kloning van 'n git repo is 'n spesiale kopieervorm; As u 'n projek kloon, kry u 'n afskrif van al die lêers wat in die repo is, sowel as die hele Git-nagespoor geskiedenis van die projek. Deur ons repo te kloon, kry u 'n projekgids wat reeds gestruktureer is met ons aanbevelings vir die gebruik van Git met KiCad. Ons gaan meer oor die projekstruktuur in stap 6, of u kan na stap 7 oorgaan as u wil begin werk.

'N Paar vinnige huishoudelike take - voer' git remote rm origin 'uit om die skakel na die Github -projek waaruit u gekloon het, te verwyder. Voer ook `git commit --amend --author =" John Doe "` in en vervang die outeur -parameter met u naam en e -posadres. Dit wysig die laaste verbintenis (wat in hierdie geval ook die eerste verbintenis is) en verander die outeur in plaas van Brainbow.

Stap 4: Installasie -nota: KiCad Libraries

Een vinnige opmerking oor die biblioteekstruktuur van KiCad. KiCad bied 'n stel biblioteke wat deur die ontwikkelaarspan onderhou word vir 'n wye reeks elektriese komponente. Daar is drie hoofbiblioteke:

• Skematiese simbole: simbole wat gebruik word vir die voorstelling van elektroniese komponente in 'n stroombaan skematiese tekening.
• PCB -voetspore: 2D -tekeninge wat die werklike voetspoor voorstel (koperblokkies, syskermteks, ens.) Wat gebruik moet word by die uitleg van die stroombaan op 'n PCB.
• 3D -modelle: 3D -modelle van elektroniese komponente.

Hierdie biblioteke word afgelaai saam met die KiCad -programpakket wat u pas geïnstalleer het. U kan KiCad sonder meer moeite gebruik. Vir 'kraggebruikers' word die bronlêers vir die biblioteke egter in 'n git -bewaarplek op Github gestoor, sodat gebruikers wat op die hoogte wil bly van die nuutste veranderinge, die biblioteek se repos na hul eie masjien kan kloon. Om die biblioteke met git op te spoor, het 'n aantal voordele - u kan kies wanneer u u biblioteke wil opdateer, en opdaterings hoef slegs veranderinge aan die lêers op te neem, eerder as om die hele stel biblioteeklêers weer af te laai. U is egter verantwoordelik vir die opdatering van die biblioteke, wat maklik kan vergeet.

As u die biblioteke wil kloon, bevat hierdie webwerf die verskillende Github -repos wat KiCad bied. Git kloon die biblioteke na u rekenaar (byvoorbeeld: 'git clone https:// github.com/KiCad/kicad-symbols.git'), maak KiCad oop, kies die menubalk "Voorkeure" en klik op "Configure Paths … ". Hiermee kan u KiCad die gidspad vertel waarna u elke biblioteek moet soek. Hierdie omgewingsveranderlikes is standaard die pad na die biblioteke wat met die KiCad -installasie geïnstalleer is; Ek het kennis geneem van hierdie waardes sodat ek na die standaardbiblioteke kan terugkeer indien nodig. Die pad KICAD_SYMBOL_DIR moet verwys na u gekloonde kikad-simbole-biblioteek, KISYSMOD na die gekloonde kikad-voetspore-biblioteek en KISYS3DMOD na die gekloonde kicad-packages3d-biblioteek.

As u die biblioteke wil opdateer, kan u 'n eenvoudige 'git pull' -opdrag in die biblioteek -repo uitvoer, wat Git sal vertel om te kyk of daar verskille is tussen u plaaslike kopie van die biblioteekreparasie en die Github' remote 'repo, en u outomaties op te dateer plaaslike kopie om veranderinge op te neem.

Stap 5: Git Fundamentals

Git is 'n komplekse en veelsydige program, met hele boeke wat daarop gemik is om dit te bemeester. Daar is egter 'n paar eenvoudige konsepte wat u sal help om te verstaan hoe ons Git in ons werkstroom gebruik.

Git volg veranderings aan lêers in 'n reeks fases. Normale veranderinge vind plaas in die werksgids. As u tevrede is met die veranderinge wat u aan 'n reeks lêers aangebring het, voeg u die lêers wat u verander het by die opstelgebied. Nadat u al die veranderings wat u van plan is, aangebring het en al die lêers wat u in Git wil nagespoor het, opgestel het, bring u die veranderinge tot die bewaarplek toe. Commits is in wese foto's van die toestand van die lêers in 'n repo op 'n spesifieke tydstip. Aangesien Git veranderinge aan lêers opspoor en hierdie veranderinge in kommitte stoor, kan u op enige stadium 'n projek terugstuur na die toestand waarin dit was, op enige vorige verbintenis.

Daar is meer ingewikkelde onderwerpe, soos vertakking en afstandbeheer, maar ons hoef dit nie te gebruik om die voordele van bronbeheer te verkry nie. Al wat ons nodig het, is om veranderinge aan ons KiCad -ontwerplêers op te spoor met 'n reeks verbintenisse.

Stap 6: KiCad -projekstruktuur

Kom ons kyk na die struktuur van die KiCad-Starter-projek wat u vroeër gekloon het. Dit is verdeel in 'n aantal subgidse vir maklike organisasie:

• Kring: Hierdie vouer bevat die werklike KiCad -projeklêers (skematies, PCB, ens.). Ek hernoem nie hierdie gids nie, maar ek hernoem al die lêers binne met die naam van die projek (Circuit.pro => ArduinoMini.pro).

  • Circuit.pro: die KiCad -projeklêer
  • Circuit.sch: die KiCad -skematiese lêer.
  • Circuit.kicad_pcb: die KiCad PCB -uitleglêer.
• Dokumentasie: Hierdie gids is vir die stoor van dokumentasie aangaande die projek. Ons het planne om hierdie ruimte in die toekoms te verbeter, maar dit bevat tans 'n eenvoudige README -lêer. Gebruik dit om notas oor die projek te stoor sodat u dit later kan hersien.
• Vervaardiging: in hierdie gids kan u die gerber -lêers stoor wat die meeste fab huise sal gebruik vir die vervaardiging van u bord. Ons gebruik dit ook om stempellêers en ander dokumente wat nodig is vir die vervaardiging en samestelling, te stoor.
• Biblioteke: Hierdie vouer is vir die stoor van projekspesifieke biblioteeklêers (ons bespreek dit in 'n paar stappe).

U het moontlik ook 'n paar ander lêers opgemerk (veral as u 'die gids' is). Die.git -gids is waar Git sy towerkuns doen en die geskiedenis van die bewaarplek stoor. Die.gitignore -lêer word gebruik om vir Git te vertel watter lêers dit moet ignoreer en nie in bronbeheer gestoor moet word nie. Dit is meestal rugsteunlêers wat KiCad genereer, of 'n paar verskillende 'gegenereerde' lêers, soos netlyste, wat nie in die bronbeheer gestoor moet word nie, omdat dit gegenereer word uit die bron wat die skematiese lêer is.

Hierdie projekstruktuur is slegs 'n beginpunt. U moet dit aanpas by u behoeftes, en indien nodig afdelings byvoeg. In sommige projekte het ons 'n sagtewaremap of omslagmap ingesluit, waar ons modelle vir 3D -afdrukke vir die projek gestoor het.

Stap 7: Gebruik Git vir KiCad -projekte

Ons is uiteindelik gereed om te sien hoe u Git kan gebruik om u projekte op te spoor. Hierdie instruksies is nie bedoel om u te leer hoe u KiCad moet gebruik nie (alhoewel ek dit in die toekoms kan doen as daar 'n behoefte daaraan is), daarom gaan ons 'n paar triviale voorbeelde deur om u te wys hoe die werkstroom verloop. Dit moet maklik wees om te verstaan hoe om hierdie idees aan te pas by 'n werklike projek.

Maak die kicad-starter-gids oop en voer dan 'git log' uit om die commit-geskiedenis te vertoon. Hier moet een verbintenis wees, die inisialisering van die repo deur Brainbow. Deur 'git status' uit te voer, sal u die status van lêers in u repo vertel (ongespoor, gewysig, verwyder, opgevoer).

Op die oomblik behoort u geen veranderinge aan u rekening te hê nie. Kom ons maak 'n verandering. Maak die KiCad -projek oop en voeg 'n weerstand by die skema, en stoor dan. As 'git -status' uitgevoer word, moet dit wys dat u die skematiese lêer gewysig het, maar dat u nog nie die veranderinge vir commit gemaak het nie. As u nuuskierig is oor wat KiCad presies gedoen het toe u die weerstand bygevoeg het, kan u die diff -opdrag op die gewysigde lêer `git diff Circuit/Circuit.sch` uitvoer. Dit beklemtoon die veranderinge tussen die huidige weergawe van die lêer in die werkgids en die toestand van die lêer by die laaste verbintenis.

Noudat ons 'n verandering aangebring het, probeer ons hierdie verandering aan ons projekgeskiedenis toewy. Ons moet die veranderinge van ons werksgids na die verhooggebied skuif. Dit skuif die lêers in die lêerstelsel nie eintlik nie, maar dit is konseptueel 'n manier om Git te laat weet dat u al u beplande veranderings vir 'n spesifieke lêer aangebring het en gereed is om die veranderinge aan te bring. Nuttig, Git gee 'n paar wenke wanneer u 'git -status' vir die volgende aksie uitvoer. Let op die boodskap '(gebruik' git add … 'om by te werk wat gepleeg sal word)' onder 'Veranderings wat nie vir begaan is opgevoer nie:'. Git vertel jou hoe om die veranderinge na die verhooggebied te skuif. Voer 'git add Circuit/Circuit.sch' uit om die veranderinge op te stel, en dan 'git status' om te sien wat gebeur het. Nou sien ons die skematiese lêer onder veranderings wat gemaak moet word. As u nog nie hierdie veranderinge wil aanbring nie, bied Git nog 'n wenk: '(gebruik' git reset HEAD … 'om dit te verhoog)'. Ons wil wel hierdie veranderinge aanbring, daarom voer ons 'git commit -m "Added resistor to schematic" toe. Dit bring die veranderinge met die verstrekte boodskap mee. Deur 'n git -logboek uit te voer, word hierdie verbintenis in die projekverbintenisgeskiedenis aangetoon.

Nog 'n paar wenke oor verbintenisse.

1. Moenie met elke redding verbind nie. Pleeg as jy voel dat jy 'n punt bereik het waar jou veranderinge effens gestol het. Ek verbind my na die voltooiing van die skema, nie na elke byvoeging van die komponente nie. U wil ook nie te selde pleeg nie, want dit kan moeilik wees om die konteks te onthou waarom u die veranderinge wat u drie weke later aangebring het, kan onthou. Dit is 'n bietjie kuns om uit te vind wanneer u moet pleeg, maar u sal gemakliker word namate u Git meer gebruik.
2. Slegs winkelbron (meestal). Dit bevat die projek-, skematiese en uitleglêers, sowel as projekspesifieke biblioteke. Dit kan ook dokumentasie lêers insluit. Wees versigtig wanneer u afgeleide voorwerpe stoor, want dit kan maklik uit die sinchronisasie met die oorspronklike bron kom, en dit veroorsaak later hoofpyn. BOM- en gerber-lêers word besonder maklik gesinkroniseer, daarom word dit beter vermy (hoewel meer gedetailleerde leiding in stap 9 behandel word).
3. Prysboodskappe is baie handig, maar goed gestruktureerde verbindingsboodskappe is van onskatbare waarde. Hierdie uitstekende artikel gee 'n paar riglyne vir die skryf van duidelike, bondige, bruikbare boodskappe. Dit kan nodig wees om 'n opdragreël -teksredakteur te gebruik, wat vir beginners ingewikkeld kan wees ('git commit' sonder die opsie -m -boodskap sal 'n teksredakteur oopmaak). Vir die meeste mense beveel ek die Nano -redakteur aan. StackOverflow het 'n goeie verduideliking vir die verandering van u redakteur

Stap 8: Gevorderd: Semantiese weergawe vir elektronika

Vir die avontuurlustige siele is die volgende wenke gevorderde idees, verkry uit baie ure KiCad -ontwikkeling. Dit is nie besonder nuttig vir kleiner projekte nie, maar dit kan u regtig hartseer bespaar namate u projekte in kompleksiteit toeneem.

In sagteware is daar 'n konsep van Semantic Versioning (semver). Semver definieer 'n algemene benoemingsmetodiek om sagteware -vrystellings te identifiseer deur 'weergawenommer', volgens 'n patroon van 'Major. Minor. Patch'. Om die spesifikasie van semver aan te haal, gee u die weergawenommer vooraf volgens die volgende veranderingskategorieë.

1. GROOT weergawe as u onversoenbare API -veranderinge aanbring,
2. MINDER weergawe as u funksies op 'n agteruit-versoenbare manier byvoeg,
3. PATCH-weergawe as u agteruit-versoenbare foutoplossings maak.

Ons by Brainbow gebruik ons eie weergawe van semver wat aangepas is vir die behoeftes van hardeware projekte. Ons spesifikasie volg dieselfde patroon van 'Major. Minor. Patch', hoewel ons definisies van watter veranderinge onder watter kategorie natuurlik verskil.

1. GROOT weergawe: word gebruik vir beduidende veranderinge aan die kernfunksies van die stroombaan (byvoorbeeld: omskakel verwerker van ATmegaa na ESP8266).
2. MINDER weergawe: word gebruik vir komponentruilings wat die werking van die stroombaan kan beïnvloed (byvoorbeeld: SPI-flitswisseling met 'n pen-versoenbare deel wat 'n ander opdragstel kan hê) of die toevoeging van 'n paar ekstra bykomende funksies (byvoorbeeld: ekstra bykomende temperatuursensor).
3. PATCH -weergawe: word gebruik vir geringe foutoplossings wat die kring nie sal verander nie (bv. Syskermaanpassing, geringe spooruitlegaanpassing, eenvoudige komponentruilings soos 0603 -kondensator na 0805).

In hardware semver word die weergawenommer slegs by vervaardiging bygewerk (net soos in sagteware verander weergawegetalle slegs met vrystellings, nie elke individu verbind tot 'n projek nie). As gevolg hiervan het baie projekte 'n lae weergawegetal. Ons het nog nie 'n projek nie, maar gebruik meer as 4 groot weergawes.

Afgesien van die voordele in konsekwentheid en verstaanbaarheid wat u kry as u oorskakel na 'n goed gedefinieerde naamstelsel, kry u ook voordele in firmware-verenigbaarheid en klanttevredenheid. Firmware kan geskryf word met inagneming van die weergawe van die bord waarop dit gemik is, en dit kan makliker wees om te ontfout waarom 'n spesifieke program nie op 'n spesifieke bord werk nie ("reg, die 2.4.1 -firmware werk nie op 1.2 nie borde omdat ons nie het nie. "). Kliënte het ook baat by ons hardeware -semver omdat kliëntediens en probleemoplossing baie makliker is met 'n gedefinieerde standaard.

Stap 9: Gevorderd: gebruik hardeware -semantiese weergawe

Om hardeware semver in u eie projekte te gebruik, gebruik ons 'n Git -funksie genaamd tagging. As u die eerste keer 'n bord vervaardig, is dit die 1.0.0 -weergawe van die bord. Maak seker dat u al die veranderinge in u projek aangebring het, en voer dan 'git tag -a v1.0.0' uit. Dit sal 'n redakteur oopmaak sodat u 'n aantekeningboodskap vir hierdie tag kan skryf (baie soortgelyk aan 'n commit -boodskap). Ek bevat besonderhede oor die vervaardiging (wat die PCB gemaak het, wat die bord bymekaargemaak het), wat later nuttige inligting kan wees.

Die vrystellingsetiket word bygevoeg tot die verbindingsgeskiedenis en dui die toestand van die lêers aan by die 1.0.0 -vervaardiging. Dit kan veral later baie hersienings nuttig wees as u na hierdie punt moet teruggaan vir probleemoplossing. Sonder 'n gespesifiseerde vrystellingsplaatjie, kan dit moeilik wees om uit te vind watter verbintenis die mees onlangse was ten tyde van die vervaardiging. Met 'n 1.0.0 (en 1.1, 1.1.1, ens) -merker kan u spesifiseer dat hierdie spesifieke bronlêers die lêers was wat in 'n spesifieke vervaardigingsloop gebruik is.

'N Nota oor Gerbers. Sommige fab huise benodig gerber lêers om u bord te maak, en u kan dit met KiCad genereer. Dit is afgeleide voorwerpe, gegenereer uit die bron.kicad_pcb lêer, en ons gebruik gewoonlik nie weergawe beheer afgeleide lêers nie. Ons by Brainbow stoor nie gerbers in weergawebeheer nie, behalwe as ons 'n vrystelling merk. As ons gereed is om te bou, genereer ons die gerber -lêers, stoor dit in die Fabrication -lêergids en verbind en merk dit. Dan verwyder ons die gerbers en verwyder dit. Dit kan aanvanklik 'n bietjie verwarrend lyk, maar dit verseker dat normaalweg slegs bronlêers gestoor word, en die gemerkte weergawes stoor ook die presiese lêers wat gebruik is om die borde te vervaardig. Dit was opmerklik nuttig om weke later produksiefoute op te spoor.

Stap 10: Volgende stappe

Hopelik het hierdie inleiding u genoeg geleer om weergawe -beheer op u eie elektroniese projekte te begin gebruik. Ons het nie by die meer gevorderde onderwerpe gekom nie, soos weergawebeheer vir biblioteke wat tussen projekte of funksietakke gedeel word. Tog is weergawe -beheer soos om jou groente te eet: jy kry dalk nie wat jy dink jy moet nie, maar elke bietjie tel.

Brainbow werk aan 'n meer gedetailleerde gids vir sommige van die meer gevorderde funksies van ons werkstroom. Ons hoop om dit in die komende maande te publiseer. Volg ons hier op Instructables, en ons sal u sekerlik laat weet wanneer u dit kan lees.

Dankie dat u gelees het, en ons kan nie wag om te sien wat u maak nie!