Využítí ARM GCC vývojového retezce

| Kategorie: Diplomové, bakalářské práce  | Tento dokument chci!

Předmětem této práce je studium stávajícího vývojového řetězce pro mikroprocesor LPC23xx v předmětu MPOA. Hlavním cílem je zkoumání možností realizace nového vývojového řetězce, postaveného na GCC. Výstupy této práce jsou ukázkové aplikace s mikroprocesorem LPC2378 a GCC. Součástí vysledků jsou i návody pro studenty, jak tyto ukázkové aplikace implementovat. Ukázky zahrnují základní aplikace, RTOS aEthernet.

Vydal: FEKT VUT Brno Autor: Jan Ledvina

Strana 31 z 93

Vámi hledaný text obsahuje tato stránku dokumentu který není autorem určen k veřejnému šíření.

Jak získat tento dokument?






Poznámky redaktora
Pro správnou činnost pak třeba vždy zajistit, aby počet přivlastnění vrácení mutexu byl stejný. tomto konkrétním případě jedná LCD displej. Tato funkce však ovladači nebyla nalezena. Pokud chce úloha přistoupit sdílené periferii nejprve zkontroluje příslušný mutex. Mutexy binární semafor jsou podstatě stejné. Pro takovéto účely existují tzv. druhé kategorii jsou celkem možnosti použití jednobitových zpráv. Oficiální manuál [4] uvádí dvě možnosti využití tohoto nástroje: resource managment event counting. Mutexy jsou jednobitové informace, které umožnují řídit právě přístup ke sdíleným zdrojům. Přístup semaforu opět stylem „take“ „give“. dokončení komunikace touto periferii musí proces mutex uvolnit, čímž možnost ostatním procesům ke komunikaci. . Jde mutex, rekurzivní mutex, binární semafor čítací semafor. Navíc zde však dispozici vnitřní čítač semaforu, který čítá podle toho, jak semafor ovládán. Fronta podstatě libovolně nastavitelná velikost paměti, která sdílená více procesy. Důležitým rozhodnutím zde byla volba ovladače pro LCD. napsání aplikace však docházelo „zamrzání“ anebo k různým nestandardním stavům. Obě úlohy potřebují měnit údaj příslušném čase. V tuto chvíli existovaly dvě možnosti. Dle požadavku zadání byl vytvořen nový projekt, kterého byly přidány již existující potřebné moduly. Díky tomuto zpoždění trvalo zapsání každého znaku celkový zápis 2x16 znaků pak trval ms. prostudování zdrojového kódu tohoto ovladače byl zjištěn nejzákladnější rozdíl způsobu realizace zpoždění pro generování řídících signálu LCD. Jejím využitím můžou být třeba vstupní buffery procesů, které přebírají požadavky ostatních procesů. Proto bylo toto zpoždění odstraněno. Pokud mutex volný, úloha jej dočasně přivlastní tím sděluje ostatním procesům, periferii obsazenou. Bylo však podle katalogového listu HD44780 [17] ověřeno, že jediná funkce, která vyžaduje zpoždění při prací displejem, return home. tímto ovladačem již těmto chybám nedocházelo. Poslední možností tzv. Jelikož tento ovladač volá funkce RTOS, lze jej inicializovat až startu jádra RTOS. Postupně byly zredukovány možnosti, které mohly způsobovat toto chování. V FreeRTOS existují celkem dvě základní kategorie meziprocesové komunikace: Semafory/Mutexy (Semaphore/Mutex) Fronta (Queue). tohoto důvodu inicializace provedena samotném procesu. Tímto však dojde tomu, všechny proměnné, včetně proměnných ovladače LCD, jsou dostupné pouze procesu, který volal inicializaci LCD. Funkce realizující zápis instrukce LCD zde používala zpoždění ms. Po odstranění zpoždění již ovladač pracoval naprosto bez problému. Byl však zjištěn další nedostatek. tohoto důvodu v případě volání funkce pro zápis LCD jiného procesu dojde chybě vlivem nedostupnosti některých stavových proměnných LCD ovladače. Přesný důvod použití tohoto zpoždění nebyl zjištěn. Rekurzivní mutex je pak pouze variace mutexu, která umožnuje opakovaně „brát“ stejný mutex. Z tohoto důvodu ovladač nestačil zpracovávat data. Použít přeportovaný ovladač Petera Fleuryho anebo použít ovladač, který byl součástí demoaplikace FreeRTOS. Jediným rozdílem možnost prioritního systemu mutexů. čítací semafor. Po tomto zjištění byl projektu zakomponován druhý ovladačů.24 Důvodem, proč nutné této aplikaci použít meziprocesovou komunikaci, je sdílení jedné periferie oběma procesy. Nejprve byly provedeny pokusy s ovladačem FreeRTOS. Mutexy