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

Vývoj aplikací s moduly SQM4: Začínáme s Xilinx Zynq – 6. díl

DPS 4/2016 | Články
Autor: Michal Hanák

V tomto, již šestém, pokračování našeho seriálu o platformě Zynq®-7000 Xilinx® All Programmable SoC a modulech SQM4 konečně opustíme vývoj programovatelné logiky a zaměříme se na vývoj software. Naším cílem bude připravit aplikaci, která komunikuje s uživatelem prostřednictvím sériové konzole nebo přes Telnet protokol a řídí periferii řadiče displeje, jejíž syntézou v hradlovém poli jsme se zabývali v předchozích číslech. Úvodem však nejprve trocha teorie.

Hradlová pole a softprocesory

Procesorová jádra hrají důležitou roli v naprosté většině produktů společnosti Xilinx. Historicky se jednalo o výpočetní a výkonné jednotky uměle syntetizované přímo v logice hradlového pole a softwarový vývoj zde byl plně závislý na tom, jak byl každý takový procesor navržen. Dodnes jsou na internetu k dispozici projekty, které v hradlových polích umožňují použíti syntetických „klasických“ procesorů jako např. Zilog Z80, Intel 8051 nebo Siemens C166. Firma Xilinx představila již před více než 15 lety rychlé 8bitové mikroprocesorové jádro PicoBlaze, které se stalo velmi populární, protože jej bylo možné syntetizovat i v těch nejmenších obvodech, a to dokonce v mnoha instancích jako multiprocesorový systém. Známý je například projekt využívající dokonce tisíc PicoBlaze jader v jediném systému, který tvoří zaklad obřího LED televizoru na Times Square v New Yorku. Pro seriózní práci představila firma Xilinx i vlastní 32bitový procesor MicroBlaze, který podpořila bohatou sadou nástrojů včetně kompletního grafického vývojového prostředí. V roce 2009 se stal Micro-Blaze prvním syntetickým procesorem plně podporovaným standardními distribucemi GCC a Linuxu.

Syntetické tzv. softprocesory mohou ovšem z hlediska softwarového inženýra představovat poměrně složitou a jaksi „neuchopitelnou“ problematiku. To, že procesor v době startu systému vlastně neexistuje a je potřeba nejprve nahrát kód programovatelné logiky, je jen zanedbatelná komplikace.

Často mnohem zásadnější bariérou je, že obrovské množství volitelných nastavení jádra i možností periferních obvodů syntetického procesoru vyžaduje úzkou spolupráci mezi softwarovými a FPGA vývojáři. I malá chyba v návrhu FPGA může zásadně ovlivnit vývoj softwaru; hranice mezi stavem, kdy „systém funguje spolehlivě“, a stavem, kdy „nefunguje nic“, je poměrně tenká a během vývoje se často překračuje. Naprostá většina projektů nakonec rezignuje na kreativitu a z nekonečného počtu způsobů toho, „jak“ systém v hradlovém poli sestavit, vybere takový, který je doporučen výrobcem a pro který existuje již dostatečné množství příkladů a dokumentace.

Platforma Zynq je vlastně postavena na jednoduché myšlence. Místo toho, aby si vývojáři znovu a znovu konfigurovali MicroBlaze stejným způsobem včetně doporučených periferií, přinese Zynq výkonnou procesorovou jednotku a běžné periferie přímo na čipu a umožní tak zákazníkům v FPGA řešit už jen opravdu nestandardní a velmi specifické úkoly.

Duše softwarového inženýra může zůstat v klidu, protože vyvíjí pro pevně danou, reálnou hardwarovou platformu a jeho závislost na FPGA vývojářích se minimalizuje. Pro vývoj nejnižší vrstvy softwaru, takzvanou Board Support Package (BSP), která má na starosti nastartování procesoru, inicializaci paměti a základních komunikačních periferií, pak softwarový inženýr nepotřebuje s „lidmi přes FPGA“ dokonce mluvit vůbec.

S trochou nadsázky můžeme v duchu předchozího odstavce pokračovat a tvrdit, že až modul SQM4-ZY7 skutečně osvobozuje vývojáře od rutinních úkolů, které je potřeba při práci s takto složitou technologií opakovat znovu a znovu, a umožňuje jim soustředit se na vlastní vývoj toho, v čem je projekt unikátní. S modulem SQM4-ZY7 již není třeba řešit, jak k Zynq připojit různá napájecí napětí, paměť DDR3, bootovací Flash, gigabitový ethernet nebo USB. Vše je již připraveno ve velmi kompaktním provedení o rozměrech 42 × 42 mm s možností povrchové montáže na základní desku nebo i připojení pomocí patice. V kombinaci s prototypovou základní deskou EasyBoard se vývoj pro Zynq dokonce blíží práci s jednoduchými mikrokontroléry, a to vše bez zásadních omezení ve výkonnosti procesorových jader a ve využití hradlového pole.

Pro vývoj softwaru s platformou Zynq je určeno vývojové prostředí Xilinx SDK založené na oblíbeném (ale i často zatracovaném) projektu Eclipse/CDT. V SDK je možné vygenerovat i knihovnu BSP, ve které je uložen kód pro inicializaci procesorové jednotky, pinů (MIO) a řadiče pamětí DDR. Generátor BSP kódu vyžaduje jako vstup soubor s příponou hdf, který lze exportovat z existujícího projektu Vivado. V blokovém diagramu ve Vivadu totiž probíhá značná část konfigurace parametrů procesorového systému – například výběr aktivních periferních modulů, typ použité paměti apod. Vivado má tedy teoreticky všechny informace nutné pro sestavení funkčního BSP.

V předchozích dílech seriálu jsme nastavení procesorového systému ve Vivadu nemuseli příliš řešit, protože jsme použili hotovou konfiguraci připravenou pro modul SQM4-ZY7. Při práci s modulem bychom dokonce nemuseli ani generovat vlastní BSP, bez problémů bychom mohli použít BSP z příkladů na stránkách www.sqm4.com. Nicméně je přece jen lepší generovat BSP pro každý projekt zvlášť, a to i v případech, kdy se zapojení procesoru nemění. Při generování BSP totiž jako vedlejší produkt dostáváme i hlavičkový soubor jazyka C, kde jsou uvedeny bázové adresy všech periferií včetně těch syntetizovaných v FPGA – a ty jsou samozřejmě specificky různé v každém projektu.

Postup generování BSP v nástroji SDK je velmi intuitivní. Základem pro BSP je vytvoření tzv. Hardware Platform projektu, který obsahuje vlastní nastavení procesorového jádra ve formě výchozích hodnot konfiguračních registrů Zynq ve formátu jazyka C a skriptovacího jazyka TCL. Inicializační funkce v C [nazvaná ps7_init()] je dále použita v samotném softwarovém projektu, kód TCL používá debugger pro kompletní inicializaci platformy před nastartováním aplikace během ladění kódu. Díky TCL skriptu je debugger schopen inicializovat čip do stejného stavu, do jakého jej v normálním případě nastaví zavaděč (bootloader). Po vytvoření Hardware Platform už pak stačí jen vybrat, jaké ovladače má nově vygenerované BSP obsahovat. Pokud plánujeme BSP využít i pro sestavení standardního, tzv. First-Stage Bootloaderu (FSBL), je dobré přidat minimálně ovladače FFS a RSA.

First-stage Bootloader

O zavaděčích a projektu FSBL jsme dosud nehovořili, ale koncept je velmi jednoduchý. Zavaděč je vlastně obyčejný program sestavený nad knihovnami BSP a Hardware Platform, jehož hlavním úkolem je inicializovat procesor, paměť a základní periferie, z vybraného úložiště načíst soubor s bitovým obrazem pro FPGA, nakonfigurovat FPGA a nakonec načíst a spustit finální aplikaci. Všechny tyto úkony může samozřejmě kdokoliv naprogramovat přímo v rámci aplikace. Všechny potřebné informace jsou k dispozici – inicializační kód je připraven v rámci Hardware Platform a postup programování FPGA je plně dokumentován. FSBL je vlastně jen ukázkový kód dodávaný v sadě příkladů spolu s Xilinx SDK, který zavedení FPGA a programu řeší za nás. Navíc má další zajímavé funkce jako podporu načítání aplikací z QSPI paměti nebo z SD karty, případné dekryptování souborů apod.

Hello World

S funkčním BSP už nám nic nebrání vytvořit aplikační projekt a věnovat se konečně softwarové práci. Nejrychlejší cesta k novému projektu je použít průvodce, vybrat BSP a šablonu Hello World. Stačí opravdu jen několik kliků myši a v SDK budeme mít připraven funkční kód, který ve funkci main() vytiskne toto základní zvolání z počátku digitálního věku. Vygenerovaný projekt je správně nastaven tak, aby použil drivery z knihovny BSP. Jestliže tedy nastavíme UART terminál stejně, jako jsme definovali v nastavení procesorového systému ve Vivadu, bude textový výstup fungovat podle očekávání. Možná trochu paradoxně najdeme ve vygenerovaném aplikačním kódu i zakomentované volání funkce ps7_init(). Toto volání je zakázáno záměrně, aplikace je totiž připravena na spuštění buď v režimu ladění pod debuggerem (kde inicializaci procesoru zajistí TCL skript), nebo v normálním samostatném režimu, kdy inicializaci zajistí FSBL. Jen v případě, že se od aplikačního kódu očekává vlastní inicializace celé platformy, je možné volání ps7_init povolit a nechat kód z projektu Hardware Platform vykonat vše potřebné.

FNET aneb jde to i bez Linuxu

Pro mnoho projektů je nasazení Linuxu na platformě Zynq jistě správným krokem umožňujícím plnohodnotné využití výpočetních, komunikačních i multimediálních možností, které dvoujádrový procesorový systém CortexA9 nabízí. Periferní obvody syntetizované v programovatelné logice je možné poměrně snadno obsloužit formou ovladačů a modulů zavedených přímo do jádra operačního systému. Zní to možná složitě, ale takový vývoj je opravdu jednoduchý a je podpořen velkým množstvím ukázkových projektů a hotových aplikací.

Stále ovšem existují a budou existovat aplikace a úlohy, ve kterých je nasazení Linuxu nevhodné. Zpracování signálů, kódování a jiné zpracování video či audio zdrojů, analýza obrazu, to mohou být příklady projektů, kde je těžiště celého řešení v hradlovém poli samotném a pro procesorové zpracování a komunikace zcela postačí jednoduchý RTOS, nebo dokonce i prostá jednoduchá jednovláknová aplikace. Na internetu jsou pro Zynq k dispozici příklady nasazení systému FreeRTOS a síťové komunikační knihovny lwIP. V rámci podpory modulu SQM4-ZY7 jsme se ale rozhodli jít tak trochu vlastní cestou a připravili jsme port výkonné komunikační knihovny FNET. Projekt FNET původně vznikl jako TCP/IP řešení pro procesory firmy Motorola a Freescale (dnes NXP); díky přívětivým licenčním podmínkám jsme si mohli kód rozšířit i na platformu Zynq. Projekt FNET prošel od svého založení v roce 2008 značným vývojem a stal se skvělým řešením nejen pro duální IPv4 a IPv6 konektivitu, ale také platformou pro vývoj aplikací s jednoduchými operačními systémy i bez nich. V základní verzi obsahuje kromě vlastní TCP/IP komunikace, aplikačních protokolů HTTP, Telnet, TFTP apod. i jednoduchý interpret příkazové řádky, rozhraní pro přístup k externí paměti a další užitečný kód nezbytný pro většinu běžných aplikací „mikrokontrolérového“ typu.

Pro potřeby aplikace řízení jednoduchého syntetizovaného řadiče displeje, kterou se zabýváme v tomto seriálu, představuje FNET skvělé řešení. Všem uživatelům modulu SQM4-ZY7 jej můžeme vřele doporučit.

Příště

Příště si prakticky ukážeme, jak v kódu nastavit registry syntetizovaného řadiče displeje a jak celou aplikaci ovládat pomocí příkazové řádky nejen přes UART, ale i přes Telnet nebo webový prohlížeč.