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