Programování MCU v QtCreatoru

12.1.2016 16:00 | Přečteno: 2160× | Programování | | poslední úprava: 12.1.2016 15:58

Tento článek popisuje, jak použít vývojové prostředí QtCreator na programování bare-metal mikropočítačů. Celý postup je pro ukázku aplikován na cenově dostupný vývojový kit STM32F4 Discovery, ale pouze s minimálními obměnami je aplikovatelný i na ostatní vývojové kity od STMicroelectronics nebo i od jiných výrobců.

Situace na trhu IDE

Pro programování mikropočítačů existuje nepřeberné množství komerčních a free IDEček. Prakticky každý větší výrobce má vlastní odnož Eclipsu která je použitelná zadarmo, nebo jen s mírnými omezeními. Pak existují nezávislá komerční prostředí založená na Eclipsu (např. Atollic TrueStudio, Tasking, ..), která kromě poměrně vysokých cen nenabízejí příliš mnoho přidané hodnoty. Mimo to jsou široce používané ne-Eclipse prostředí Keil uVision a IAR Workbench, jejich cena je ale pro menší projekty dost vysoká. Během posledních let lze také použít samotný čistý Eclipse za použití sady pluginů GNU ARM Eclipse (http://gnuarmeclipse.github.io). A když člověk nechce drahá prostředí ani Eclipse, může použít třeba Em::Blocks (www.emblocks.org) a nyní také QtCreator, který je předmětem tohoto článku.

Na tomhle místě si nemůžu odpustit menší rant proti chování Eclipsu - specificky CDT - které se objevuje úplně ve všech verzích od všech výrobců. Ve chvíli, kdy jakkoliv modifikujete projekt (třeba přidáním dalšího adresáře se soubory které se mají kompilovat) nebo i přepnete aktuální konfiguraci z Release na Debug, tak vám Eclipse zmodifikuje soubor .cproject a udělá tam změny. A to ve stylu že odebere nějaký řádek a místo toho tam ten samý řádek přidá o kousek vedle. To pak logicky dělá bordel ve verzovacím systému, takže někdy je nutné soubor stagovat po řádcích a někdy to tu konfiguraci pozmění natolik že vám nezbyde nic jiného než ten soubor commitnout celý.

Proč QtCreator

QtCreator byl původně a primárně vyvíjen pro použití s Qt knihovnou a tomu také odpovídá jeho funkcionalita. Jak se na něj postupně nabalovaly další a další části (vývoj pro Symbian, Android, QNX, Meego), stalo se z jednoduchého IDEčka něco, co podporuje obrovské množství cílových platforem a zároven si ponechává svůj jednoduchý vzhled a pokročilá funkcionalita je přehledně a snadno dostupná. Kromě účelného designu lze vyzdvihnout také podporu pluginů (Beautifier, ToDo, systémy pro správu verzí), podpora GDB s Python skriptováním nebo třeba integraci Valgrindu. Subjektivně má QtCreator z autorem používaných IDEček asi nejlepší Code Model (který lze případně nahradit Clang backendem.)

Čím začít?

Nejdříve je nutné zapnout některé pluginy, ty lze nalézt v menu Help->About Plugins.

 

V tomto okně je nutné zapnout pluginy QbsProjectManager, BareMetal a případně další (Beautifier, Todo,...) podle požadavků. Tím se v nastavení QtCreatoru objeví další položky, které si nyní probereme.

Nastavení GDB serveru

První z položek je sekce BareMetal. V ní je možné spravovat poskytovatele GDB serveru. Aktuálně QtCreator podporuje 3 a těmi jsou ST-Link, OpenOCD a Default. ST-Link je debugger, který se typicky nachází na vývojových kitech od společnosti STMicroelectronics a lze ho provozovat na Windows s nástroji od výrobce a na Linuxu s opensource klonem (www.github.com/texane/stlink.) OpenOCD je generický debuggovací server, který podporuje nepřeberné množství procesorů, hardwarových debuggerů a má i předpřipravené konfigurace pro známé vývojové kity. Ve většině Linuxových distribucí se OpenOCD nachází ve standardních repozitářích. Typ Default lze pak použít pro GDB server, který je spuštěný samostatně mimo QtCreator (a může být vzdálený). Všechny 3 typy lze také používat vzdáleně - např. tak že si v práci do počítače zapojíte vývojovou desku, spustíte tam GDB server a pak se k němu odjinud připojíte.

Příklad

Pro ukázku si tady vytvoříme GDB Server typu OpenOCD a dáme mu název STM32F4 Discovery OpenOCD.

V nastavení vybereme Startup mode: Startup in TCP/IP Mode aby nám QtCreator při debugování sám OpenOCD spustil. Dalé je nutné vyplnit kde máme OpenOCD nainstalované, a kde jsou uložené jeho skripty (výchozí umístění v mojí distribuci je možné vidět na obrázku.) Aby se OpenOCD bylo schopné připojit k procesoru na cílové desce, je nutné mu předhodit ještě konfigurační soubor, který se použije pro nakonfigurování OpenOCD. Ten je možné nastavit do položky Configuration file (tak jak je to na obrázku), nebo je možné ho OpenOCD předat pomocí Additional arguments - např takto:

-f board/stm32f4discovery.cfg

Tento způsob je nutné použít pokud máte nestandardní kombinaci hardwarového debuggeru a cílového procesoru - prostě použijete 2 konfigurační soubory, např. takto:

-f interface/jlink.cfg -f target/stm32f4x.cfg

Do sekce Init commands jsem si doplnil příkaz monitor arm semihosting enable, aby mi OpenOCD zachytávalo přesměrování printfu do IDE.

Pokud chcete, aby se program zastavil na začátku mainu, můžete přidat příkaz break main.

Cílové zařízení

Další sekce v menu, kterou se budeme zabývat je Device. QtCreator umožňuje jako cílové zařízení přidat buďto Generic Linux Device (vhodné například pro vývoj na embedded modulech s Linuxem - Toradex Apalis T30, Freescale IMx6, apod. ), nebo QNX, a nebo Bare Metal Device, což je volba která nás aktuálně zajímá.

Příklad

Aktuálně tu lze nastavit pouze poskytovatele GDB serveru, takže si nyní vytvoříme nové Bare Metal Device a nastavíme mu jako GDB Server Provider námi vytvořený STM32F4 OpenOCD.

Nastavení kompilátoru a debuggeru

Než budeme pokračovat dále, je nutné si sehnat toolchain (sada assembleru, kompilátoru, linkeru, gdb,...) Pro ARM Cortex-M a Cortex-R existuje projekt GCC ARM Embedded (launchpad.net/gcc-arm-embedded) který poskytuje opatchovaný toolchain ve formě zdrojových kodů i připravených binárek pro různé operační systémy. Prozatím bych doporučoval se držet GCC 4.9.

Pokud již máme někde připravený toolchain, můžeme v QtCreatoru pokračovat do sekce Build & Run. Nejdříve na záložce Debuggers vytvoříme nový záznam a v něm nastavíme cestu k GDB v připraveném toolchainu. Protože QtCreator vyžaduje GDB s podporou skriptování v Pythonu, je nutné použít binárku arm-none-eabi-gdb-py. Tato binárka je dynamicky slinkovaná a vyžaduje ke běhu 32bitovou variantu Pythonu 2.7. Případné chybějící knihovny je možné vyhledat pomocí příkazu ldd. Stejným stylem si pak na záložce Compilers vytvoříme nový záznam pro kompilátor. Pokud máme kompilátor a debugger, můžeme přejít k hlavnímu programu - dát to všechno dohromady. To uděláme na záložce Kits a v podstatě tam jen vyplníme správnou kombinaci zařízení, kompilátoru a debuggeru. No a pokud tohle máme, jsme připraveni k vytvoření projektu a vývoji na mikropočítačích.

Vytvoření projektu

Při vytváření projektu vybereme volbu Non-Qt Project -> Plain C Application. V průvodci pak následně vyplníme jméno a umístění projektu a pak build system, kde vybereme Qbs. Následně se nás QtCreator zeptá na to, kterým Kitem (kde a jak) chceme projekt provozovat. Tam vybereme Kit, který jsme si vytvořili v předcházející kroku. Takto vytvořený projekt bychom mohli rovnou překládat na lokálním pročítači, ale pro vytvoření binárky pro mikropočítače je zpravidla nutné přidat další volby pro kompilátor a linker.

Aktuálně pro Qbs neexistuje žádný průvodce, který by nám umožnil si všechny potřebné volby naklikat, takže jr budeme muset nastavit ručně v projektovém souboru. Nastavení předpřipravených flagů do textového souboru ale není žádná rocket science, takže si s tím poradíme. Naším cílem bude vytvořit program pro vývojový kit STM32F4 Discovery, který bude (jak jinak) blikat LEDkou a posílat textové výpisy na standardní výstup. K tomu budeme potřebovat nějaké předpřipravené knihovny od výrobce desky, spolu s nějakou jednoduchou vrstvou, která se nám postará o přesměrování výstupů. Já vycházím z existujícího projektu, který jsem si vytvořil v Eclipsu s pluginem GNU ARM Eclipse, ale stejně tak lze použít například STM32Cube-MX, který umí vygenerovat projekt s předkonfigurovanými periferiemi. Mnou použité soubory je možné nalézt zde ( http://gitlab.fai.utb.cz/format/QtBlinky)

Product {
   type: "application"
   Depends { name:"cpp" }
   cpp.defines: ["STM32F407xx", "TRACE", "OS_USE_TRACE_ITM", "OS_USE_SEMIHOSTING"]
   cpp.positionIndependentCode: false
   cpp.debugInformation: true
   cpp.commonCompilerFlags: [
       "-mthumb","-mcpu=cortex-m4",
       "-mfloat-abi=hard","-mfpu=fpv4-sp-d16",
       "-fdata-sections","-ffunction-sections",
       "-fno-inline","-std=gnu11", //"-flto"
   ]
   cpp.linkerFlags:[
       "-flto","-mthumb","-mcpu=cortex-m4",
       "-mfloat-abi=hard","-mfpu=fpv4-sp-d16",
       "-Wl,--start-group",
       "-Wl,--gc-sections",
       "-nostartfiles", "-Xlinker",
       "-T" + sourceDirectory + "/ldscripts/libs.ld",
       "-T" + sourceDirectory + "/ldscripts/mem.ld",
       "-T" + sourceDirectory + "/ldscripts/sections.ld",
       "-lnosys","-lgcc","-lc",
       "--specs=rdimon.specs",
       "-lrdimon"
   ]
   cpp.includePaths: [
       'include',
       'system/include',
       'system/include/arm',
       'system/include/cmsis',
       'system/include/cortexm',
       'system/include/diag',
       'system/include/stm32f4-hal'
   ]
   files: [
       "src/*",
       "system/src/cmsis/*",
       "system/src/cortexm/*",
       "system/src/diag/*",
       "system/src/newlib/*",
       "system/src/stm32f4-hal/*",
   ]
   Properties {
       condition: qbs.buildVariant === "debug"
       cpp.defines: outer.concat(["DEBUG=1"])
   }
   Group {
       qbs.install: true
       fileTagsFilter: "application"
   }
}

Prvně je nutné nastavit překladači pro jaký procesor a s jakou instrukční sadou se bude překládat. To se provede volbami -mcpu=cortex-m4 (protože na vývojovém kitu je procesor STM32F407VG, který je typu Cortex-M4) a -mthumb. Dále je vhodné překladači nastavit, jaký typ float-pointu budeme používat; float ABI může být budto soft (pro softwarovou implementaci floating pointu), nebo můžeme použít hardwarovou floating point jednotku - kterou je pak nutné specifikovat. Náš vzorový projekt také využívá části inline assembleru, proto je nutné nastavit typ používaného standardu například na -std=gnu11.¨

Aby se projekt správně slinkoval a aby byl stack, heap, a další sekce na správných místech, je nutné použít linker scripty, které jsou specifické pro procesor (nebo rodinu procesorů).

Pro použití semihostingu (tedy přesměrování I/O na host PC) je nutné přidat mezi linker flagy volbu --specs=rdimon.specs. Samotné povolení/zakázání semihostingu se v tomto příkladu provádí definem OS_USE_SEMIHOSTING. U semihostingu je potřeba pamatovat na to, samotný akt posílání výstupu pryč přes SWD kanál debuggeru procesor blokuje, a může tedy vést ke zpomalení programu a případnému rozhození časování.

Reference

http://doc.qt.io/qbs/index.html

https://gcc.gnu.org/onlinedocs/gcc-4.9.3/gcc/Link-Options.html

V pokračování bude použití nástroje STM32Cube pro vygenerování projektu a vytvoření něčeho lepšího než jen blikání LEDkou.

PS: Než mě bude někdo kamenovat proč se vlastně v tom examplu nepoužívá systémový časovač a je tam zpožďovací smyčka s čítačem, tak je to proto, že jsem použil původní example vygenerovaný s Eclipsu a nechtěl jsem ho moc modifikovat.

       

Obrázky

Komentáře

[skunkOS]

Wow, perfektní článek. Nejsem sám, kdo Qt Creatoru holduje. Třeba na prási s NASM je také docela dobrý, jednoduchý.

[Rezza]

Pridavam se, QtCreator jsem pouzil na ruzne zarizeni. Ale ze tam jde delat az tohle, to jsem netusil.

[kralyk z abclinuxu]

+1, skvělý článek

[randy]

Toto vyzera slubne. Qt sa mi vzdy pacilo, len nikdy som nepotreboval programovat okienkove aplikacie ;) Ale na stm32 procaky sa mi to moze hodit. Na programovanie stm32f1 pouzivam Arduino s stm32duino. Na stm32f4 je uz vhodnejsie System Workbench postaveny na Eclipse, ktore mi nikdy nesedelo. Toto by mohla byt cesta...

[mirec]

Je to celkom schodné. Ja som na tom fungoval skôr než mali explicitnú podporu pre bare metal.

[Roman Došek]

Já jsem dřív používal Tasking, protože jsme měli koupené floating licence. To je vlastně Eclipse s vlastním toolchainem pro ARMy. Kromě toho, že to vyšlo poměrně draze (tuším okolo 80k Kč/licenci) tak v té době bylo potřeba aktualizovat pro podporu nových desek, nebo si napsat vlastní linker sckripty. Ten software taky celkem často padal a navíc fungoval jen pod Windows. Pak jsme chvilku zkoušeli Coocox CoIDE, jenže z toho zase někdo naschvál vykostil správu projektů, takže jde aktuálně otevřít pouze jeden. To je možná fajn na hobby projekty, ale na komerční vývoj to není.

Za poslední cca 1.5 roku používám čistý Eclipse s pluginem GNU ARM Eclipse, a ze zkoušených řešení to bylo asi to nejlepší, nicméně docela mi na tom vadí ta konfigurace, indexer taky nemám zrovna v lásce, a občas to při debugování sletí. Styl přepínání aktivního projektu na základě naposledy otevřeného souboru taky není něco co by mi zrovna vyhovovalo (a třeba zrovna tohle už měl ten Tasking vyřešené lépe.)

Aktuálně v tom QtCreatoru zkouším svoje aktivní projekty (cca 150kLOC) a funguje to bez problémů (aby taky ne, stejný kompilátor i flagy..), debugování je rychlejší než v Eclipsu přestože používám JLink s OpenOCD namísto nástrojů od výrobce - myslím že podpora JLinkGDBServeru by ještě QtCreatoru neuškodila. Aktuálně je tam ještě chyba, která způsobuje poškození konfigurace gdb providera při použití parametrů openocd namísto konfiguráku (tak jak je ukázka v zápisku), ale je to nareportované a snad to v další verzi zmizí. Druhá nevýhoda je, že pro každou kombinaci procesoru a debug interfacu je nutné mít další kit, docela rychle to pak narůstá.

System Workbench jsem zkoušel, ale prakticky jeho jediná výhoda je, že zvládne naimportovat generované projekty z Cube, a to na Linuxu ještě špatně protože Cube generuje soubory které mají v názvu mezeru. Bavil jsem se o tom i s člověkem s STMicra a říkal, že jemu by se líbilo kdyby ten Cube generoval třeba makefily namísto projektů pro specifická IDE, ale že je problém o tom přesvědčit lidi, kteří to vyvíjejí.

Ten Qbs má právě natolik jednoduchou konfiguraci, že by se dal vygenerovat projekt na základě projektu pro jiné prostředí. Mám to na TODO listu, kdybych se někdy nudil.