„Embedded software se nedá unit testovat, potřebujete hardware." Slýchám to často a platí to přesně pro jeden druh kódu: kód, který sahá na registry. Všechno ostatní, stavové automaty, parsery protokolů, řídicí logika, převody hodnot, je obyčejné C, které se přeloží na vašem PC. A na PC běží v milisekundách, bez debuggeru, bez kabelu a bez flashování.

Tento článek ukazuje, jak otestovat modul pomocí Unity (testovací framework) a CMock (generátor mocků), od návrhu, který to umožňuje, až po soubor CMake, který to sestaví. Všechno bylo sestaveno a spuštěno a výstupy níže jsou skutečné.

Můj coding style říká, že názvy souborů začínají názvem modulu a že „kompletní organizace souborů je popsána jinde". Tohle je to „jinde".

C nemá private, jmenné prostory ani balíčky. Jakmile je kód rozdělen do souborů, jsou soubory a build systém jedinými nástroji, kterými můžete říct, co k sobě patří, co je veřejné a co se nikoho jiného netýká. Organizace souborů tedy není věcí vkusu, je součástí návrhu. Tento článek popisuje, jak organizuji embedded projekt na třech úrovních: projekt, modul a jednotlivý soubor.

Řekněte „MISRA“ v místnosti plné embedded vývojářů a polovina si povzdechne, zatímco druhá se zeptá, jaký nástroj používáte. Pověst těchto pravidel je rozporuplná: pro některé je to byrokracie, která před každým vydáním sežere týden, pro jiné důvod, proč se auto na dálnici nerestartuje. Obě skupiny mají zčásti pravdu.

V tomto článku projdu pravidla, se kterými se setkávám nejčastěji, jedno po druhém: co pravidlo požaduje, co za to získáte, jak vypadá špatný kód, jak vypadá dobrý kód a kdo za vás problém najde. Všechny příklady jsou skutečný C kód, který jsem přeložil a spustil.

Pět písmen, která se objevují při každém pracovním pohovoru ze softwarového inženýrství. S, O, L, I a D. Principy byly popsány pro objektově orientované jazyky, a tak se běžně usuzuje: „SOLID je pro C++ a Javu, my píšeme v C, takže máme hotovo.“ Ten závěr je špatný a pokusím se ukázat proč. U každého principu najdete původní myšlenku s příkladem v C++ a potom tutéž myšlenku v C, bez tříd, bez dědičnosti a bez jediného virtual.

OCD. Tři skvělá písmena, která mě nutí neustále přemýšlet o architektuře softwaru. To může být opravdu bolestivé, zvlášť když se musím potýkat s architekturou v „arduinovském" stylu. Určitě ji znáte: celý projekt v pár složkách, aplikace ve složce src, nízkoúrovňová funkcionalita ve složce driver a tak dále. Ale co dělat ve složitých systémech?

Pro vývoj embedded softwaru je správný návrh nezbytný. Mikrokontrolér musí zvládat zpracování samotné aplikace i komunikaci s množstvím připojených obvodů přes interní či externí periferie. Provádění aplikace má být co nejrychlejší. To je ale pro kohokoli dost hrozné vysvětlení. V reálném světě musí vývojář zajistit optimálně krátkou logickou cestu provádění kódu. To znamená, že vývojář nemá v každém hlavním cyklu kontrolovat všechny podmínky. Jedním ze způsobů této optimalizace je správné vnořování podmínek. S rostoucí složitostí projektu to může být opravdu obtížné. Množství vnořených podmíněných příkazů může vést k nestabilitě kódu a zhoršit jeho čitelnost. Čitelnost kódu je přitom kruté nutná pro budoucí úpravy nebo údržbu existujícího kódu. Jeden z mých oblíbených citátů říká: