Volba prostředků pro řízení v reálném čase

Úvod

V předchozích číslech byl stručně popsán systém Combi-BaseBoard jako možný základ pro řízení reálných objektů (motor, průmyslový automat, meteo stanička) v reálném čase a s využitím komfortu nabízeného vestavěným operačním systémem Linux s Real-Time s rozšířením. Systém se skládá z modulu Combi s procesorem ARM9, velké paměti SDRAM a NAND Flash, programovatelného logického obvodu s rychlým datovým přístupem, řady rozhraní (Ethernet, USB Host a Function, SPI, I2C aj.) a základní desky BaseBoard se zdroji, industriálními I/O, reléovými výstupy, převodníky A/D, D/A, indikátory LED, čtečkou SD karet, sériovým rozhraním atd. Tato deska zajišťuje připojení k vnějšímu světu. Během zhruba dvou let, kdy se Combi architektura stala hardwarovým základem řady aplikačních desek, jsme často byli postaveni před otázku, jakými prostředky řešit určitý funkční požadavek. Řešení je vždy technicky zdůvodněným kompromisem mezi cenou, systémovými nároky, pracností vývoje a bezpečností. Deska BaseBoard1, jíž se týká tento článek, byla prvním pokusem nějak realizovat očekávané požadavky. Zkušenosti, dobré i špatné, mne vedly k následující úvaze.

Obr. 1 Blokové schéma a propojení systému Combi/BaseBoard1

Prostředky k dispozici

Řídicí elektronický systém má zpravidla řadu analogových čidel připojených k procesoru přes A/D převodníky, binární nebo vícebitové asynchronní vstupy a výstupy a další periferie. Problém je v tom, že programové vybavení musí obsloužit všechny tyto vstupy a výstupy bez prodlev, aby nedošlo ke ztrátě dat nebo neošetření události.

Procesor zpravidla pracuje sekvenčně v programové smyčce, z níž „odbíhá“ ošetřit nezávislé, asynchronní vnější události, které mu signalizují požadavky. Musí mít takovou rezervu výkonu, aby i v nejhorším případě, když nastanou všechny myslitelné události, byl schopen je obsloužit v jejich časovém limitu. Pokud by program cyklicky obíhal všechny možné zdroje asynchronních událostí a dotazoval se, je-li nějaká práce (polling), trvala by smyčka neúnosně dlouho a docházelo by ke ztrátám a opomínání událostí. Pokusme se vyjmenovat, jaké prostředky má vývojář k dispozici, aby tento požadavek splnil, a stručně zvážit jejich klady a zápory (omlouvám se za neúplný výčet, určitě by šlo přidávat a dlouze diskutovat). Deska BB1 nám bude ilustrací.

Pevně zapojené obvody jsou spolehlivé a rychlé (logika pracuje se zpožděním řádu desítek ns), ale postrádají možnost změny. Úkol zadání musí být vyřešen již ve fázi návrhu elektroniky, tedy poměrně brzy. S dostupností součástek bývají problémy, zabírají místo na desce plošného spoje, a proto se pevně zapojené obvody používají tehdy, kdy je to naprosto nezbytné, a přidávají se další požadavky (např. odolnost proti vysokonapěťovým špičkám, výkonové obvody atd.). Zpravidla jejich obsluha vyžaduje nějakou periodickou péči obslužných programů. Na desce BB1 je to například obvod zdroje, výstupních posuvných registrů (musíme zvolit periodu aktualizace reléových a opto výstupů). Obvody posuvných registrů zde nahrazují potřebu velkého množství výstupních portů procesoru za cenu obsazení kanálu SPI.

Programovatelná logika existuje v obrovském rozsahu, od jednoduchých obvodů CPLD/GAL až po obří FPGA s miliony prvků na čipu. Je zde problém volby jejich velikosti podle požadavků. Jistou laťkou, dělící je na „malé“ a „velké“, je přístup procesorem do těchto obvodů, jako by to byla sdílená paměť nebo registry v adresním prostoru periferií. Proto je potřeba velké množství vývodů na data, adresy a další signály. S velikostí roste i cena a spotřeba. Proto, neznáme-li přesně současné a budoucí nároky a požadavky, volíme takového člena rodiny programovatelných logických obvodů, který má vývody uspořádané kompatibilně s dalším nebo několika dalšími členy rodiny, abychom variantním osazením mohli reagovat na rozmanité požadavky. Zpravidla výrobci takovou možnost nabízejí. Je třeba mít na mysli, že programování se provádí po zapnutí, a tedy náběh funkce je pomalý. Tyto obvody jsou také o něco méně spolehlivé než pevné obvody (může selhat programování, vstupy bývají citlivé na statické výboje, takže zde musejí být nějaké ochrany) a často jsou dražší a mají větší spotřebu. To je daň za univerzálnost.

Obr. 2 Sestava Combi/BaseBoard1

Na desce BB1 je „velký“ obvod FPGA od Xilinxe, kde je možno využít rychlý datový přístup přes paměťový prostor procesoru. Část vývodů obvodu je vyvedena na konektor s jen jednoduchou ochranou, tvořenou sériovým odporem a obvodem na čipu. Optické vstupy využívají vstupy do obvodu FPGA, protože lze očekávat velké množství asynchronních událostí (čidlo polohy v Grayově kódu nebo obousměrný čítač) s frekvencí až stovek MHz a reálné je komunikovat s CPU řádově po milisekundách.

Aplikačně specifické obvody, včetně akcelerátorů a podřízených procesorů, je radno použít tehdy, když jsou přímo „šité“ na danou aplikaci. Je sice možno použít obvod i jinak, ale na základě špatných zkušeností s nedokumentovanými módy a funkcemi bych to nedoporučoval, zejména s nejnovějšími obvody, které mívají i různé nedodělky a chyby a jejichž funkce je zaručena prakticky jen v katalogovém zapojení a s firmwarem přímo od výrobce. Do této skupiny patří i různé komunikační a grafické řadiče a akcelerátory, například řadič sériové komunikace s FIFO bufferem. Opět použití v módu popsaném v katalogu je zpravidla bez chyb, ale běda, chcete-li měnit nějaké parametry nad rámec dokumentace. Tyto obvody jsou rychlé a zatěžují CPU málo, ale bývají dosti drahé. Příklad na BB1: obvody A/D a D/A, čidlo tlaku.

Každý moderní procesor, až na ty nejlevnější, nabízí konstruktérům svoje mechanismy pro zachytávání asynchronně přicházejících událostí a požadavků na obsluhu v podobě mechanismu přerušení nebo DMA. Přerušení je možno často přiřadit jakémukoli vstupnímu portu, takže přišlá hrana či impuls na tomto vstupu vyvolá obslužný podprogram. DMA přenos se používá u datově orientovaných periferií, kdy žádost na vstupu způsobí vygenerování cyklu(ů) sběrnice, anebo u integrovaných periferií interní přenos dat. Příkladem může být integrovaný grafický řadič, který využívá přístupu do paměti procesoru pro nabrání zobrazovaných dat. Zpoždění nebo perioda těchto činností jsou v řádech jednotek μs až ms. Bohužel volných vstupů je vždy nedostatek, takže se zřetězují periferní obvody, připojené na společný vstup žádosti. Obslužný program tak nejprve musí zjistit zdroj žádosti a pak ji obsloužit, takže latence je větší, kolem desíti μs. Na desce BB1 tento mechanismus není využit, ale na systémovém konektoru je několik použitelných vstupů. Signály na IDE konektorech vedou do FPGA, který by musel používat svůj mechanismus přerušení do CPU.

Real-Time orientovaný operační systém tyto hardwarové mechanismy využívá. Zpravidla používá nějaký interní časovač, jehož výstupní frekvence generuje požadavky na periodické přerušení. RT OS svým procesům přiděluje priority tak, aby časově náročné a často se opakující žádosti byly obsluhovány včas (s opakovací frekvencí stovek kHz nebo prodlevou desítek μs), a současně musí zbývat na ostatní procesy na pozadí (např. zápis na disk nebo kartu či běh komunikačního protokol-stacku). To poskytuje rozumný kompromis a soulad mezi rychlými nebo periodickými akcemi a komfortem na úrovni práce s PC. Programátorům tento mechanismus nabízí téměř luxus neprocedurálního programování.

Závěr

Pokusil jsem se vyjmenovat některé prostředky pomáhající konstruktéru vypracovat návrh mechanismu provádějícího v reálném čase řídicí akce a další potřebné činnosti. Časové charakteristiky jsou dosti vágní a konstruktér musí často používat intuici založenou na znalosti podobných systémů.

Bohužel nemohu nabídnout žádné pravidlo pro volbu mezi jednoduchým levným procesorem s jednoduchým softwarem psaným znovu a znovu od nuly, anebo složitým a dražším systémem s RT OS systémem. Zdá se mi však, že často jsou voleny kvůli úsporám příliš jednoduché systémy a když potíže vývoje narůstají, vývojáři sami sebe „uženou“. Proto si dovolím jim poradit, aby si dobře rozvážili způsob řešení úkolu ve své celé složitosti.