česky english Vítejte, dnes je středa 25. prosinec 2024

Pět tipů na značení verzí embedded systémů

DPS 1/2020 | Články
Autor: Jacob Beningo, Beningo Embedded Group, LLC

Jedním z úkolů při vývoji embedded systémů je značení jejich verzí (revizí). Každý embedded systém má dvě primární složky, které je potřeba vhodně označit kvůli jejich kompatibilitě – hardware a software. I když se to může zdát jednoduchou úlohou, nebývá už tak jednoduché nalézt nejvhodnější způsob značení navazujících verzí hardwaru a softwaru. Cílem tohoto článku je upozornit na pět možných tipů v souvislosti se zápisem verzí.

Použití nevyužitých GPIO pro značení verze desky

Značení verze hardwaru v potisku desky plošných spojů bývá u embedded systémů jednou z možností. Problémem je skutečnost, že software neumí číst informaci v potisku desky. V některých aplikacích se může deska změnit mezi dvěma verzemi natolik, že je potřeba zajistit, aby na ní běžela správná verze softwaru. Proto by mělo být možné, aby si software mohl číst verzi hardwaru sám.

Nabízejí se dvě možnosti, jak zajistit, aby si software mohl číst verzi hardwaru. Pokud má systém nějaké nepoužité piny GPIO (General Pin Input Output), potom mohou být dva nebo tři z nich využity k indikaci verze hardwaru. Každý pin GPIO může být připojen na VCC (reprezentováno jako 1) nebo zem (reprezentováno jako 0). Když se použije binární reprezentace, potom 2 piny GPIO mohou zajistit značení až 4 verzí hardwaru, zatímco 3 piny GPIO až 8 verzí – viz tabulka 1.

Pět tipů na značení verzí embedded systémů

Ne všechny systémy mají dva nebo tři piny GPIO volné k tomuto použití. Místo nich mohou vývojáři také využít nepoužitý kanál A/D převodníku a použít určité analogové napětí k reprezentaci verze hardwaru. V takovém případě by byl ADC připojen do odporového můstku, u kterého je jeden rezistor připojen na VCC a druhý na zem. Hodnoty rezistorů by byly nastaveny tak, aby zajistily určité napětí, které reprezentuje určitou verzi hardwaru. U aplikací s nízkým příkonem by měly být hodnoty rezistorů dostatečně velké, aby obvod neodebíral příliš velký proud.

Použití sémantiky MAJOR.MINOR.PATCH

Existuje několik různých možností, jak značit verze softwaru, ale jedna možnost, která vyhovuje většině vývojářů softwaru, je založena na sémantice typu MAJOR.MINOR.PATCH, například 1.0.0, 1.1.2, 2.4.2, atd.

Výraz MAJOR představuje hlavní číslo verze, které se mění pouze v případě změny, která způsobí nekompatibilní API. V podstatě to znamená, že verzi zvýšíme po změnách v kódu, který potom není zpětně kompatibilní. Hodnota výrazu MINOR je zvyšována pouze tehdy, když se provede změna, která je zpětně kompatibilní s existujícími API. Výraz PATCH představuje drobné úpravy v softwaru a zvyšuje se pouze tehdy, když se v softwaru opraví chyby.

Významu této sémantiky pro značení verzí softwaru rozumí každý vývojář.

Vytvoření souboru version.h

Z mé zkušenosti je nejefektivnější vytvořit záznam verze softwaru pomocí souboru (modulu, file header, resource file, …) nazvaného version.h, který vytvořím. Ten zahrnuje sémantiku typu Major.Minor.Patch spolu se záznamem o změně. Číslo verze může být pro software snadno nastaveno použitím makra, jako je toto:

#define VERSION_MAJOR (1)

#define VERSION_MINOR (0)

#define VERSION_PATCH (0)

Vývojář může dokonce nastavit minimální verzi hardwaru, která umožňuje použití softwaru, takto:

#define HARDWARE_VERSION_MIN (4)

Důležitou součástí souboru version.h není jen číslo verze softwaru, ale také informace o změně verze. To může být zajištěno pomocí komentářů zahrnujících informace, jako jsou např.:

  • verze softwaru,
  • datum změny souboru version.h,
  • změny v souboru version.h.

V mých vlastních záznamech verzí vždy uvádím změny v horní části souboru, abych nemusel procházet záznam až dolů k prohlédnutí změn provedených v předcházející verzi.

Nevytvářet verze pro soubory a funkce

Způsob, jakým jsou verze embedded aplikací vytvářeny, je zcela na vývojovém týmu, ale i tak mám jedno doporučení – vyhnout se vytváření verzí na úrovni souborů (modulů) a funkcí, pokud je to možné. Tím je míněno: nechceme přiřazovat verze jednotlivým C modulům, nebo funkcím. Jinak si přiděláváme zbytečnou práci, která navíc může vést k tomu, že značení verzí bude nakonec špatně.

Tak například, když jsem provedl změnu ve funkci Dio_Write, nechci zvýšit číslo verze pro tuto funkci, ale chci aktualizovat číslo verze pro celou složku, ve které Dio_Write je. Když začnu přiřazovat funkci číslo verze, musím mít také verzi modulu, složky a softwaru. Když tyto verze zapomenu někde aktualizovat, potom je celý zápis verzí ztracen. Nejlepší tedy je, se zápisu verzí na této nízké úrovni vyhnout.

Integrujte VCS s vaším IDE

Důležitým aspektem verzí softwaru je, jak je software integrován do systému pro ovládání verzí (VCS – Version Control System). Nejoblíbenější je dnes pravděpodobně Git, ale někteří vývojáři používají také SVN, Mercurial a další. Když se u softwaru zadávají jeho verze, zjistil jsem, že je poměrně důležité se ujistit, že je funkčnost systému VCS integrována do vašeho vývojového prostředí tak, aby bylo možné provádět potřebné změny jednoduše a snadno. Tak například mnohé VCS plug-ins dovolí vývojáři kliknout na jedno tlačítko a nové změny budou přidány. Přitom vyskočí dialogové okno, které mu umožní komentovat provedené změny. To nabízí perfektní příležitost ke kopírování změn zapsaných v souboru (modulu) version.h a přenést je do záznamu VCS. V takovém případě jsou všechny informace o verzích softwaru a VCS stejné.

Závěr

Zavedení verzí u embedded systémů nemusí být komplikované. Čím je způsob přiřazení verzí jednodušší, tím je menší pravděpodobnost vzniku zmatků a nedopatření způsobených nesprávnou verzí hardwaru nebo softwaru. Bez ohledu na to, který systém pro zápis verzí je použit, vývojáři musí přistupovat k verzím disciplinovaně, aby byl proces úspěšný.

Poznámka – připomínky čtenářů:

Je velmi těžké si udržet přehled o kompatibilním softwaru a hardwaru, když se jedná o více produktů. Jednou možností je použít takový způsob zápisu verzí softwaru a hardwaru, ze kterého lze jednoduše vyčíst, které verze jsou kompatibilní. Když máme například šestimístnou verzi softwaru (123-456), která reprezentuje MA JOR-MINOR zápis a podobně šestimístnou verzi hardwaru (123-456), potom zápis 123456-123456 v potisku na desce plošných spojů je dostatečně intuitivní k tomu, aby se nemíchaly nekompatibilní verze softwaru a hardwaru, alespoň po dobu, po kterou je zavedený způsob značení verzí udržován.

Lepší náhled a porozumění, co zdrojový kód vyžaduje, umožňuje snížit počet nezbytných revizí softwaru a tím i verzí. Datování každého kousku kódu je také dobrá metoda ke sledování, co je vlastně aktuální. Pochopitelně, že celá záležitost se řeší lépe v malém kolektivu, který rozumí celému projektu, než když tisíce programátorů v různých částech světa píší pouze několik řádků kódu.

Originál článku (5 Tips for Versioning Embedded Systems) byl publikován na DesignNews dne 23. 9. 2019 (www.designnews.com/electronics-test/5-tips-versioning-embedded-systems/93647737161546)