Analyzátor vozidlových datových komunikací

ESKÉ VYSOKÉ UENÍ TECHNICKÉ

Analyzátor vozidlových datových komunikací Diplomová práce

erný Luboš

2007

eské vysoké uení technické v Praze Katedra mení 13138

Fakulta elektrotechnická Školní rok 2005/2006

ZADÁNÍ DIPLOMOVÉ PRÁCE

Student

Luboš erný

Obor

Mení a pístrojová technika

Název tématu: Analyzátor vozidlových datových komunikací s real-time výstupem

Zásady pro vypracování

Navrhnte a realizujte postup úprav zaízení CAN DataLogger tak, aby bylo schopno poskytovat alespo ástené výsledky analýzy komunikace v reálném ase. Souástí úprav bude pechod z operaního systému MS-DOS na operaní systém reálného asu PharLap a datový výstup analyzovaných informací prostednictvím rozhraní Ethernet s protokoly TCP/IP.

Seznam odborné literatury: [1]

Kocourek, P., Novák, J.: Penos informace. Skripta VUT, Praha 2003

[2]

Haasz, V., Roztoil, J., Novák, J.: íslicové mící systémy. Vydavatelství VUT, Praha 2000

[3]

Standard ISO11898-1998

[4]

Manuály systému PharLap

[5]

Technická dokumentace CAN DataLogger

Vedoucí diplomové práce:

Ing. Jií Novák, Ph.D.

Datum zadání diplomové práce:

28. listopad 2005

Termín odevzdání diplomové práce:

19. leden 2007

LS

Prof. Ing. Vladimír Haasz, CSc

Doc. RNDr. Tomáš Bílek, CSc

vedoucí katedry

prodkan

V Praze dne 28.11.2005

estné prohlášení Prohlašuji, že jsem zadanou diplomovou práci zpracoval sám s pispním vedoucího práce a konzultanta a používal jsem pouze literaturu v práci uvedenou.

Datum: 24. 5. 2007

………………..………………………. podpis diplomanta

Anotace: Práce popisuje úpravy zaízení CAN DataLogger umožující ástenou analýzu komunikace v reálném ase. Programové vybavení bylo peneseno pod operaní systém reálného asu PharLap s real-time výstupem mených dat na Ethernet s protokolem TCP/IP.

Summary: The dissertation describes a CAN DataLogger device enhancements that enable partial communication analysis in real-time. Software was adopted in the PharLap realtime operating system and it provides a real-time data output on Ethernet using a TCP/IP protocol.

Dkuji Ing. Jiímu Novákovi, Ph.D. za pomoc a as vnovaný vedení mé diplomové práce pi studiu. Dále pak Milanu Kašemu za pomoc s Phar Lapem a všem svým kolegm za trplivost, s jakou odpovídali na moje dotazy.

Obsah

1.

ÚVOD...................................................................................................................................................... 2 1.1 1.2

2.

MOTIVACE....................................................................................................................................... 3 UVEDENÍ DO PROBLEMATIKY .......................................................................................................... 4

RTOS PHARLAP.................................................................................................................................. 6 2.1 ETS JÁDRO REAL-TIME SYSTÉMU PHARLAP .................................................................................... 7 2.2 DEVELOPMENT STUDIO PRO EMBEDDED KÍŽOVÉ LAD NÍ ............................................................ 10 2.3 LINKLOC ....................................................................................................................................... 10 2.4 VISUAL SYSTEM BUILDER ............................................................................................................. 11 2.5 TYPICKÝ VÝVOJOVÝ CYKLUS ........................................................................................................ 11 2.5.1 Aplikace uložená v RAM .......................................................................................................... 12 2.5.2 Aplikace uložená v ROM.......................................................................................................... 12 2.6 PROGRAMOVACÍ PROSTEDÍ REAL-TIME ETS JÁDRA ..................................................................... 13 2.7 REŽIM CHRÁN NÉHO PROSTEDÍ ................................................................................................... 15 2.8 PAM OVÝ MODEL A GDT UKAZATELÉ ........................................................................................ 16 2.9 ETS KNIHOVNA A HOSTITELSKÉ SLUŽBY ....................................................................................... 17 2.10 APLIKANÍ ZÁSOBNÍK A HROMADA ............................................................................................... 17 2.11 POÁTENÍ APLIKANÍ STAV ......................................................................................................... 18 2.12 NULOVÝ UKAZATEL, NULOVÝ SKOK A OCHRANA ŠPATNÉHO SKOKU ............................................. 19 2.13 INICIALIZACE GLOBÁLNÍCH PROM NNÝCH .................................................................................... 21 2.14 PODPORA B HOVÝCH KNIHOVEN C ............................................................................................... 22 2.15 HOSTITELSKÝ SOUBOROVÝ SYSTÉM .............................................................................................. 23 2.16 KOMUNIKACE S VÝVOJOVÝM HOSTITELEM ................................................................................... 23 2.16.1 Hostitelské komunikace pes sériový port ........................................................................... 24 2.16.2 Hostitelská komunikace pes paralelní port........................................................................ 24 2.17 MAPOVÁNÍ PÍSTUPU ZAÍZENÍ DO PAM TI ................................................................................... 25 2.18 PÍKAZOVÁ ÁDKA HOSTITELE A SYSTÉMOVÉ PROSTEDÍ ............................................................ 25 2.19 ZVOLENÍ REAL-TIME ETS PODSYSTÉMU JÁDRA ............................................................................. 26 2.20 PERUŠENÍ A VÝJIMKY .................................................................................................................. 27 2.20.1 Zpracování perušení real-time ETS jádrem....................................................................... 28 2.20.2 Instalování obsluhy perušení v aplikaci............................................................................. 30 2.21 OVLADAE ZAÍZENÍ VLOŽENÉ S REAL-TIME ETS JÁDREM ........................................................... 32 2.22 VNITNÍ ARCHITEKTURA REAL-TIME ETS JÁDRA A INICIALIZACE ................................................. 33 2.23 PEHLED SLEDU ZAVÁD NÍ REAL-TIME ETS JÁDRA ...................................................................... 34 2.23.1 První krok: Inicializace ETS Monitoru ............................................................................... 35 2.23.2 Druhý krok: Inicializace real-time ETS knihoven jádra ..................................................... 35 2.23.3 Tetí krok: Penesení kontroly do embedded aplikace........................................................ 35

3.

POPIS SYSTÉMU A ZÁSUVNÝCH KARET................................................................................... 36 3.1 STRUNÝ POPIS STÁVAJÍCÍHO SYSTÉMU ........................................................................................ 37 3.2 POUŽITÉ KARTY V M ICÍM SYSTÉMU ........................................................................................... 42 3.2.1 Analogov digitální karta ........................................................................................................ 42 3.2.2 Zásuvná karta s adii CAN..................................................................................................... 44 3.2.3 Ethernet karta .......................................................................................................................... 45

4.

EŠENÍ ÚKOLU ................................................................................................................................. 47 4.1 4.2

POPIS PROGRAMU PED A PO HLAVNÍ SMYCE .............................................................................. 48 POPIS B HU PROGRAMU V HLAVNÍ SMYCE................................................................................... 52

4.3 POPIS A SPRÁVA PAM TI BUFFER ................................................................................................. 60 4.3.1 DMA buffer .............................................................................................................................. 61 4.3.2 Logovací a monitorovací buffer............................................................................................... 61 4.3.3 Zápis dat na flash disk ............................................................................................................. 62 4.4 POPIS FUNKCE OBSLUHY PERUŠENÍ V PROGRAMU ........................................................................ 63 4.4.1 Zápis záznam do pamti......................................................................................................... 63 4.4.2 Vyhodnocování píznak perušení ......................................................................................... 65 4.4.3 Funkce volané v perušení ....................................................................................................... 66 4.5 OV ENÍ FUNKCE .......................................................................................................................... 69 5.

ZÁVRENÉ ZHODNOCENÍ .......................................................................................................... 70

6.

POUŽITÁ LITERATURA A PÍLOHY........................................................................................... 73 6.1

SEZNAM LITERATURY A POUŽITÝCH ODKAZ ................................................................................ 74

Analyzátor vozidlových datových komunikací s real-time výstupem

Kapitola

1 1. Úvod

- 2 -


1.1 Motivace Za dobu své existence prošlo lidstvo již mnoha vývojovými etapami. Stalo se zvykem je oznaovat podle pevažujícího materiálu, jehož zpracování mlo pro danou dobu zásadní význam. Také úrove zpracování se s postupujícími etapami zvyšovala. Od doby kamenné, kdy lovk nevdl mnoho o struktue hmoty, pes dobu železnou, ve které již znal mnohé zpsoby zpracování, až po dnešní dobu, kterou bych si dovolil nazvat dobou kemennou. A to z dvod použití kemíku snad ve všech oborech lidské innosti. I když zajisté není zanedbatelné jeho použití v kterékoli oblasti, troufám si íci, že zásadní význam pro rozvoj souasné civilizace má jeho použití v elektronice. Souasné znalosti jeho struktury a technologické možnosti jeho zpracování zpsobily, že se dnes setkáváme s elektronikou na každém kroku. Podíváme-li se na historický vývoj z jiného hlediska, je též možné naší dobu nazvat dobou informací. K úspchu jak jednotlivce tak celé populace je zapotebí mít správnou informaci ve správný as a na správném míst. Existuje pedpoklad, že nárst významu informací má na svdomí práv elektronika. Protože díky elektronice je lovk schopen zaznamenat, zpracovat, setídit, vybrat a využít ty správné informace podstatn efektivnji, než bez elektroniky. Zvláš s rozvojem íslicového zpracování je možné „bezchybn“ zpracovat rychleji vtší množství informací. Dnes se klade velký draz práv na rychlost penosu informace a s tím je spojené stále nové objevování a vývoj komunikaních sbrnic. S rostoucí rychlostí penosu se zvyšuje i penosová frekvence v penosových kabelech. Roste taky pracovní frekvence budi sbrnice a mikroprocesor, které tyto informace zpracovávají. Do prostedí, ve kterém tyto rychlé obvody pracují, se dostává vysokofrekvenní rušení. Toto rušení zpsobené vlastním zaízením i zaízeními pracujícími v okolí se ruší penos informace a proto se vyvíjí sbrnice, které jsou stále odolnjší. Pi vývoji a testování tchto sbrnic je zapotebí zaízení, které se pipojí na sbrnici, analyzuje její stavy a pomáhá identifikovat penášená data nebo chyby na sbrnici.

- 3 -


1.2 Uvedení do problematiky Cílem mé práce je vytvoení programu do stávajícího zaízení CAN Datalogger. CAN Datalogger slouží k monitorování tí automobilových sbrnic CAN. První sbrnice CAN je omezena na rychlost 500 kbit/s, druhá a tetí na 100 kbit/s. Dále je DataLogger vybaven vstupy pro monitorování teploty, analogovými a digitálními vstupy. Program umožuje spustit monitorovaní na danou zprávu na sbrnici CAN, pi výskytu chyby na sbrnici, pi pekroení „vytížení“ sbrnice, pi nastavení hodnoty na analogov digitálním vstupu nebo nastavením hodnoty na digitálním vstupu. Toto monitorování lze nastavit i tak, že se zaznamenají i události, které nastaly ped (pre-trigger) a i po píchodu (posttrigger) monitorovacího impulsu spuštní. Doby záznamu ped a po spuštní si nastavuje uživatel. Funkce zaízení CAN Datalogger se nastavují programem DataLogger v prostedí Microsoft Windows (obr. 1.1), který byl také vyvinut na Katede mení. Program DataLogger podle nastavení vygeneruje nastavovací soubor „Setup.cfg“. Tento soubor se uloží na PCMCIA flash kartu, která se pipojí do mícího systému CAN Datalogger. Stávající program je napsaný v jazyce C a bží pod operaním systémem DOS. Program, který budu pro CAN Datalogger vytváet, je v real-time prostedí PharLap. Operaní prostedí PharLap je od spolenosti Ardence. Ke stávající konfiguraci CAN Dataloggeru pibude ješt ethernetová sí ová karta, která bude vysílat zvolené namené hodnoty v reálném ase. Transportním protokolem, kterým se bude na výstup sí ové karty vysílat, je UDP. Výsledný program musí mít ve výsledku stejné možnosti funkce ovládání a monitorování jako pedchozí program.

- 4 -


Obr. 1.1 Datalogger

Obr. 1.2 Vzhled micího zaízení CAN DataLogger

- 5 -


Kapitola

2 2. RTOS PharLap

- 6 -


Obr. 2.1 Logo PharLap

2.1 ETS jádro real-time systému PharLap Jádro ETS (Embedded ToolSuite) systému poskytuje pro bh „embedded“ (v celé diplomové práci budu používat toto anglické slovo z dvodu jeho astého používání v eském jazyce) program pln real-timové vlastnosti operaního systému. Hlavní funkce jádra mají za úkol zinicializovat 32 bitový chránný režim a poskytnout provozní knihovny Win32 API jako základ pro peklada Visual C++. ETS jádro obsahuje širokou paletu služeb operaního systému. Paleta služeb dlá vývoj programu pro real-time embedded systém stejn snadný, jako je napíklad vývoj program pro MS-DOS a Windows. ETS jádro zahrnuje také nepovinného hostitele modulu komunikace, který dovoluje embedded

cílovému

(95/98/NT/2000/XP).

systému

komunikovat

s vývojovým

PC

s OS

Windows

Pro vývoj embedded programu mžeme tedy snadno používat

kompilátor Windows a jeho vývojové nástroje

- 7 -


Zkompilovaný program se nahrává do cílového embedded systému z vývojového hostitelského systému a synchronizuje se s bžícím Microsoft Visual C++ na vývojovém hostitelském systému. Real-time jádro je fyzicky rozdlené do dvou oddlených ástí: 16 bitový ETS Monitor a 32 bitové ETS knihovny, které jsou spojené s vyvíjeným programem. ETS knihovny poskytují Win32 API, které obsahuje volitelné souásti real-time ETS jádra a podporuje knihovny C/C++. ETS Monitor obsluhuje systémovou hardwarovou inicializaci, pepíná procesor do chránného režimu a komunikuje s ladicím programem. ETS monitor mže být zaveden: x

z disku na cílovém kompatibilním PC/AT systému

x

z dávkovacího souboru spolu s žádostí o naprogramování ROM

x

z emulátoru ROM

Real-time ETS jádro zavede embedded systém a vytvoí chránný režim pro vyvíjený program. Ped spuštním vyvíjeného programu se provedou následující operace: x

Vestavný procesor je pepnut do chránném režimu

x

Selektory jsou pipraveny pro kód a ásti dat

x

Registry jsou zinicializovány

x

Globální promnné jsou samoinn inicializovány z dat v ROM

x

ETS knihovny jsou inicializovány a poskytují Win32 implementaci

x

Knihovna jazyka C je inicializována

Real-time ETS jádro vykonává celou inicializaní úrove jako souást procesu zavádní a bží zde pouze funkce inicializované embedded programem. Programové prostedí pro vyvíjení embedded program je podobné prostedím pro jiné 32 bitové systémy provozované v chránném režimu. Real-time ETS jádro mže být spuštno v jednom ze dvou režim: x

WaitHost

x

NoWaitHost

- 8 -


Ve WaitHost režimu je jádro zavedeno z cílovém systému, samo se inicializuje a následn eká na instrukce pro spuštní embedded vyvíjeného programu od vývojového poítae. V NoWaitHost režimu je jádro zavedeno z cílového systému, samo se inicializuje a zane vykonávat embedded program z pamti ROM nebo z pevného disku. Obecn je WaitHost režim používán jen bhem programovacího vývoje pro ladní a NoWaitHost režim pro konené výrobní procesy. Po spuštní embedded programu poskytují knihovny jádra (které jsou spojené s embedded programem) funkce Win32 API, které jsou nezbytné pro podporu embedded programu. Real-time ETS jádro obsahuje nkteré vnitn používané funkce, které se vtšinou implementují do spolených funkcí v knihovnách C nap. memcpy() nebo strcmp(). Jestliže kompilátor nepodporuje námi požadovanou funkci, mžeme použít tyto alternativní funkce z knihovny C. Krom klasických Win32 API funkcí poskytuje real-time ETS jádro také další pidané funkce pro systémovou konfiguraci a ízení perušení. Pidané funkce do jádra pro systémovou konfiguraci a ízení perušení: x

Obsloužení uspoádané výjimky knihovnou

x

Ovladae asovae, klávesnice a video adaptéru

x

Komunikaní software s hostitelem

x

Aplikaní zavad (nate embedded aplikaci ze stejného zavádjícího disku jako jádro)

x

Zavedení PCI BIOS knihovny

x

Knihovnu vláken (thread)

x

Emulátor výpot v pohyblivé ádové árce

x

MS-DOS kompatibilní souborový systém

x

TCP/IP sí ové funkce

x

Balíek pro podporu PC CARD

x

MicroWeb sever

x

Zavad DLL

- 9 -


Standardní hardwarová konfigurace pro embedded systémy je dána architekturou PC/AT. Architektura PC/AT je zvolena pro širokou dostupnost systém. Navíc je s ní seznámena vtšina programátor 32 bitových x86 kompatibilních poíta. Tato architektura však pro malou ást vyvíjených embedded aplikací není vhodná.

2.2 Development Studio pro embedded kížové ladní Pokud bží cílový systém ve WaitHost režimu, má real-time ETS jádro silné ladící prostedí, které nám usnadní ladní embedded programu. Stejné zdrojov ladící prostedí pitom používají i programy pro ne-embedded systémy. Embedded doplnk StudioExpress mžeme používat v Development Studiu pi kížovém ladní program.

2.3 LinkLoc Linkování programu, které pobží pod embedded operaním systémem typu real-time ETS má jiné požadavky, než linkování programu bžícího pod víceúelovým operaním systémem typu DOS nebo Windows. LinkLock je 32 bitový linker navrhující stavby program bžících pod real-time ETS jádrem. LinkLoc má tradiní linkerovou funknost: rozlišuje adresy, hledá knihovny a staví debugovací tabulku symbol. LinkLoc navíc vykonává následující innosti potebné pro embedded systémy: x

Specifikuje rzné adresy pro rzné ásti aplikace – nap. kódový segment mže zaínat na adrese C100h a datový segment na adrese 3300h

x

Pedává binární nebo hexadecimální soubory pro programování flash pamti nebo ROM

x

Pedává OMF bootovací soubory pro ladní v emulátoru obvodu (ICE)

x

Generuje ROMINIT segment pro inicializaci promnných v ROM programech

- 10 -


ETS zahrnuje íslo z píkazového souboru linkeru skládající se z LinkLoc píkaz pro specifické volby sdružené s vloženým ETS podsystémem. Obecn eeno, specifikujeme píkazový soubor linkeru, který identifikuje náš cílový hardware a ETS bootovací metodu. Dále pak pídavnou píkazovou ádku pro každou ETS souást jež má být propojena s naším programem.

2.4 Visual System Builder Doplkové komponenty real-time ETS jádra jsou snadno volitelné pomocí Visual System Builderu. Visual System Builder usnaduje konfiguraci real-time ETS jádra, ízení a pizpsobování parametr pro embedded cílový systém. Pomocí Visual System Builderu mžeme nahradit specifický jádrový modul vlastním vytvoeným kódem. Výstup z Visual System Builderu se skládá ze dvou linkerových píkazových soubor. Jeden se používá pi linkování aplikace a druhý pi linkování ETS Monitoru. Tyto linkerové píkazové soubory jsou pedány do dávkových soubor používaných ke zkompilování a spojení našeho programu. Jestliže Visual Systém Builder nepreferujeme, mžeme vytvoit a editovat svj vlastní linkerový píkazový soubor.

2.5 Typický vývojový cyklus Jedna z prvních otázek, která nás pi vývoji embedded systému napadne je, zda bude aplikace umístna v pamti ROM nebo RAM. V pípad pamti RAM použijeme ve vývojovém prostedí Embedded ToolSuite. V opaném pípad bude rozdíl v zavedení ETS aplikace na embedded cílový systém. Budeme ale moci používat stejné postupy pro stavbu a ladní programu.

- 11 -


2.5.1 Aplikace uložená v RAM Vtšina embedded cílových systém, jejichž aplikace bží uložená v RAM, jsou na PC/AT kompatibilních poítaích nebo na PC/104 systémech. Výrobní verze daného zaízení nahrává aplikaci z njakého druhu disku: floppy, IDE, PC Card, Flash,…

Typický vývojový cyklus aplikace uložené v RAM mže obsahovat tyto kroky: 1. Zavedení ETS monitoru ve WaitHost režimu z disku a stáhnutí embedded programu z hostitelského systému. V tomto stádiu je cílový systém propojen kabelem s hostitelským poítaem, na kterém je program vyvíjen. Bhem této fáze vývoje mžeme provádt asté zmny v programu, krokovat program a sledovat tak jeho problémové oblasti. 2. Zavedení ETS monitoru ve WaitHost režimu z disku a spuštní uloženého programu z disku. Cílový embedded systém je spojený s hostitelským poítaem pomocí kabelu. Bhem této fáze vývoje mžeme provádt mnoho test a používat ladící program jen pokud nastane njaký problém. Tento scéná by mohl být vhodný k testování jednotlivých stádií ped finálním programem. Jestliže je program obzvlášt velký, mžeme využít možnosti nahrání programu z disku, které je rychlejší než nahrávání z hostitelského poítae. 3. Zavedení ETS monitoru v NoWaitHost režimu a spuštní programu z disku. Tento scéná popisuje výrobní verzi produktu. Embedded systém obsahuje vše potebné ke spuštní programu.

2.5.2 Aplikace uložená v ROM V závislosti na hardwaru cílového systému mžeme zahájit vývoj na PC/AT kompatibilním systému. Jestliže se rozhodneme pro tuto variantu, mli bychom následovat body 1 a 2 v kapitole Aplikace uložené v RAM (2.5.1). Vtšinou ale chceme zaít ladní programu co nejdíve a to na hardwaru, který bude co nejvíce podobný embedded systému.

- 12 -


Typický vývojový cyklus aplikace uložené v ROM mže obsahovat tyto kroky: 1. Zavedení ETS monitoru ve WaitHost režimu z ROM a stáhnutí embedded programu z hostitelského systému. V tomto stádiu je cílový systém propojen kabelem s hostitelským poítaem, na kterém je program vyvíjen. Bhem této fáze vývoje mžeme provádt asté zmny v programu a obvykle krokovat program a sledovat tak jeho problémové oblasti. 2. Zavedení ETS monitoru ve WaitHost režimu z ROM a spuštní uloženého programu z ROM. Cílový embedded systém je spojen s hostitelským poítaem pomocí kabelu. Bhem této fáze vývoje mžeme provádt mnoho test a používat ladící program jen pokud nastane njaký problém. Tento scéná by mohl být vhodný k testování jednotlivých stádií ped finálním programem. Jestliže je program obzvlášt velký, mžeme využít možnosti nahrání programu z disku, které je rychlejší než nahrávání z hostitelského poítae. 3. Zavedení ETS monitoru v NoWaitHost režimu z ROM a spuštní uloženého programu z ROM. Tento scéná popisuje výrobní verzi produktu. Embedded systém obsahuje vše potebné ke spuštní programu.

2.6 Programovací prostedí real-time ETS jádra Používání Microsoft Visual C++ kompilátoru spolu s real-time ETS jádrem pináší usnadnní programování embedded systém v jazyku C. Vývoj embedded program mže být pomrn rychlý a jen málo odlišný od vývoje program pro operaní systémy typu MS-DOS, Windows nebo UNIX. Real-time ETS jádro, jako univerzální operaní systém, poskytuje následující rysy a schopnosti prostednictvím Win32 API: x

Pidlování pamti

x

Konsolové I/O

x

Vzdálené I/O

x

Lokální I/O

- 13 -


x

asovací systémové služby

x

Uspoádanou obsluhu výjimek

x

Rzná další API prostedí

x

Více-vláknové operace a jejich synchronizování

x

TCP/IP sí (winsock 1.1 kompatibilní API)

x

Naítání a používání DLL knihoven

x

Sériové rozhraní

Obr. 2.2 Architektura Phar Lapu Real-time ETS jádro má tyto další vlastnosti specifické pro embedded poítaové aplikace: x

Real-time ETS jádro je škálovatelné. Jestliže aplikace nepotebuje nkteré vlastnosti operaního systému nebo podsystému, mžeme je vylouit a tím redukovat pam potebnou pro real-time ETS jádro.

x

Real-time ETS jádro garantuje aplikaci schopnost reagovat na skutené události v reálném ase.

- 14 -


x

Real-time ETS jádro poskytuje dalším API pevzetí vektor perušení, zaznamenávat události, konfigurovat systém a získat informace o stavu ladné aplikace.

x

Real-time ETS jádro psobí jen ve fyzické pamti. Pro zaruení real-time odezvy se jádru virtuální pam neposkytuje. Embedded aplikace si musí být tohoto faktu vdoma. Ve speciálních pípadech se nemže embedded aplikaci pidlit neomezená pam a musí tedy používat pevn daný zásobník (Stack).

x

Real-time ETS jádro mže být pizpsobeno i pro nestandardní hardware. Všechny hardwarov závislé moduly jsou v real-time ETS jádru posílány ve zdrojové form kódu a musí se tedy nutn nahradit nebo pizpsobit.

2.7 Režim chránného prostedí Bez ohledu na vybrané konfiguraní volby real-time ETS jádro vždy nastaví režim chránného prostedí pro embedded aplikaci. Ve chvíli kdy program získává kontrolu pi vstupu do funkce main(), jádro už vykonalo nízkoúrovové nastavení podrobností v tomto prostedí: x

Embedded procesor je pepnut do chránného režimu.

x

Ukazatelé na segmenty kód a dat jsou nastaveny rovnou na startovací adresy s poátení adresou 0 a mžou se rozšíit až do 4 GB.

x

Registry a píznaky jsou nastaveny.

x

Perušení jsou povolena.

x

Globální promnné byly inicializovány.

x

Jestliže je s programem spojená knihovna C, inicializuje se také.

Kdyby mohlo real-time jádro automaticky vykonávat tuto inicializaci, velmi by se zjednodušil vývoj program pro embedded systémy. Program by napíklad nemusel vícekrát specifikovat a ídit systémové zdroje typu tabulky deskriptor.

- 15 -


2.8 Pam ový model a GDT ukazatelé Real-time ETS jádro definuje jedenáct ukazatel:

#define CODE16_SELECTOR 0x08

// jádro 16 bitový kódový segment

#define DATA16_SELECTOR 0x10

// jádro 16 bitový datový segment

#define CODE32_SELECTOR 0x18

// 32 bit. pímý kódový segment pro aplikaci

#define DATA32_SELECTOR 0x20

// 32 bit. pímý datový segment pro aplikaci

#define TEB_SELECTOR 0x28

// 32 bit. datový segment mapování vláken

Blok prostedí pro Win32 kód:

#define KER32_CODE 0x30

// 32 bitový alias pro kódový ukazatel

#define KER32_DATA 0x38

// 32 bitový alias pro datový ukazatel

#define MONOSCR_SELECTOR 0x40

// 16 bitový datový segment pro mapování jednobarevné pamti

#define COLORSCR_SELECTOR 0x48

// 16 bitový datový segment pro mapování barevné pamti

#define KER32_CODE2 0x50

// druhý 32 bit. alias pro kódový ukazatel.

#define DATA4G_SELECTOR 0x58

// 0 – 4 Gb datový segment

#define GDT_FIRST_FREE 0x60

Režim chránného prostedí se skládá z 32 bitového pam ového modelu bez možnosti stránkování. Každý ukazatel je 32 bitový, mžeme tedy adresovat až 4 GB. Všechny adresy jsou adresami fyzickými a embedded programu mžou snadno zpístupnit fyzickou pam v embedded systému. ETS monitor dovolí specifikovat minimální platnou adresu pro data a maximální platnou adresu pro kód. Real-time ETS jádro používá globální tabulku deskriptor (GDT) s 50 záznamy. Z toho je jich 11 používaných pro peddefinované ukazatele. Zbylých 39 ukazatel je dostupných pro potebné aplikace. Jádro nevytváí místní tabulku deskriptor (LDT).

- 16 -


2.9 ETS knihovna a hostitelské služby ETS monitor používá INT (Interrupt) FFh k zajištní hostitelské služby a INT FEh k poskytnutí služeb pro ETS knihovny. Výjimky procesoru se používají pro ladní. Hardwarové perušení IRQ 0 je použito pro asovací služby. Všechna další perušení odkazují na IRETD instrukce. Aplikace má schopnost zachytit všechna perušení a výjimky a to vetn tch používaných real-time ETS jádrem. Když odvolá ETS monitor poskytování hostitelských služeb nebo služeb knihovnám, systém bží s vyazenými perušeními, protože se jedná o 16 bitový kód a architektura real-time ETS jádra nedovoluje povolení perušení na 16 bitovém zásobníku. To znamená, že hardwarová perušení jsou pozdržena, pokud se objeví pi ladní programu nebo ve chvíli kdy aplikace eká na hostitelské služby (napíklad: hostitelské I/O, printf() na obrazovce hostitele nebo na oznámení hostitelského programu na ladní události). Ve výrobním systému nepipojeném k vývojovému zaízení se tedy 16 bitový kód v ETS monitoru nebude vykonávat bhem normálních operací aplikace. Hardwarová perušení tedy ve výrobním systému nebudou pozdržena.

2.10 Aplikaní zásobník a hromada Visual System Builder a ETS linkerové píkazové soubory specifikují poátení hodnoty pro velikost a umístní zásobníku. Tyto poátení hodnoty mžeme pepsat pomocí Visual System Builderu nebo pímo zavoláním LinkLoc (kapitola 2.3). Pepínaem STACK v LinkLoc specifikujeme velikost zásobníku. Výchozí pozice zásobníku je umístna s daty v programu. Mnit výchozí hodnotu na specificky umístném zásobníku lze s pomocí pepínae LOCATE. Napíklad: -locate segment _stack 20000h Celá operaní pam RAM se nepoužívá pro jádro, aplikaci nebo zásobník, ale je automaticky použitá pro hromadu.

- 17 -


2.11 Poátení aplikaní stav Real-time ETS jádro penáší kontrolu do aplikace se systémem v následujících stavech: x

Procesor v chránném režimu vykonává nulové privilegované úrovn.

x

Stránkování není povoleno.

Registry a píznaky jsou dány následující tab. 2.1. Registry segment mohou být mnny jen pi splnní pokyn v tab. 2.2. CS

0x18

(4 GB kódový segment)

EIP

Adresa specifikovaná v LinkLoc pepínaem START

ESP

Vrchol segmentu zásobníku v programu

EFLAGS

0x0202

(povolení perušení)

SS

0x20

(4 GB datový segment)

DS

0x20

ES

0x20

FS

0x20

GS

0x20

Další jiné registry

0

(blok Win32 vláken)

Tab. 2.1 Registry a píznaky

- 18 -


Registr

Podmínky

CS, SS, FS

Po dobu zmn v registru musí být perušení vypnuto

DS, ES

Po dobu zmn v registru nesmí program provádt nic s knihovnou C a Win32 funkcemi

GS

Program mže libovoln mnit hodnotu v GS registru. Zavoláním nkteré knihovny C, Win32 nebo ETS systémové funkce mže tuto hodnotu v registru GS zmnit. Tab. 2.2 Zmny hodnot v registrech

2.12 Nulový ukazatel, nulový skok a ochrana špatného skoku ETS Monitor mže oznait njaké adresové rozsahy v 4 GB kódovém a datovém segmentu jako neplatné. Tímto oznaením zabráníme pokusu o pímé adresování této pamti neplatným ukazatelem. Pi pokusu odkazování v programu na njakou ást z tchto rozsah adres dostáváme špatnou pam ovou ást. x

Ochranou nulového ukazatele vymezíme rozsah ásti pamti, která je neplatná pro datový pístup. Rozsah koní v nejvyšší ásti pamti. Limit nulového ukazatele udává spodní hranici tohoto rozsahu.

x

Ochranou nulového skoku vymezíme rozsah ásti pamti, která je neplatná pro cílový skok instrukce. Rozsah zaíná v nejnižší ásti pamti. Limit nulového skoku vymezuje horní hranice tohoto rozsahu.

x

Ochranou špatného skoku uríme rozsah ásti pamti, která je neplatná pro kódový pístup. Rozsah zaíná od Ochrany nulového skoku. Limit špatného skoku udává vyšší hranice tohoto rozsahu.

Popisované ochrany jsou ukázané na obr. 2.3.

- 19 -


Výchozí nastavení ochrany nulového ukazatele je odesíláno v ETS Monitoru. První 4 kB pamti v systému (adresový rozsah od 0 do 0FFFh) jsou chránny z odkaz na 32 bitovou datovou ást pamti. Vypnout ochranu nulového ukazatele nebo zmnit ochranné pásmo mžeme použitím pepínaem NULLPROTLIM. Ochranu nulového ukazatele lze zmnit i v nabídce nastavení Monitoru ve Visual System Builderu. Pi zvtšení velikosti ochranného pásma musíme vdt, zda se v ochranném pásmu neobjeví žádná systémová data (pro aplikaci nebo ETS Monitor). Vtšina standardních ETS Monitor zane ukládat data od místa 1000h, a tak nejvtší možná ochrana nulového rozsahu je 0 až 0FFFh. 4 GB

Platný kódový pístup je pro rozsah adresovaný od limitu nulového skoku (LNS) do limitu špatného skoku (LŠS)

Platný datový pístup je pro rozsah adresovaný od limitu nulového ukazatele (LNU) do 4 GB

LŠS

LNU LNS 0B Obr. 2.3 Hlídaný rozsah adres Ochrana špatného skoku a ochrana nulového ukazatele poskytují zpsob, jak pedejít zpístupnní neplatné pam ové oblasti programu. Ochrana špatného skoku je použita pro ochranu vysoké (high) pam ové oblasti a ochrana nulového ukazatele je použitá zase k ochran nízké (low) pam ové oblasti. Ochrana špatného skoku je standardn vypnuta. Zapnutím ochrany se nastaví limit na specifickou hodnotu v kódovém segmentu a všechny odkazy mimo vymezený segment

- 20 -


(ochranné pásmo) skoní s chybou. Limit ochrany špatného skoku musí být dostaten velký pro vložení celého aplikaního kódu z pamti RAM nebo ROM. Zapnutí ochrany špatného skoku se provádí bu pomocí pepínae BADJAMPLIM nebo v nabídce nastavení ETS Monitoru ve Visual System Builderu. Pro systém nahrávající aplikaci do pamti RAM smí být kódový limit segmentu nastaven na konec pamti u cílového systému. Napíklad: Limit kódového segmentu je nastaven u cílového systému obsahujícího 1,25 MB rozšíené pamti na 23FFFFh.

Ochrana nulového ukazatele je standardn zapnuta. Zapnutá ochrana umožní real-time ETS jádru detekovat skok nebo volání do nízké pam ové oblasti. ETS Monitor zapisuje do pamti od adresy 0 až do limitu nulového ukazatele s perušující instrukcí INT 3. Pokusí-li se program vykonat instrukci v této oblasti, bude hned na této pozici zastaven. Toto pozastavení dovoluje snadnjší zptné krokování k urení nesprávného volání nebo skoku. Pro vypnutí ochrany nulového ukazatele nebo zmnu chránného pásma musíme použít pepína NULLJUMPPROT. Standardní limit ochrany nulového ukazatele je 0x3Fh. Rozsah adres pamti ovlivnné ochranou špatného skoku a ochranou nulového ukazatele mní pouze aplikaní kód, ne ETS Monitor. Jestliže aplikace bží z pamti ROM, mžeme naíst ETS Monitoru z vyšší adresy z ROM a aplikace bude nahrána v nižší adresové oblasti. Tím mžeme jednoduše urit horní hranici pro kódový limit.

2.13 Inicializace globálních promnných Inicializovaná globální data jsou automaticky zabalena v kódovém segmentu. Než se program spustí, jsou už globální data rozbalena v pamti RAM. Balení dat je v kódovém segmentu ízeno specifickými pepínai v píkazových souborech ve standardním linkeru. Rozbalení a spuštní je ovládáno inicializaním kódem v aplikaci a ETS knihovnách.

- 21 -


2.14 Podpora bhových knihoven C Vtšina z bhových knihoven Visual C++ je podporována real-time ETS jádrem. ETS jádro tyto knihovny podporuje poskytováním požadovaných Win32 API funkcí pro systémové služby. Z hlavních run-time funkcí C nejsou podporovány jen ty, které nynjší embedded systémy pravdpodobn nebudou vyžadovat. Napíklad: _exec() není podporována, protože vyžaduje operaní systémy s podporou pro více paraleln bžících proces. Chování programových bhových knihoven C je s real-time ETS jádrem podobné jako s operaními systémy MS DOS a Windows. Hlavní rozdíly v chování jsou: x

Standardní hromada dostává celou dostupnou pam RAM. Funkce EtsCustomGetMemPool()

mže

modifikovat

velikost,

umístní

a dynamicky ji v asovém prbhu programu pizpsobovat. x

Systémové prostedí a píkazový ádek jsou pevn propojeny v ase. Když vyvíjený program bží ve WaitHost režimu, jsou funkce a promnné z knihovny C (getenv(), putenv(), argc(), argv(),…) zpístupnné i pro systémové prostedí a píkazovou ádku z vyvíjecího systému. Funkce obstarávající

tuto

komunikaci

s vývojovým

systémem

jsou:

EtsCustomGetCommandLine() a EtsCustomGetEnvStrings(). x

Pi spuštní WaitHost režimu je podporován souborový I/O vývojovým systémem komunikujícím pes ladící kabel. Tato vlastnost je popsána v kapitole Hostitelský souborový systém (2.15).

x

Pi spuštní WaitHost režimu je podporován obrazový výstup a vstup klávesnice z vývojového systému komunikujícího pes ladící kabel. Máme-li embedded systém vybaven obrazovkou (monitorem) a klávesnicí (s pilinkovanými

funkními

ovladai),

mžeme

pomocí

funkce

EtsSelectConsole() pepnout vysílání obrazu a vstupu z klávesnice z embedded systému do vývojového hostitelského systému. x

Služby asovae na embedded cílovém systému jsou podporovány pes ovlada asovae.

- 22 -


Real-time ETS jádro obsahuje nkteré vnitn používané funkce implementované a modifikované z bhové knihovny C. ETS jádro se chrání ped njakou vnitní závislostí na bhové

knihovn C. Pi vyvíjení programu se snažíme využívat z ETS jádra

alternativní funkce a vyhýbat se nahrání verze z knihovny C.

2.15 Hostitelský souborový systém Real-time ETS jádro podporuje souborové operace na vyvíjeném hostitelském systému. Pro souborové operace jsou použité obvyklé funkce z knihovny C. Napíklad: fprintf() je použita pro formátovaný výstup do souboru a fread() je použita pro neformátovaný vstup ze souboru. Hostitelský souborový systém je dostupný ve WaitHost režimu a je automaticky vložen, když linkujeme program. Hostitelský souborový systém využíváme bhem vývoje, kdy asto zacházíme se soubory na vývojovém hostitelském systému. Mžeme také používat soubor od vyvíjecího systému k simulaci pijatých dat ze vstupních zaízení. Jestliže embedded vývojový systém nebude mít pi vývoji programu souborový systém, mžeme použít hostitelský souborový systém pro poátení vývoj aplikace a pejít ve vhodnou dobu na lokální souborový systém.

2.16 Komunikace s vývojovým hostitelem Spuštný WaitHost režim nabízí v ETS Monitoru rzné možnosti komunikací (sériové nebo paralelní) s vývojovým systémem. Tyto možnosti komunikace s Developer Studio Debuggerem umožní vyladní programu a poskytnutí pístupu ke klávesnici, obrazovce a souborovému systému na vyvíjeném systému.

- 23 -


2.16.1 Hostitelská komunikace pes sériový port Standardn je použit pro komunikaci sériový port COM1 a to jak hostiteli vývoje, tak na embedded cílovém systému. COM1 a COM2 jsou jediné vývojov podporované sériové porty. Nap.: Použití hostitelského vývojového sériového portu COM2: x

Pro Developer Studio: Vybrat COM2 port ze seznamu port v nabídce v dialogu StudioExpres Target Configuration

x

Pro RUNEMB: Specifikovat COM2 na píkazové ádce.

Specifikovat sériový port mžeme i použitím Visual System Builderu v Target Serial Line Port v sekci vlastnostech listu Host Comms. Pokud nemžeme použít Visual System Builder, mžeme spustit CFIGKERN utilitu a na ETS Monitoru zmnit nastavení sériového portu.

2.16.2 Hostitelská komunikace pes paralelní port Pi použití paralelní komunikace musíme specifikovat íslo paralelního portu na vyvíjejícím i vývojovém systému. íslo je index BIOSu na tabulku port oznaující I/O adresu portu konfigurovaného systému. x

Pro Developer Studio: Vybrat LPT1 až 3 seznamu port v nabídce v dialogu StudioExpres Target Configuration

x

Pro RUNEMB: Použít LPTn pepína píkazové ádky. Platné hodnoty pro n jsou 1až 3.

Pi použití paralelní komunikace musíme nakonfigurovat real-time ETS jádro. Všechny monitory odesílané s Embedded ToolSuite (ETS) používají standardn sériovou komunikaci. Pokud chceme sériový port zmnit, musíme použít v ETS Monitoru

- 24 -


pepína -LPT. Komunikaní port nastavíme i v Visual System Builderu, kde vybereme v nastavení Monitoru port (LPT1, LPT2,…) nebo specifickou adresu portu. Pokud na vývojovém systému bží na OS Windows, musíme nainstalovat ovlada zaízení ETSIO.SYS, který umožní komunikovat skrz paralelní kabel a nahrát napíklad program do embedded cílového systému.

2.17 Mapování pístupu zaízení do pamti Real-time ETS jádro pipravuje deskriptor pro 32 bitový datový segment se základem 0 a velikostí 4 GB. Stránkovací jednotka je v ETS jádru vypnuta, a tudíž všechny adresy pamti jsou fyzickými adresami pamti. Embedded systém mže zpístupnit celou fyzickou pam , obsahující i zaízení pímo mapované do pamti, s pímým 32 bitovým ukazatelem. Napíklad: V programu mžeme pímo pistupovat do fyzické pamti grafické karty.

2.18 Píkazová ádka hostitele a systémové prostedí Pi použití standardní programovací techniky C mohou embedded programy povolit k používání píkazový ádek a systémové promnné. Argumenty z píkazové ádky jsou zpístupnné pes parametry argc a argv v main(). Konfiguraní promnné mohou být zpístupovány prostednictvím funkcí getenv() a putenv() nebo pes parametr envp v main(). Možnosti putenv() jsou analogické možnostem _putenv() z MS DOS, ale jen se mní systémové prostedí pro trvání embedded programu. V hostitelském systémovém prostedí nejsou udlány žádné zmny. Bží-li real-time ETS jádro v režimu WaitHost, obsahuje píkazová ádka jméno programu a následující parametry. Pro Developer Studio jsou tyto parametry specifikovány v okn Project Setting. Pro RUNEMB následují tyto parametry za jménem programu na píkazové ádce hostitelského systému. Ve všech pípadech je argv[0] jméno embedded programu.

- 25 -


Máme možnost specifikovat píkazový ádek a konfiguraní promnné v ETS konfiguraním souboru RTOS.INI. Píkazová ádka je specifikována v [General] sekci, kde ádková promnná obsahuje etzec, který bude vracet funkce GetCommandLine(). Typický píklad této promnné je: Píkazová ádka = C:\ProgramName.exe Arg1 Arg2 Cesta je nepovinná, ale vždy musíme uvést jméno programu. Sekce [Enviroment] specifikuje konfiguraní promnné. Každá konfiguraní promnná je specifikovaná na oddlené ádce v souboru podle následující syntaxe: <jméno> = Ve stejné syntaxi jsou i konfiguraní promnné v TEMPLETE.INI, které generuje Embedded ToolSuite (ETS). Po spuštní real-time ETS jádra v režimu WaitHost, volá ETS jádro funkce EtsCustomGetCommandLine() a EtsCustomGetEnvStrings(), které specifikují hodnoty pro píkazový ádek a etzce systémového prostedí. Pokud nejsou hodnoty specifikovány v píkazovém ádku nebo v systémovém prostedí ze souboru RTOS.INI, pak se tyto funkce specifikují v tzv. „ETS fiktivním píkazovém ádku“. Máme možnost napsat náhradní funkce doplující náhradní hodnoty do píkazového ádku a prostedí.

2.19 Zvolení real-time ETS podsystému jádra Real-time ETS jádro má velikou paletu konfiguraních voleb umožující pizpsobení ETS jádra. V real-time ETS jáde je mnoho podsystém popsaných v ETS manuálech (DLL Loader, Email Client, File System, Floating Point Emulator, FTP Server, GUI,…). Každý podsystém je zaveden jménem v souborových píkazech linkeru, které pidá nebo odebere vybraný podsystém. Manuální nastavení se provádí tak, že do LinkLoc píkazové ádky pidáme parametr, který pidá nebo odebere real-time ETS podsystém jádra. Ve Visual System Builderu se vybraný podsystém pidá nebo odebere z linkeru real-time ETS jádra podle aktuálního nastavení v okn nastavení. Embedded ToolSuite (ETS) obsahuje další vlastnosti a souásti, které jsem zde nepopsal:

- 26 -


x

ETS real-time Multi-Tasker, který podporuje real-time vícevláknové programy používané ve Win32 API.

x

ETS TCP/IP zásobník (stack), který poskytuje mnoho možností se specifikací protokol TCP/IP a WinSock 1.1. Na vhodn vybudovaném embedded systému s embedded ToolSuite mžeme spustit sí ové aplikace pes internet/intranet nebo dokonce i sí ový server.

x

SNMP VI agenta, který stanoví MIB II podporu a máme možnost pidat nkteré funkce z MIB do aplikace.

x

MicroWeb server, který bží na vrcholu ETS TCP/IP hromady, dovolí aplikaci udlat http (World Wide Web) server.

x

DLL zavad, který dovolí dynamicky naítat a odebírat moduly za bhu s Win32 API (LoadLibrary(), Free Library()).

x

Emulátor pohyblivé árky, který dovoluje vykonávání operací v pohyblivé árce na cílovém systému bez hardwaru na výpoet pohyblivé árky.

x

ETS balíek podpory pro PC Card, který poskytuje ovladam dovolení zapnout PC Card hardware s ETS aplikací.

x

ETS PEG (Portable Embedded GUI) uživatelské grafické rozhraní, které dovolí budovat grafické rozhranní do embedded aplikace.

2.20 Perušení a výjimky Perušení mže být zaazeno do tí kategorií: x

Hardwarové perušení (zpsobené vnjším hardwarem)

x

Softwarové perušení (provedením INT instrukce)

x

Výjimky procesoru (vytvoené procesorem, když se objeví jisté programovací chyby)

Dv „speciální“ hardwarové perušení jsou od asovae (IRQ 0 pro PC/AT kompatibilní poítae) a klávesnice (IRQ 1). Real-time ETS jádro obsahuje nahraditelné ovladae pro tyto hardwarová zaízení. Ped podniknutím psaní vlastního ovladae pro jedno z tchto zaízení bychom mli zvážit, zda by ETS ovlada nemohl vyhovt nebo zda

- 27 -


by nebylo rychlejší ho modifikovat k našim potebám. Jestliže se ETS aplikace potebuje zabývat výjimkami procesoru, je dobré použít ovládání uspoádání výjimek mechanizmem poskytovaným kompilátorem Visual C++.

2.20.1 Zpracování perušení real-time ETS jádrem Real-time ETS jádro vytváí perušovací tabulku (IDT) deskriptor záznam (nebo vektor) pro všech 256 perušení. Když dojde k obsluze perušení, nemže se vyvolat jiné perušení. Vtšina PC/AT systém má hardwarové perušení IRQ 0 až IRQ 7 mapováno do INT 08h až INT 0Fh a hardwarové perušení IRQ 8 až IRQ 15 mapováno do INT 70h až INT 77h. Výmnné moduly v ETS Monitoru ídí toto mapování. Hardwarové perušení

Vektor

Popis

Priorita

IRQ0

08h

Systémový asova

nejvyšší

IRQ1

09h

Klávesnice

IRQ2

0Ah

Rezervovaný pro podízený PIC

IRQ8

70h

Real-time hodiny

IRQ9

74h

Nepoužité

IRQ10

74h

Nepoužité

IRQ11

74h

Nepoužité

IRQ12

74h

Nepoužité

IRQ13

75h

Koprocesor

IRQ14

76h

adi pevného disku

IRQ15

77h

Nepoužité

IRQ3

0Bh

Sériový port COM2

IRQ4

0Ch

Sériový port COM1

IRQ5

0Dh

Paralelní port LPT2

IRQ6

0Eh

adi disketové mechaniky

IRQ7

0Fh

Paralelní port LPT1

nejnižší

Tab. 2.3 PC/AT kompatibilní hardwarové IRQ azené podle priority

- 28 -


Standardní IDT vstup pro každý bod perušení je v obsloužení perušení v real-time ETS jádru. Obsluha perušení mže rozlišovat mezi hardwarovým perušením nebo výjimkou procesoru, které se pekrývají s vektorem perušení 08h až 0Fh. Mže také vytvoit záznam perušení zásobníku pro zavolání funkce C nebo TNT/DOS Extender kompatibilní obsluhy perušení. Obsluha perušení udržuje 256 vstup ve „stínu“ IDT, která udržuje aktuální adresy každé obslužné rutiny perušení. To také udržuje „stín“ na 8 vstupech tabulky výjimek pro výjimky pekrývající s vektorem perušení 08h až 0Fh.

Obr. 2.4 Programovatelný kontrolér perušení PC/AT Když nastane perušení, tak je pevedena kontrola z aplikace na obsluhu perušení. Obsluha perušení uloží registry, nastaví prostedí a pak pedá ízení obslužné rutin ze „stínu“ IDT. Po návratu z obslužné rutiny se pedá ízení obsluze perušení, ta zpt navrátí hodnotu registr a provede návrat na místo, kde bylo vyvoláno perušení. Real-time ETS jádro používá následující perušení: x

Výjimky procesoru jsou použité pro ladní a strukturované výjimky. Výjimky 01h a 03h jsou použity jako zarážky v ladném programu. Jiné procesorové výjimky se stávají kvli chyb v kódu aplikace, které pinutí pejít program do ladící funkce.

x

Ovlada asovae používá jedno hardwarové perušení (IRQ 0 pro PC/AT kompatibilní systémy).

- 29 -


x

Nepovinný ovlada klávesnice používá jedno hardwarové perušení (IRQ 1)

x

Jestliže ETS Monitor má zapnutou možnost hostitelské komunikace, tak je jedno hardwarové perušení (standardn IRQ 3 nebo IRQ 4 pro sériovou komunikaci, nebo IRQ 7 pro paralelní komunikaci) použito na pro perušení cílového systému z dvodu ladní.

x

Pro PC/AT kompatibilní (8259) adi perušení na cílovém systému používá real-time ETS jádro obsluhu perušení na hardwarovém IRQ 15, které korektn uklidí falešné události perušení IRQ 15 v 8259.

x

Softwarové perušení INT FEh je použito k zajištní monitorovacích služeb.

x

Softwarové perušení INT FFh je použito k zajištní hostitelské služby.

Real-time ETS jádro používá jiná hardwarová perušení pro jednotlivé komponenty jako je MS DOS kompatibilní souborový systém, ETS PC Card podporu balík a ETS TCP/IP zásobník. Všechny jiné stínové IDT záznamy ukazují na standardní obsluhu perušení, které nedlají nic, než že vykonávají IRETD instrukce. Vtšina výjimek procesoru zpsobí zastavení programu v real-time ETS jádru. Jestliže se program vykonává pod kontrolou ladící aplikace, procesorová výjimka obvykle zastaví ladící program a nechá nás diagnostikovat problém. Jestliže program nebží pod ladící aplikací, jádro vypíše zprávu identifikující výjimku a adresu instrukce, která ji zpsobila. Má-li ETS Monitor na cílovém systému možnost komunikace s hostitelským systémem, mže se pipojit k cílovému systému s vývojovou ladící aplikací a prozkoumat tak vzniklé výjimky. S touto pomocí lze najít píinu vzniklého problému.

2.20.2 Instalování obsluhy perušení v aplikaci Obsluha perušení je ást kódu, která se vykonává automaticky procesorem, když nastane perušení. Kód, který navrhne a zpracuje perušení, se nazývá Interrupt Service Routine neboli ISR.

- 30 -


Díve než budeme vytváet obsluhu perušení v ETS aplikaci, tak si musíme rozmyslet strategii pro zachycení perušení, ízení perušení a odchodu z perušení. Vybraná strategie bude ovlivnná druhem perušení, které zachytíme: softwarové perušení, výjimka procesoru nebo hardwarové perušení. Pro softwarové perušení nebo výjimku procesoru je architektura zpracování docela jednoduchá, protože možností zpracování je málo. Softwarové perušení nastanou pouze, pokud jsou nastavené aplikací. Procesorové výjimky obvykle vyplývají z chyby v programu. Ob tyto události jsou synchronní a nastanou pouze, pokud jsou vytvoené kódem programu. Problém však mže vzniknout v obsluze perušení. Pokud se zde dojde k dalšímu

softwarovému

perušení

nebo

výjimce

procesoru,

mže

dojít

k nežádoucímu zacyklení. Doporuená cesta pro použití obsluhy softwarového perušení je instalací obsluhy perušení z C. Pro obsluhu procesorové výjimky se používají dv možnosti: x

Za pedpokladu použití Visual C++ kompilátoru mžeme použít prostedky pro strukturované výjimkové ízení.

x

Použití obsluhy výjimek procesoru z funkcí jazyka C.

Hardwarová perušení jsou více komplikovaná. Nastávají asynchronn a jsou obvykle ízena hardwarovým zaízením, které volá programovatelný adi perušení (nebo PIC). Hardwarová perušení picházejí s požadavkem na real-time obsluhu perušení, protože asto reprezentují njaký skutený druh dje. Jestliže chceme do aplikace vložit ETS real-time Multi-Tasker, budeme si muset vybrat, zda chceme obsluhovat zaízení pímo v obsluze perušení nebo spuštním bhu vlákna, jež obslouží zaízení žádající o perušení. Pedtím, než si vybereme softwarovou strategii pro hardwarového perušení, tak musíme porozumt real-time požadavkm obsluhovaného hardwarového zaízení a jeho souvislostem s požadavky ostatních hardwarových zaízení v cílovém systému

- 31 -


2.21 Ovladae zaízení vložené s real-time ETS jádrem Real-time ETS jádro obsahuje mnoho ovlada periférií, které jsou kompatibilní s cílovými embedded systémy. Cílové systémy, které podporují alespo jednu z tchto podporovaných periférií, mohou (ve vtšin pípad) používat nezmnný ovlada z realtime ETS jádra. Potom mže aplikace v cílovém systému zpístupnit zaízení pes Win32 nebo pomocí funkcí z knihovny C. Real-time ETS jádro zahrnuje vestavnou podporu pro následující druhy ovlada zaízení (tab. 2.4): Typ ovladae

Popis

asova

Ovlada asovae poskytující asové znaky a službu perušení asovae. Ovlada asovae je vyžadován real time ETS jádrem.

Obrazovka

Ovlada obrazovky poskytující služby pro psaní ASCII textu na displeji.

Klávesnice

Ovlada klávesnice poskytující služby pro pijmutí a zpracování stisk kláves a zpracování perušení od klávesnice.

Ukazující zaízení

Ovlada myši poskytuje služby pro píjem a zpracování informace od palety Microsoft mousekompatibilních zaízení jako myši, trackbally, touchpady,…

Disk

Lokální souborový systém obsahující blokové ovladae pro nkolik rozdílných typ diskových zaízení.

Sí

ETS TCP/IP zásobník obsahuje ethernetové ovladae pro nkolik rzných druh ethernetových rozhraní. Také obsahuje 16550 kompatibilní sériový ovlada pro SLIP/PPP spojení.

PC Card

ETS PC Card obsahuje podprný balík ovlada zaízení pro Intel 82365 kompatibilní PC Card Host kontrolér. Také obsahuje i nkolik dalších PC Card zaízení.

Sériový

Ovlada Sériového zaízení poskytne pístup k 16550 nebo 16650 kompatibilních sériových port používaných Win32 API. V ETS specifikaci API jsou také implementována i jiná sériová rozhraní.

- 32 -


TNT embedded ToolSuite zahrnuje ovladae pro množství rzných video karet a ipset. Každý ovlada podporuje specifické množství bit na pixel. Tyto ovladae jsou používány ETS PEG GUI knihovnami

Video

Tab. 2.4 Podpora rzných druh ovlada v real-time ETS jádru Protože je vyžadován v cílovém systému ovlada asovae, tak je instalován standardn. Všechny ostatní ovladae jsou nepovinné a jsou instalovány jen, když jsou použity ve vyvíjeném programu. Ovladae pro PC/AT hardwarovou architekturu jsou umístnny v real-time ETS jádru. Všechen hardwarov-závislý kód v real-time ETS jádru je rozdlen na zdrojový a objektový kód. Jestliže chceme používat tyto ovladae v cílovém systému, který není PC/AT kompatibilní, tak musíme vhodn upravit zdrojové kódy k tmto ovladam.

2.22 Vnitní architektura real-time ETS jádra a inicializace Real-time ETS jádro je fyzicky rozdlené do dvou oddlených kus: x

ETS Monitor

x

knihovny real-time ETS jádra.

ETS monitor je 16 bitový kód poskytující systému inicializaci a hostitelské komunikaní služby. Po spuštní provede hardwarovou inicializaci, pepne procesor do 32 bitového chránného režimu a zane komunikovat s Developer Studiem nebo s RUNEMB. Dále pak stahuje a nahrává aplikace z disku. ETS Monitor mže být zaveden z disku na PC/AT kompatibilním cílovém systému nebo mže být spojen do "kontejneru" spolu s aplikací naprogramovanou v ROM nebo stažen z emulátoru ROM. 32 bitové real-time ETS knihovny jádra jsou spojené s embedded aplikací. Poskytují operanímu systému služby pro embedded aplikaci pes Win32, Winsock 1.1 a real-time ETS API jádra. Všechny nepovinné komponenty v real-time ETS jádru jsou vložené jako oddlené knihovny kvli modularit a škálovatelnosti. Protože real-time ETS jádro je spojeno pímo s aplikaním kódem, tvoí se v ETS aplikaci jen jeden 32 bitový

- 33 -


spustitelný soubor. Soubor obsahuje jak real-time ETS jádro, tak kód aplikace. Vstupní bod pro tento soubor je pi startu inicializaního kódu real-time ETS jádra. Pro cílové embedded systémy spouštné z disku má ETS Monitor a real-time ETS aplikaní jádro soubor, skládající se ze dvou oddlených spustitelných obraz. ETS Monitor je malý binární soubor a real-time ETS aplikaní jádro je 32 bitový penosný soubor formátu.EXE (nebo PE). Pro cílové embedded systémy spouštné z ROM má ETS Monitor a real-time ETS aplikaní jádro obraz, ve kterém jsou: samotný PE obraz a s ETS Monitorem pichází sekce (nebo objekt) s PE nahrávacím obrazem. Tento obraz je zapouzdený v nahrávacím formátu pro ROM nebo v provozním emulátoru. Tento formát bude obvykle binární (.BIN), hexadecimální (.HEX) nebo spustitelný soubor OMF-386 (.OMF). ETS Monitor a real-time ETS knihovny jádra v sob zahrnují hardwarov závislé moduly pro propojení s cílovým embedded hardwarem. Hardwarov závislé moduly pro ETS Monitor zajiš ují své služby pes funkce zaínající jménem EkCustom. Hardwarov závislé moduly pro real-time ETS knihovny jádra zajiš ují své služby pes funkce zaínající jménem EtsCustom. Moduly jsou dodány aplikaci ve form zdrojového i objektovém kódu. Zdrojový kód pro hardwarov závislé moduly v ETS Monitoru je lokalizován v adresái PHAREMB\MONITOR\BUILD. Zdrojový kód pro hardwarov závislé moduly v real-time ETS knihovnách jádra je lokalizován v adresái PHAREMB\LIB\BUILD.

2.23 Pehled sledu zavádní real-time ETS jádra Kapitola pibližuje pohled na zavádcí sekvenci real-time ETS jádra i s vzájemným ovlivováním mezi ETS Monitorem a real-time ETS knihovnami jádra. Zavádní ETS jádra popisují ti kroky, které se vykonají ped první instrukcí main() v programu.

- 34 -


2.23.1 První krok: Inicializace ETS Monitoru Nejprve ETS Monitor pejímá prvotní kontrolu. Prvotní kontrola vykoná nutnou nízkoúrovovou inicializaci embedded cílového systému a pepne systém do 32 bitového chránného režimu. ETS Monitor se pipravuje spustit aplikaci pítomnou v pamti ROM nebo na disku. Další stav inicializace závisí na režimu bhu jádra. V režimu NoWaitHost je kontrola penesena do aplikace. V režimu WaitHost eká ETS monitor na signál z vývojového prostedí hostitele. Vstupním stádiem v ETS aplikaci je zaátek inicializaní sekvence pro real-time ETS knihovny jádra.

2.23.2 Druhý krok: Inicializace real-time ETS knihoven jádra Embedded procesor je v 32 bitovém chránném režimu, když real-time ETS knihovny jádra dostanou kontrolu od ETS Monitoru. Provádjí úlohy nutné k nábhu real-time ETS jádra operaního systému tím, že inicializují real-time ETS podsystémy jádra jeden po druhém v pedureném poadí. ást ETS podsystém se spoléhá na služby poskytované pedtím inicializovanými podsystémy. Po kompletní inicializaci real-time ETS jádra, je operaní systém schopný zajistit systémové služby pro 32 bitovou aplikaci pes Win32, WinSock a ETS API.

2.23.3 Tetí krok: Penesení kontroly do embedded aplikace V posledním kroku inicializaního procesu penáší real-time ETS jádro kontrolu do embedded aplikace. Ta dostane kontrolu u vstupního bodu inicializaního kódu pro provozní knihovnu. Procesor je pak ve stavu popsaném v kapitole 2.7. Provozní inicializace kódu knihovny uiní kroky, které jsou nutné k zavedení této knihovny a udlá zavolání Win32 API na systémové služby real-time ETS jádra. Když se ukoní inicializace provozních knihoven, penáší se kontrola do vstupního bodu aplikace programu, tj. k funkci main(). Od tohoto bodu mže aplikace volat provozní knihovny C a real-time ETS API jádra.

- 35 -


Kapitola

3 3. Popis systému a zásuvných karet

- 36 -


3.1 Struný popis stávajícího systému Podoba stávajícího zaízení CAN DataLogger je uvedena na obr. 1.2. V tomto pvodním zaízení je CAN DataLogger realizován pomocí prmyslového poítae Tiny 586, ke kterému jsou nainstalovány pídavné obslužné karty. Tento poíta se skládá ze sedmi rozšiujících karet, které jsou mezi sebou propojeny komunikaní sbrnicí PC/104. PC/104 vychází z klasické poítaové sbrnice ISA, ale má jiný pipojovací konektor (obr. 3.2), který dovoluje na sebe jednotlivé zásuvné karty vrstvit (obr. 3.3), oproti sbrnici ISA, kde mže být pouze tolik zásuvných karet, kolik je konektor na základní desce. Blokové schéma CAN DataLoggeru je uvedeno na obr.3.1. První zásuvnou kartou je napájecí zdrojová karta. Tato karta mže být napájena naptím v rozmezí 6V až 17V (napájení z automobilové 12V sít). Výstupem karty jsou stabilizovaná naptí pro napájení hlavního poítae, jednotlivých vnitních zásuvných karet a pipojitelných vnjších zaízení. Druhou následují kartou je PCMCIA zásuvná karta (obr. 3.4), která slouží ke komunikaci s PCMCIA flash diskem, ureným pro záznam namených dat systému a k natení nastavení CAN DataLoggeru z konfiguraního souboru. Tato karta je propojena pes IDE kanál k hlavní procesorové kart. Tetí hlavní kartou je samostatný poíta Tiny 586 s PC/AT kompatibilním procesorem 586, který je srdcem celého CAN DataLoggeru. tvrtá chladící karta má na sob nainstalovaný chladicí ventilátorek, který pímo fouká na chladící hliníkový profil procesoru a dále zajiš uje proudní vzduchu uvnit CAN DataLoggeru.

- 37 -


Napájení 12V

Napájecí karta

PCMCIA PCMCIA Flash disk

Hlavní poítaová karta

Chladící karta

A/D karta

CAN karta

Vstupn výstupní galvanické oddlení a ochranné obvody

Displej a klávesnice

PC/104 konektor Vstupy: CANy, A/D, Obr.3.1 Blokové schéma CAN DataLoggeru

- 38 -


Obr. 3.2 Konektor PC/104

Obr. 3.3 Zpsob vrstvení zásuvných karet PC/104

Na páté zásuvné kart (obr. 3.5) jsou umístnny dva izolované analogov digitální pevodníky, sbrnice pro pipojení jednoho vnitního a deseti vnjších teplomr a osm digitálních vstup. Tato karta je popsaná níže v kapitole 3.2.1. Šestá zásuvná karta na sob nese adie CAN (obr. 3.6). I tato karta je popsaná níže v kapitole 3.2.2. Sedmá zásuvná karta (obr. 3.7) obsahuje vstupn výstupní galvanické oddlení digitálních vstup, DC/DC konvertory a ochranné vstupní obvody.

- 39 -


Obr. 3.4 PCMCIA flash disk zásuvná karta

Obr. 3.5 Analogov digitální zásuvná karta

- 40 -


Obr. 3.6 Zásuvná karta s CAN adii

Obr. 3.7 Vstupn výstupní zásuvná karta

- 41 -


3.2 Použité karty v micím systému V použitém micím systému jsou použité ti zásuvné karty: x

První zásuvnou kartou je Analogov digitální karta (3.2.1)

x

Druhou zásuvnou kartou je karta s adii CAN (3.2.2)

x

Tetí zásuvná karta je klasická ethernetová karta (3.2.3)

3.2.1 Analogov digitální karta Analogov digitální karta (obr. 3.5) zajiš uje pro CAN DataLogger následující vstupy: x

Dva osmibitové analogov digitální galvanicky oddlené pevodníky.

x

Sbrnici pro mení teploty, která mže obsahovat až 10 digitálních teplomr s minimální micí dobou 1s.

x

8 digitálních galvanicky oddlených vstup

Všechny registry na kart jsou 16 bitové a karta podporuje pouze 16 bitové cykly. Registry jsou vybavený FIFO pamtí a karta podporuje DMA penosy. Pi dokonení DMA penosu je nastaven signál perušení.Všechny registry jsou mapované do I/O prostoru a celkov zabírají 8 B (tyi 16 bitové registry). Následující tab. 3.1 ukazuje mapování registr:

Relativní adresa

Délka Popis segmentu

0x6

0x002

Píznakový a kontrolní registr

0x4

0x002

Více násobný kontrolní registr

0x2

0x002

Datov komunikaní registr

0x0

0x002

A/D registr

Tab. 3.1 Mapování registr A/D karty

- 42 -


Pro detailnjší popis jednotlivých bit registru doporuuji peíst AD Board Manual (viz 6.1). Struný popis jednotlivých registr je uveden níže: x

A/D registr se skládá z dat z analogov digitálních pevodník. Z tohoto registru se nechá pouze íst.

x

Datov komunikaní registr ídí komunikaci mezi lokálním mikrokontrolérem a systémovým procesorem. Do tohoto registru se mže zapisovat i z nho íst.

x

Více násobný kontrolní registr ídí možné nastavení analogov digitálních kanál. Do tohoto registru se mže pouze zapisovat.

x

Píznakový a kontrolní registr ídí základní úrovn pístupu Analogov digitální karty. Do tohoto registru se mže zapisovat i z nho íst.

Analogov digitální karta pijme jen píkazy a data zapisující se do datového komunikaního registru. Všechny kódy píkaz musí mít osmý bit nastaven na logickou 1 a tená data mají tomto bitu logickou 0. V následující tab. 3.2 jsou píkazy spolu s kódy píkaz.

- 43 -


Píkazy Identifikace teplotního senzoru Definice teplotního senzoru Definice periody senzoru Zaátek mení teploty Konec mení teploty Nastavení vstupní digitální masky Zaátek tení digitálních vstup Konec tení digitálních vstup Nastavení doby A/D pevodu Zaátek A/D pevodu Konec A/D pevodu

Kódy píkaz 0x101 0x102 0x103 0x104 0x105 0x108 0x109 0x10A 0x110 0x111 0x112

Zaátek všech odmr Konec všech odmr

0x120 0x121

Identifikace interního teplotního senzoru Definice interního teplotního senzoru

0x140 0x141

Tab. 3.2 Píkazy Analogov digitální karty

3.2.2 Zásuvná karta s adii CAN Tato karta na obr. 3.6 má na sob 4 adie CAN a hlavní asový generátor, ze kterého se berou asové znaky všech událostí v systému. Karta s adii CAN (Chyba! Nenalezen zdroj odkaz.) zajiš uje pro CAN DataLogger následující funkce: x

Ti nezávislé galvanicky oddlené CAN kanály propojené s CAN sítí pes optické kabely. Tyto CAN kanály jsou použité jen pro tení ze sbrnice.

x

asovou

základnu

CAN

DataLoggeru.

Ta

je

tvoená

bžícím

programovatelným 16 bitovým ítaem. Tento íta je pro náš pípad nastaven na 50 s a je použit k asovým znakám jednotlivých událostí v systému. x

Speciální asová základna pro mení vytížení sbrnice na jednotlivých CANech.

- 44 -


Karta s adii CAN je 16 bitová. Registry adi CAN jsou umístnné v dolní polovin 16 bitového slova, protože CAN adie mají jen 8 bitové rozhraní (horních 8 bit je nulových). Tato karta generuje perušení, které zpracovává hlavní procesor. Všechny registry na kart jsou mapovány do pamti poítae. Celkov tato pam zabírá 2 kB. Do prvního kB jsou mapovány CAN adie (4 x 256 B každý) a v druhém jsou ostatní registry pro celkové ovládání a nastavování karty. Následující tab. 3.3 ukazuje pohled na význam jednotlivých registr. Pro detailnjší popis jednotlivých bit registr doporuuji peíst CAN Board Manual (viz 6.1). Struný popis vybraných v programu použitých registr je uveden níže: x

Jednotlivé registry CAN(x) adi jsou popsané v datasheetu od obvodu SJA1000 (jsou použité jako adie CANu).

x

Kontrolní registr perušení – zde se nastavují, povolují a vypínají jednotlivá perušení

x

Stavový registr perušení – obsahuje informace o tom, která služba nebo funkce nastavila perušení

x

Vstupní konfiguraní registr perušení – zde se nastavuje resetování a jednotlivá nastavení perušení CAN adi

x

Konfiguraní registr ítae asu – umožuje nastavení generování asových znaek

x

Poet tení z registru – poet tecích pístup na kartu s CAN adii

x

Registr verze – informace o verzi karty s CAN adii

3.2.3 Ethernet karta Ve vývojové poítai je použita normální ethernetová karta 10/100 Mbit/s, pipojená na sbrnici PCI. Tato konkrétní karta na sob nese ipset RTL 8139 od firmy Realtek.

- 45 -


Relativní adresa

Délka Popis segmentu

Typ

Relat. adresa registru

0x7FF

…

Rezervováno

-

1023

…

…

…

…

…

0x420

…

Rezervováno

-

16

0x41E

0x002

íta asových událostí

0x41C

0x002

íst i psát

15

(2)

íst

14

(2)

EINT2 Time Stamp register

0x41A

0x002

EINT1 Time Stamp register

íst

13

0x418

0x002

EINT0 Time Stamp register(2)

íst

12

0x416

0x002

Rozšíený CAN Time Stamp register

íst

11

0x414

0x002

CAN2 Time Stamp register

íst

10

0x412

0x002


íst

9

0x410

0x002


íst

8

0x40E

0x002

Registr s verzí karty

íst

7

0x40C

0x002

Poet tení z registru

íst

6

0x40A

0x002

Rezervováno

-

5

0x408

0x002

Rezervováno

-

4

0x406

0x002

Konfiguraní registr ítae asu

íst i psát

3

0x404

0x002

Vstupní konfiguraní reg. perušení

íst i psát

2

0x402

0x002

Stavový registr perušení

íst i psát

1

0x400

0x002

Kontrolní registr perušení

íst i psát

0

0x300

0x100

Rozšíený CAN3 adi

Registry CANu

X

0x200

0x100

CAN2 adi

Registry CANu

X

0x100

0x100

CAN1 adi

Registry CANu

X

0x000

0x100

CAN0 adi

Registry CANu

X

Tab. 3.3 Registry Karty s CAN adii

- 46 -


Kapitola

4 4. ešení úkolu

- 47 -


V této ásti diplomové práce je popsána navržená funkce hlavního programu pro hlavní jednotku systému sbru dat - CAN DataLoggeru. Popis je rozdlen na popis toho, co se dje ped a po hlavní smyce (4.1) a na popis hlavní smyky programu (4.2). Jako hlavní smyka je zde brána ást programu, do které se dostane po prvotním nastavení a opustí ho jedin po zadaném píkazu exit. V poslední ásti se budu vnovat popisu funkce obsluhy perušení (4.4).

4.1 Popis programu ped a po hlavní smyce Poté co je ETS Monitorem nahrán program do pamti poítae CAN DataLoggeru, spouští se program. Nejdíve se provede postupné spouštní ty setup funkcí: x

Funkce setupExpressions() - tato funkce nejdíve vynuluje pole adres teplomr a poté se je pokouší naíst do tohoto pole. Naítání je provádno ze souboru SENSORS.CFG, který je uložen na disku. Tyto teplomry budou pipojené ke CAN DataLoggeru jako vnjší senzory teploty.

x

Funkce initLAN() - tato funkce inicializuje sí ovou kartu tak, že nastaví WinSock 1.1, vytvoí Socket a nastaví sí ovou adresu a port. Pokud vše probhlo v poádku, tak se nastaví promnná LanOK.

x

Funkci setupBuffer() - tato funkce zarezervuje 5 MB pamti pro DMA penosy z analogov digitální karty. Dále program zarezervuje a zamkne zbytek pamti pro logovací a monitorovací buffery.

x

Funkce setupHW() - tato funkce hned na zaátku inicializuje a nastavuje funkce globálního perušení, poté pechází k inicializaci karty s adii CAN. V této kart nastavuje konfiguraní registr ítae asu na 50 s a vedlejší na 1 ms. Znaky po 50 s jsou použité k oznaování as jednotlivých událostí, který systém mením zachytí. 1 ms znaky slouží hlavn jako asová základna k výpotu vytížení sbrnice CAN. Zápisem do registru se také provede reset jednotlivých adi CAN. Po resetu CAN adi se udlá jejich na stavení funkcí setupSJA1000(). Tato funkce te z tabulky jednotlivé hodnoty a zapisuje je do registr CAN adi. Tyto adie jsou nastavené jen na odposlech CAN

- 48 -


sbrnice, tedy pouze na její monitorování. Po nastavení všech CAN adi následuje resetování analogov digitální karty. Provede se inicializace DMA adie a zakázání 8 a 16 bitových DMA kanál. Zapnou se, ze zaátku inicializované, funkce perušení. Posledním krokem této funkce je zjištní pítomnosti grafické karty. x

Funkce setupVideo(), která vypíše na obrazovku masku jednotlivých promnných. Do této masky se pak budou vypisovat hodnoty promnných. Výpis dat na obrazovku se dlá pímým zápisem hodnoty do pamti grafické karty. Pro tyto zápisy se využívají funkce printText(), která vypisuje textové etzce od zadaných souadnic, a funkce printNumber(), která dlá totéž, ale s íselnými hodnotami.

Od této doby bží program ve hlavní smyce, ze které ho mže dostat jen píkaz exit, zadaný z klávesnice. Po píkazu exit následují analogicky ti funkce typu unSetup: x

Funkce unSetupHW() - vypíná zapnutá globální perušení i generování perušení kartou CAN adi.

x

Funkce unsetupBuffer(), která odemkne zamknutou pam (pro logovací a monitorovací buffer) a provede její optovné uvolnní systému. Funkce ješt nakonec uvolní zarezervovanou pam pro DMA penosy.

x

Funkce unSetupLAN, která uzave otevený Socket sí ové komunikace.

- 49 -


Start programu

setupExpressions()

Název promnné v programu programStatus lineCommand

Použitá zkratka PS LC

systemError

SE

setupLAN() Promnné programStatus se v programu piazují hodnoty PROGRAM_START, PROGRAM_CARD, atd, ale zde pro pehlednost budu tyto názvy zkracovat na Start, Card, atd. Analogicky pak i u promnných lineCommand a systemError.

setupBuffer()

setupHW()

setupVideo()

PS = Start, LC = None, SE = None

printVideo()

Je vstup z klávesnice?

ano

Uložení znaku do LC

Start

Výpis ísla chyby

Card

programCard()

PS = Card SE = None

PS = NC

PS = INIT

EX

PS = EXIT

LC =

pokraování níže

- 50 -


pokraování výše

Init1

initConfigExpresion()

ConfigFromFile()

Nastala chyba?

Ano

PS = Start Nastaví se SE

initExpresions()

checkFreeSize()

Init2

PS = Init2

initHW()

PS = Nastala chyba?

Ano

PS = UnInit Nastaví se SE PS = Run

Run

programRun()

Nastala chyba?

UnInit

pokraování níže

Ano

PS = UnInit Nastaví se SE

unInitHW()

Podle druhu chyby SE

Ano

Ano

- 51 -

PS = Start

PS = Init2


pokraování výše

Exit

unSetupHW()

unSetupBuffer() PS = unSetupLAN()

Konec programu

Obr. 4.1 Blokové schéma hlavní smyky

4.2 Popis bhu programu v hlavní smyce Tento kód je vykonáván neustále dokola, dokud není zadán povel k ukonení programu. Jsou zde njaké píkazy, které se provádjí vždy a dále píkaz switch, který vykonává rzné innosti, podle stavu, ve kterém program práv je (mení, chyby, atd.). Ve smyce while se vždy volá funkce pro zobrazení hodnot promnných na obrazovku. Dále je zde zajištn píjem zpráv od displeje a také z klávesnice. Následuje zpracování dvou zpráv od displeje a to odpovdi na dotaz, zda-li hlavní jednotka žije a vyslání stavových zpráv, když displej nastartuje. Dále je již bh programu závislý na aktuálním stavu. Prbh programu je dobe vidt na blokovém schématu programu (obr. 4.1). Program mže být v následujících stavech: x

START - V tomto stavu program pošle displeji zprávu, že eká na spuštní a pidá kód chyby, pokud njaká je. Program z tohoto stavu okamžit pejde do následujícího stavu CARD. V tomto stavu (START) je také program po startu.

x

CARD - Zde program eká na zprávu od displeje, bu Spustit program nebo Odchod z systému. Pouze v tomto stavu je také volána funkce programCard()

- 52 -


umožující íst a mnit as a datum. Jestliže pijde zpráva Spustit program, program zmní stav na INIT1, po zpráv Odchod z systému je stav EXIT. x

INIT1 - V tomto stavu program provádí první ást inicializace ped spuštním mení. Nejprve následuje inicializace promnných - nejdíve se nastaví na pipravené hodnoty konfiguraní promnné funkcí initConfigExpression(), poté se provede funkcí configFromFile() natení tchto konfiguraních promnných z konfiguraního souboru a poté se funkcí initExpression() nainicializují ostatní systémové promnné (nkteré podle natených konfiguraních promnných). Následn program zjistí funkcí checkFreeSize(), kolik je volného místa na flash kart. Na závr program vyšle stavové zprávy. Jestliže nkde bhem tchto inností nastala chyba, je okamžit další innost ukonena, nastaví se odpovídající chybová promnná a program pejde do stavu START, kde se tato chyba zobrazí. Je-li vše v poádku, program pejde do stavu INIT2.

x

INIT2 - V tomto stavu se provede inicializace hardware funkcí initHW(). Jestliže inicializace neprobhne v poádku program pejde do stavu UNINIT s píslušnou chybou, kde se pokusí funkcí unInitHW() nejprve hardware odinicializovat a pak pejde do stavu START. Jestli je inicializace v poádku program pejde do stavu RUN. Inicializace je rozdlena na dva stavy protože po restartování není teba provádt inicializaci promnných, ale jen hardware.

x

RUN - V tomto stavu je volána funkce programRun() pro obsluhu záznamu dat. Jestliže tato funkce detekuje njakou chybu, nebo je zadán píkaz pro ukonení záznamu dat, tak program pejde do následujícího stavu UNINIT.

x

UNINIT - Zde se nejprve odinicializuje hardware funkcí unInitHW(). Následn se již jen rozhoduje do jakého stavu má program pejít. Jestliže kód chyby udává chybu, program pejde do stavu START. Jestliže chyba má význam restartu, program pejde do stavu INIT2, kde zane mení znovu. Jinak (normální konec) program pejde do stavu START.

x

EXIT - Tento stav nezpracovává píkaz switch. Jestliže je program v tomto stavu bude ukonena smyka while a tím je zajištno ukonení programu.

- 53 -


Popis nevysvtlených funkcí použitých v hlavní smyce: x programCard() - pomocí této funkce je možné z displeje nastavit a íst as a datum z pamti CMOS v hlavní jednotce. x initConfigExpression() - zde se nastavují promnné, které se budou v následujícím kroku nastavovat z konfiguraního souboru. Zde jsou promnné nastaveny na hodnoty, které zajiš ují, že budou všechny innosti programu zastavené - jestliže nebudou povoleny z konfiguraního souboru. x

configFromFile() - je hlavní funkce pro naítání konfigurace. Funkce se nejprve pokusí nalézt na flash kart konfiguraní soubor. Jestliže jej nenajde, tak skoní s chybou. V opaném pípad nate ádku konfiguraního souboru a provede její zpracování. Toto se opakuje dokud je co naítat z konfiguraního souboru. Zpracování ádky znamená, že se nejprve provede rozdlení typu ádky: poznámky a prázdné ádky se ignorují, je-li ádka návštím nové sekce, provede se pokus o nalezení jejího indexu. Jestliže se jméno sekce neshoduje s nkterým peddefinovaným jménem (neznámá sekce) je zajištno, že se budou následující ádky ignorovat až do nalezení nové známé sekce. Jestliže se ádka dosud nezpracovala, musí obsahovat píkaz pro nastavení promnné. Nejprve se provede kontrola, jestli ádka obsahuje znak „=“. Jestliže jej neosahuje, celá funkce se ukoní s chybou. Jestliže za znaménkem „=“ nic není, nebo je-li nastavena neznámá sekce, ádka se ignoruje. Jinak se provede pokus o nalezení indexu promnné v dané sekci. Jestliže se tento pokus nezdaí, je funkce opt ukonena s chybou. Naopak se pokrauje zavoláním funkce readExpression() pro natení hodnoty a zavolá se funkce setExpression() pro nastavení konkrétní promnné na konkrétní hodnotu. Ob tyto funkce provádjí kontrolu na chyby, jestliže tedy zjistí chybn zapsané údaje vrátí chybový kód a zde se také provede ukonení s chybou. Na závr této funkce se provede úprava a kontrola rozsahu promnné „vzorkovací perioda AD kanál“, protože velikost této promnné je závislá na potu povolených AD kanál, což je známé až na konci naítání všech promnných. Následuje uzavení konfiguraního souboru. Tím je konfigurace ze souboru hotova.

- 54 -


x

initHW() - tato funkce slouží pro inicializaci hardware ped každým spuštním mení. V první ásti této funkce se resetují a inicializují registry v Altee, adie SJA1000, AD karta a adi DMA. Také se zde zjistí verze firmware AD karty. Následuje ást, která slouží pro zjiš ování adres nových teplomr a piazení adresy internímu teplomru. Program detekuje jeden pipojený teplomr a podle jeho adresy rozhodne, která ze dvou peddefinovaných sad bude používána. Jestliže není teplomr nalezen ani v jedné sad, je bh systému ukonen s chybou. Následuje hardwarové spuštní perušení v registru v Altee. Provede se test jestli vznikne první perušení po 1ms (od Bus-Loadu). V další ásti se již provádí konfigurace a pípadné spouštní jednotlivých ástí hardware podle konfigurace, která byla natena z karty. Jako první se takto provede spuštní CAN, následují teplomry a digitální vstupy. Na závr se spustí AD neboli DMA kanály. Pro tyto kanály se provede test, jestli první DMA penos probhl.

x unInitHW() - tato funkce se volá na každém konci mení. Je zde tedy teba zastavit všechny vstupy. Nejprve se zastaví všechna perušení, pak DMA penosy. Zastaví se innosti AD karty a adi SJA1000. Je teba nejprve zastavit perušení a až pak zadat píkaz pro zastavení inností na AD kart, protože pi zadávání píkazu k zastavení nesmí vzniknout perušení, které by pracovalo s AD kartou. x

programRun() Tato funkce zajiš uje obsluhu záznamu dat. Je volána z hlavní smyky, když je

program ve stavu záznamu dat. Jsou zde zajištny píslušné vstupy a výstupy informací na displej, správa pamti a zajištní správného provedení triggeru. Jako první se provede zachycení aktuálních hodnot promnných, které se mní v perušení. Zpracování dat se musí provádt pro platnou hodnotu, a nelze aby se tato hodnota bhem zpracování mnila. Nyní se otestují pípadné problémy, které by mohly zabránit v pokraování záznamu dat. Jedná se o vyhodnocení poítadla restart. Jestliže poítadlo restart pekroilo jistou mez je program ukonen s chybou. Poítadlo restart má za úkol hlídat, jestli není v systému njaká závada, kvli které je další bh systému nemožný. Kontrola správné innosti systému je zajištna zprávou, která se pedává hodnotou interního teplomru. Tato zpráva je pravideln (2 sec) vysílána pomocí perušení z AD karty. Perušení od A/D karty se

- 55 -


pedávají do programu skrz kartu CAN (neobsluhuje ji procesor), která pedává všechna perušení (ta už obsluhuje je procesor). Takto je tedy zajištno, jestliže tato zpráva dojde, platí

s vysokou

pravdpodobností,

že

je

systém

v poádku.

Program

provádí

vyhodnocování stavu systému. Má-li poítadlo restart hodnotu vyšší než 0 a pijde-li zpráva od interního teplomru, je hodnota poítadla snížena o jedniku. Naopak, nepijdeli tato zpráva do 3 sec. od minulé nebo od startu systému, je hodnota poítadla zvtšena o 3. V tomto stavu systém bu hodn chybuje nebo nechodí vbec. V následující ásti je zajištn píjem píkaz od displeje, které se používají pi záznamu dat. Jedná se o zprávy Manuální trigger, Pauza nastav / vypni a Stop. Pi píjmu každé této zprávy se nastaví píslušné promnné. Nyní se zajistí vysílání zpráv: Aktivita CAN a teplota interního teplomru. Zpráva Aktivita CAN se vysílá periodicky a udává, jestli na dané sbrnici CAN v uplynulém ase probíhala njaká innost. Zpráva o teplot interního teplomru se pouze vytvoí z hodnoty pedané v perušení. Následuje blok, který zajiš uje správu pamti. Nejprve se otestuje, jestli není trigger aktivní. Jestliže není aktivní, provede se posun ukazovátka hranice na adresu ocásku (není teba pam navíc blokovat) a také nulování píznaku peteení buffer. Jestliže je detekováno peteení bufferu znamená to ukonení ekání na post-trigger, a proto nemá význam detekovat peteení, jestliže není trigger aktivní a také je teba vynulovat píznak peteení ped jakýmkoli zahájením triggeru. V následující asti programu se provádí správa DMA. Nejprve je teba vyíst z adie DMA aktuální adresu, na kterou práv probíhá zápis. Tato innost má úskalí v tom, že jde o ti 8 bitové registry, které neustále ítají adresu a nelze je zastavit. Zjištní adresy se tedy provede v cyklu, který se ukoní, jen tehdy jestliže nenastane perušení od konce DMA, tím je zajištna platnost stránky (nejvyššího registru adresy). V tomto cyklu se nate aktuální adresa dvakrát, po skonení cyklu se provede vyhodnocení. Jestliže je adresa z prvního tení menší než z druhého tení, prohlásí se za platnou adresa z prvního tení (menší). Naopak (není-li adresa z prvního tení menší než z druhého tení) prohlásí se za platnou adresa z druhého tení. Zde se jedná o zachycení peteení pi tení dvou spodních registr. Tyto registry se tou od nejnižšího. Jestliže tedy dojde k peteení budou petené hodnoty vypadat asi njak následovn: 0x00fd - 0x01ff - 0x0101. Jestliže budeme íst dv hodnoty, správná hodnota bude vždy ta menší. Je teba poznamenat, že pi tení

- 56 -


adresy DMA se vytou také nkteré promnné, které je teba zachytit, protože se mní v perušení a pi dalším zpracování by mohly mít jinou hodnotu. Následuje kontrola na peteení DMA bufferu, které by mohlo nastat, jestliže by systém ekal na post-trigger, a mezitím by se DMA buffer otoil dokola. Dále se provede výpoet hlaviky a ocásku DMA bufferu. Hlavika DMA bufferu se mírn odlišuje od hlaviek logovacího a monitorovacího bufferu a to tím, že as analogových dat, na které ukazuje hlavika mže být vtší než aktuální as (as zpráv, na které ukazuje hlavika monitorovacího nebo logovacího bufferu, nesmí být vtší než aktuální as). Nejprve se vypoítá poet byt pro pre-trigger. Tento výpoet se provádí z asu pro pre-trigger s pipotením asového rozdílu mezi asem dat, na které ukazuje hlavika, a aktuálním asem. Ocásek se vypoítá odetením tchto byt od hlaviky. Jestliže ješt nebyl zaznamenán dostatený poet byt (po startu systému), je ocásek nastaven na zaátek bufferu. Tím je zajištna správa DMA bufferu. Dále se provede správa logovacího a monitorovacího bufferu. Nejprve se vypoítá nová hodnota ukazovátka ocásku. Ukazovátko ocásku má ukazovat na zprávu, která má svoji asovou znaku zpoždnou od aktuálního asu o daný asový interval. K tomuto zpracování slouží následující kód: while(1) { if (small1.tail == small1.write) break; if (small1.tail == small1.stop) small1.tail = 0x00000000L; if ( ((*(U32 *)(small1.memory+small1.tail+2)) + globalCfg.preTimeSmall) > lTimeGlobal ) break; small1.tail += ((*(small1.memory+small1.tail+1)) + 2); }

Nejprve se provede test, jestli ocásek neukazuje za poslední uloženou zprávu, to se mže stát v pípad, kdy od píjmu poslední zprávy již ubhl as delší, než daný pretrigger, v tomto pípad se hledání ukoní. Jestliže ocásek ukazuje na znaku konce bufferu je pesmrován na zaátek bufferu (kruhový buffer). Nyní následuje vytení asové znaky zprávy, na kterou ukazuje ocásek. Jestliže tato znaka leží v intervalu pre-triggeru, další hledání se již ukoní. Jinak se ukazovátko posune na další zprávu a zaíná nové vyhodnocení.

- 57 -


Po vyhodnocení ukazovátka ocásku se provede zpracování ukazovátka pro tení dat - ukazovátka hlaviky. Toto zpracování provádí následující blok: while(1) { if (small1.head == small1.write) break; if (small1.head == small1.stop) small1.head = 0x00000000L; if ( (*(U32 *)(small1.memory+small1.head+2)) > lTimeGlobal ) break; if ( (*(small1.memory+small1.head)) & TYPE_TRG ) { if (triggerStatus == 0x00) { trigger.address = small1.memory+small1.head; triggerStatus++; } else { *(small1.memory+small1.head) &= (~TYPE_TRG); } } small1.head += ((*(small1.memory+small1.head+1)) + 2); }

Nejprve se otestuje, jestli neukazuje hlavika na konec bufferu, neboli na zapisovací ukazovátko. Jestliže ano, není teba nic dlat a práce se ukoní. Dále je zde zajištní správné funkce kruhového bufferu, neboli pesmrování z konce na zaátek. Dále se provede kontrola, jestli nechce ukazovátko íst i dál, než kam ukazuje aktuální as. Jestliže ano, práce se ukoní, nebo další data se budou zpracovávat až píšt. Zpracovávání se provádí jen do aktuálního asu. Nyní se otestuje, jestli zpráva, na kterou ukazuje hlavika, nemá nastaven píznak triggeru. Jestliže ano a jestliže není žádný trigger aktivní a ani není nastaven píznak pauzy (je možný vznik nového triggeru), tak se provede zaznamenání adresy triggeru a trigger se zahájí. Jestliže je již trigger aktivní nebo je aktivní pauza, tak se provede vymazání píznaku triggeru v této zpráv, nebo nesmí být v jednom záznamu dv zprávy oznaeny píznakem triggeru. Jestliže tedy hledání ješt neskonilo, posune se ukazovátko hlaviky na další zprávu. Všechna tato zpracování se provedou jak pro monitorovací, tak i pro logovací buffer. Popis mechanismu práce programu s pamtí obsahuje kapitola (4.4.1).

- 58 -


V následující ásti programu se provádí zpracování trigger. Zpracování trigger se provádí postupn, neboli je rozdleno na jednotlivé stavy. V každém stavu se provádí jednotlivá ást zpracování triggeru. Nultý stav signalizuje, že žádný trigger nenastal a ani není aktivní. V tomto stavu se zde neprovádjí žádné operace. V prvním stavu, který znamená zahájení triggeru, se provedou innosti související se zahájením nového triggeru. Pipraví se popisná struktura triggeru, která obsahuje aktuální as a datum, as konce post-triggeru pro každý ze tí buffer a také se zde zaznamenají ocásky jednotlivých buffer. Pesnji eeno nezaznamenává se hodnota ocásku, ale hodnota ukazovátka hranice, nebo ta obsahuje minulou hodnotu ocásku. Dále zde program zjistí jméno datového souboru, který se bude vytváet a souasn provede aktualizaci souboru SUMMARY.CFG tímto jménem. Na závr se nastaví píznaky pro vyslání zpráv do displeje. Vyslány budou zprávy o stavu programu, o píin vzniku triggeru a o jménu práv ukládaného datového souboru. Ve druhém stavu zpracování triggeru program eká na uplynutí doby post-triggeru. Pro každý buffer byl v prvním stavu spoítán as, který je poteba zaznamenat pro post-trigger. Každý buffer má zde svj píznak, jestli už jeho doba uplynula. Ukonení záznamu post-triggeru se provede také, když je nastaven píznak zaplnní bufferu. Když je buffer zaplnn, tak se do nj již další záznamy nevejdou a nemá tedy smysl dále ekat. Aby program odešel z tohoto stavu musí být nastaveny píznaky od všech tí buffer. Vždy když je splnn záznam post-triggeru toho kterého bufferu, je uloženo ukazovátko hlaviky do popisné struktury triggeru a nastaven píznak splnní tohoto post-triggeru. Pouze pi konení zaznamenávání bufferu DMA se ješt uloží as bytu na který ukazuje hlavika DMA bufferu. Ve tetím stavu se provádí zahájení ukládání záznam z pamti na flash kartu. Jsou zde volány dv funkce z programového modulu Disk. První funkce translateTrigger() zajistí pipravení dat pro zápis na flash kartu - vyplní se zde úvodní a konený záznam v souboru a zaznamenají se zde úseky pamti, které se budou zapisovat na kartu. Druhá funkce openFile() oteve soubor pro zápis. Poté zpracování triggeru pejde do následujícího stavu.

- 59 -


Ve tvrtém stavu se provádí zápis záznam z pamti na flash kartu. Tento zápis provádí funkce saveBlock(). Touto funkcí je zajištno, že se ukládání bude provádt po blocích. Program bude postupn volat tuto funkci dokud nebude uloženo vše. Toto rozdlení zápisu do blok, je z dvodu definovaného asového zdržení pi zápisu. Jestliže bude poteba zaznamenat vtší záznam, tento záznam se provede na nkolikrát, pitom mezi jednotlivými ukládáními se provede normální zajištní innosti programu. Po provedení zápisu zpracování triggeru pokrauje do následujícího stavu. V pátém stavu zpracování triggeru se provádí uzavení datového souboru funkcí closeFile(). Poté stav zpracování triggeru pejde do následujícího stavu. V šestém stavu se zajiš uje ukonování zpracování triggeru. Program zavolá funkci checkFreeSize(), která zjistí kolik je volného místa na flash kart. Poté se zajistí vyslání zpráv o stavu programu, pípadné varování, že další záznam se na kartu asi nevejde a zpráva o volném míst na flash kart. Na závr se zruší píznak triggeru ve zpráv, která zpsobila tento, práv konící trigger. Je teba poznamenat, že pi každé práci s flash kartou se provádí vyhodnocování chyb, jestliže nastane njaká chyba, je tento program (funkce) ukonena s chybou. Na závr se zjiš uje s jakým ukonovacím kódem (neboli chybovým kódem) bude program ukonen. Normáln je ukonen s kódem, který udává, že žádná chyba nenastala. Pouze v pípad, že uživatel zadal z displeje píkaz k ukonení mení a také jestli se souasn neprovádí zpracování triggeru (nap. ekání na post-trigger) je program ukonen s kódem, který udává konec mení. Jestliže uživatel zadal píkaz k ukonení mení a ješt se zpracovává trigger, tak se poká na dokonení triggeru a až pak se mení ukoní.

4.3 Popis a správa pamti buffer Hlavní inností tohoto programu je mení a záznam dat. Pro zajištní trigger (pre-trigger a post-trigger) a také kvli rychlosti zápisu na flash kartu je teba data uchovávat v operaní pamti. Data jsou v pamti uchovávána ve tech bufferech: monitorovací, logovací a DMA. Monitorovací buffer slouží pro ukládání vtšiny dat, až na vtšinu dat ze sbrnic CAN. Tento buffer je navržen pro záznam delších asových

- 60 -


interval. Logovací buffer slouží pro bžný záznam dat ze sbrnic CAN. Je navržen pro kratší asový interval záznamu (asto však ne menší, co se týe objemu dat). DMA buffer, neboli buffer pro záznam dat z analogov-íslicových pevodník se od pedchozích dvou buffer znan odlišuje, nebo tento záznam neprobíhá v perušení, ale pomocí DMA penosu.

4.3.1 DMA buffer Správa tohoto bufferu je jednodušší než dvou následujících. Ukládání dat do tohoto bufferu zajiš uje DMA a to s danou rychlostí penosu, která odpovídá vzorkovací frekvenci analogových kanál. Pro správnou funkci DMA je teba rezervovat pam pro tyto penosy. V programu se používají nejvtší možné DMA bloky. Po každém dokonení tohoto bloku je vygenerováno perušení, kde se provede nové nastavení a spuštní penosu DMA. V tomto perušení se také pete asová znaka, ze které lze pozdji pomocí vzorkovací periody odvodit asové znaky penosu jakéhokoli bytu. Také se zde poítá ukazovátko hlaviky a ocásku. Tento výpoet se provádí však pouze kvli piblížení práce se všemi temi buffery a o hodn jednodušeji než u následujících dvou buffer, nebo zde mžeme znát pesn asovou znaku každého bytu.

4.3.2 Logovací a monitorovací buffer Tyto dva buffery slouží pro záznam dat v pamti. Práce s obma je naprosto shodná. Hlavní myšlenka je, že do tchto buffer se budou data ukládat v perušení a hlavní smyka programu bude zajiš ovat jejich správu a také pípadné ukládání uložených dat z buffer na flash kartu. Buffery jsou navrženy jako kruhové buffery. Pro práci s tmito buffery jsou v programu zavedena následující ukazovátka: x

hranice (boundary) - Toto ukazovátko slouží k zabránní peteení bufferu, nebo není možné aby zapisovací ukazovátko pekroilo tuto mez. Nejastji se sem kopíruje minulá hodnota ocásku.

- 61 -


x

ocásek (tail) - Ukazuje za poslední zprávu, která neodpovídala asovému intervalu pre-trigger, neboli na zaátek první zprávy, která odpovídá asovému intervalu pre-trigger. Je to zaátek (starší konec) kruhového bufferu.

x

hlavika (head) - Ukazuje za konec poslední zprávy, která byla zpracována v hlavním programu. Je to konec (mladší konec) kruhového bufferu.

x

zápis (write) - Ukazuje za poslední zapsanou zprávu. Sem se zapisuje v perušení.

x

konec (stop) - Tato adresa znaí pesmrování na zaátek pamti - bufferu. Na konci pamti - bufferu se zprávy nerozdlují na byty, ale za poslední zprávu ukazuje toto ukazovátko.

x

maximum (max) - Fyzická maximální adresa pamti - bufferu.

BUFFER PRO ZÁZN AM DAT Hra nice (Bou nda ry)

Ocá se k (Ta il)

Hla vika (He a d)

Zá pi s (W rite )

Kone c (Stop )

Ma x im um (Ma x )

Da ta pro zá zna m

AKT U ÁLNÍ AS

Obr. 4.2 Schéma bufferu pro záznam dat

4.3.3 Zápis dat na flash disk Pi zapisování dat na flash kartu je teba dodržet pedepsaný formát: hlavika, jednotlivé buffery a hlavika na závr. Pro vytváení takového souboru jsou zde funkce, které nejprve logicky pipraví data pro zápis a také funkce, které provedou fyzický zápis dat na kartu. Zápis dat po triggeru, tedy probíhá takto: nejprve je zavolána funkce translateTrigger(), která zajistí volání podízených funkcí: storeBegin(), storeBig(),

- 62 -


storeSmall(), storeAD() a storeEnd(). Tyto funkce nastaví ve speciální struktue adresy v pamti, kde zaíná a koní data pro uložení a také pipraví v pamti data pro zápis (spoítají délky jednotlivých buffer, vyplní pole o konfiguraci a podobn). Funkce storeBegin() pipraví v pamti pole obsahující hlaviku a indexy zaátk jednotlivých blok dat. Funkce storeBig() a storeSmall() pipraví monitorovací resp. logovací buffer pro zápis. Funkce storeAD() pipraví buffer AD kanál pro zápis, což vyžaduje také vytvoení interní hlaviky tohoto AD záznamu. Tato hlavika obsahuje údaje o velikosti tohoto bufferu, o potu zapnutých AD kanál, o vzorkovací period a jiné. Funkce storeEnd() vytváí zakonovací záznam. Tento záznam obsahuje údaje o aktuálním ase a hlaviku na závr souboru.

4.4 Popis funkce obsluhy perušení v programu Tento modul zajiš uje pijímání dat a jejich ukládání do pamti. Tento píjem se provádí pouze v perušení. Tím je zajištno, že v dob zápisu do pamti, nebude nikdo jiný s pamtí pracovat, protože ani perušení se navzájem neperušují. Jak je vysvtleno dále i zpracování manuálního triggeru a Bus-Loadu se provádí v perušení. Zde se využívá asování pro výpoet Bus-Loadu, tedy každou 1 ms nastane perušení pro výpoet Bus-Loadu a tehdy se zpracuje jak Bus-Load tak i manuální trigger. Pi každé detekci triggeru je vygenerován puls na tvrtém CANu. Toto slouží pro pípadné spuštní osciloskopu, pro detailní sledování stavu vybrané veliiny. Tento puls je vygenerován pi každém možném novém triggeru bez ohledu na to, je-li vznik nového triggeru možný nebo ne, nebo platnost trigger se posuzuje až v hlavním programu a ne zde, v perušení.

4.4.1 Zápis záznam do pamti Jak již bylo vysvtleno, tak se do pamti zapisuje pi píjmu dat v perušení a data v pamti se vyhodnocují a zpracovávají v hlavním smyce programu.

- 63 -


Ve funkcích pro píjem dat se vždy opakuje následující ást kódu: (píklad viz obr. 4.3). Na prvním ádku se odhadne místo, kam se bude zapisovat. Následuje kontrola, jestli pam tímto zápisem nebude peplnna. Ješt je teba otestovat, jestli nedojde k peteení pamti - kruhového bufferu. Jestliže dojde k peteení, opt se zkontroluje peplnní a dojde k patinému nastavení promnných. Jestliže vše dopadlo dobe a je nalezeno místo pro nový záznam, dojde k zápisu tohoto záznamu do pamti (zde se jedná o manuální trigger). headNew = big1.write + LEN_DATA_MANUAL; if ( (big1.write < big1.boundary) && (headNew >= big1.boundary) ) { memoryError |= OVER_MONITOR; return; } if (headNew > big1.max) { if (LEN_DATA_MANUAL >= big1.boundary) { memoryError |= OVER_MONITOR; return; } memoryMsg2 = big1.memory; big1.stop = big1.write; big1.write = LEN_DATA_MANUAL; } else { memoryMsg2 = big1.memory + big1.write; big1.write = headNew; } *memoryMsg2++ = (TYPE_MANUAL | TYPE_TRG); // RecType *memoryMsg2++ = LEN_DATA_MANUAL-2; // RecLength *(U32 *)memoryMsg2 = timeStamp; // RecTime

Obr. 4.3 Píklad ukládání do bufferu

- 64 -


4.4.2 Vyhodnocování píznak perušení Pi každém perušení se poítá a vyhodnocuje Bus-Load a manuální trigger. Opuštní obsluhy perušení je možné jen po zpracování Bus-Loadu, manuálního triggeru a pouze tehdy, není-li nastaven žádný píznak perušení a to ani v adii perušení. Na zaátku obsluhy perušení se nejprve provede pípadná korekce asovae promnné, aby pi restartování nemohl as poskoit zpt a nulování registru pro generování Bus-Load perušení (po 1 ms). Další Bus-Load tedy nastane až za 1 ms od tohoto okamžiku. Následuje vytení perušovacího registru se zajištním pro ty bity, které se v tomto registru objeví jen jednou. Dále se provede test, jestli již není možné ukonit obsluhu perušení a to je možné jen, jestli již probhla obsluha všech požadavk, vždy Bus-Load a manuální trigger a v adii perušení není nastaven píznak dalšího perušení. Jestliže obsluha je provedena a v adii perušení eká nové perušení (teba jen Bus-Load), program se vrátí k nulování píznaku perušení. Následuje obsluha perušení od asovae. Je-li požadována, je aktualizován programový as a poítadlo tchto perušení (horních 16 bit asovae) pro správné složení asových znaek. Programový as tedy kvli jednoduchosti nebží úpln ist spojit - v nejhorším pípad skáe po 1 ms. Následuje již obsluha jednotlivých zdroj perušení. Tyto obsluhy jsou azeny podle své priority. Po provedení každé obsluhy se program vrátí zase zpt k vyhodnocení píznak perušení, aby napíklad rychlý CAN byl obsluhován prioritn a tato obsluha se nemohla nikde zpozdit. Pomocí jednoho píznaku je zajištno, že obsluha Bus-Loadu a manuálního triggeru se provede vždy, když se provádí obsluha perušení. Tyto dv innosti nemají svj píznak perušení, protože se provádjí pravideln s periodou 1 ms.

- 65 -


4.4.3 Funkce volané v perušení x ReceiveCAN() Tato funkce slouží pro píjem dat a detekci chyb na jedné ze tí sbrnic CAN. Nejprve je tedy teba nastavit patiné ukazatele na ten adi SJA1000, který má být obsloužen. Následuje vytení všech informací o pijímané zpráv. Následn probíhá vyhodnocení, co se má se zprávou s daným identifikátorem udlat. Zpráva mže signalizovat trigger, mže být urena pro záznam v logovacím nebo monitorovacím bufferu. Zpráva také nemusí mít nastaven žádný píznak, tyto zprávy jsou ureny k zapomenutí. V další ásti funkce se provede vlastní uložení zprávy do pamti a to bu do logovacího nebo do monitorovacího bufferu. Na závr, byl-li proveden píjem zprávy, program oznámí adii SJA1000, že zpráva byla petena. Jestliže se zpracovávala chyba, program vyresetuje adi SJA1000, což má za následek, že adi eká na klidový stav na sbrnici. Jestliže by adi neekal na klid na sbrnici, zaal by detekovat rzné chyby na sbrnici, podle toho co by si myslel, že má na sbrnici být. Protože je adi ve stavu „jen pro tení“, tak nemže sbrnici ovlivnit, tedy ani vyslat Error Frame. Jen pro testovací úely je na závr vyhodnocování, jestli nedochází v adii SJA1000 k petékání zpráv. x ReceiveCAN4() Tato ást kódu je v programu jen pro budoucí využití. V souasné dob jsou všechny innosti na tvrtém CANu zablokovány. Jestliže nkdy v budoucnu dojde k povolení vzniku perušení na tomto CANu, tak je zde pipravena funkce pro píjem zpráv (ne pro detekci chyb). Tato funkce je velice podobná pedchozí funkci pro píjem zpráv a detekci chyb na sbrnicích CAN. x ReceiveAnalog() Nejde zde o píjem dat z analogových vstup. Toto perušení je vygenerováno na závr každého DMA penosu a slouží mj. pro nové nastavení adie DMA. Tato funkce zajistí uložení bázové adresy bloku pamti, kam se práv dokonil DMA penos. Uloží také asovou znaku odpovídající tomuto perušení. Následuje

- 66 -


výpoet nové bázové adresy. Nová adresa je uložena do adie DMA a je spuštn nový DMA cyklus. Pomocí jednoho píznaku je také zajištno, že pi prvním DMA cyklu se nebude piítat adresa. První DMA cyklus se provede pi inicializaci, aby se vyzkoušelo, jestli DMA funguje. Také restartování programu zpsobí, že DMA buffer, kde k restartu došlo, bude poškozen, ale následující buffery již budou v poádku. Jsou zde také nastavovány píznaky: píznak, že adresa pro ukládání již petekla a píznak že nastalo toto perušení. Tyto píznaky jsou využity pi správ pamti. x ReceiveDigital() Funkce pro píjem dat z digitálních vstup je v zásad jednoduchá. Nejprve se data vytou z registru. Následuje vyhodnocení jestli tato data znamenají trigger. Jestliže nenastal trigger a nebo je vypnuté monitorování, tak dojde k zapomenutí tchto dat. V opaném pípad je vytvoen záznam, který je uložen do pamti. x ReceiveSensor() Data z teplomr jsou nejdíve vytena z registru. Jestliže se jedná o teplomr na kanále .10, jde o interní teplomr. Tato hodnota je uložena do interní promnné, pro budoucí poslání do displeje. Pomocí tohoto teplomru se také pedává informace o tom, jestli deska AD vstup nepestala fungovat (Watch-Dog). Proto pi každém píjmu údaje od interního teplomru, jsou nastaveny odpovídající promnné. Je také zajištno, že interní teplomr nelze vypnout. Hodnota z interního teplomru se neukládá do pamti. Pro hodnotu z ostatních teplomr je vytvoen záznam, který je následn uložen do pamti. x BusLoad() Tato funkce slouží pro výpoet Bus-Loadu a to jak monitorování jeho hodnoty, tak i pro výpoet pípadných trigger. Pro tyto dva výpoty se používají odlišné mechanismy, nebo monitorování se provádí po pravidelných intervalech (periodicky), kdežto výpoet trigger se provádí pro asový interval od daného asu zpt. Pro výpoet triggeru je tedy teba v pamti udržovat poty penesených bit

- 67 -


v minulosti. Je proto nadefinován kruhový buffer. Výpoet obou hodnot je založen na poítadlech pijatých bit - každá pijatá zpráva je pepoítána na bity, a o tuto hodnotu je patin zvýšeno dané poítadlo. Hodnota tohoto poítadla je poté podlena asem a vynásobena patinou konstantou. Jako první se však v této funkci provede test, jestli je funkce volána v dané milisekund (nejmenší rozlišovací interval pro výpoet Bus-Loadu). Jestliže ne, je funkce busLoad() ukonena, nebo výpoet nemá v tomto ase smysl. Dále se provede zasynchronizování poítadla milisekund na aktuální as. Toto se provádí jako korekce na pípadné vynechané milisekundy. Minimáln by se zde však mla napoítat alespo jedna milisekunda. Pi tomto poítání milisekund se také aktualizuje sumární promnná pro výpoet trigger a to pomocí kruhového bufferu, kde jsou zaznamenány poty penesených bit v uplynulých milisekundách. Výpoet monitorovaného Bus-Loadu je vcelku jednoduchý. Nejprve se vyhodnotí, jestli už uplynul daný interval. Poté je vypotena hodnota Bus-Loadu a to podlením asovým intervalem a vynásobením konstantou. Následuje vynulování poítadel, aby byla pipravena pro další mení. Z vypotené hodnoty se vytvoí záznam, který je poté uložen do pamti. Výpoet trigger od Bus-Loadu je podobný. Jako vstup se zde však nepoužívá poítadlo, ale vypotená hodnota, která vznikla pi zpracovávání kruhového bufferu. Tato hodnota udává poet pijatých bit za uplynulý asový interval. Tento výpoet se však provádí vždy (na rozdíl od monitorování Bus-Loadu). Následuje opt podlení tímto daným asovým intervalem a vynásobení konstantou. Nyní se vyhodnotí, jestli vypotená hodnota Bus-Loadu je vtší než nastavená triggerovací úrove. Jestli ano, provede se vytvoení a uložení záznamu do pamti. Je teba poznamenat, že tyto výpoty se provádjí pro každý kanál CAN samostatn. x Manual() Tato funkce zajiš uje vyhodnocování manuálního triggeru. Požadavek na manuální trigger vstupuje do systému od displeje. Systém nastaví píznak požadavku. Vlastní zpracování se však provádí až zde, tj v perušovací rutin. Zpracování se provádí takto, protože je poteba, aby se do pamti zapisovalo pouze

- 68 -


v perušení (perušení nelze perušit). Odezva na zadání požadavku je také dostatená, nebo nové perušení nastane nejdéle za 1ms od pedchozího. Jako první se tedy zde vyhodnotí, je-li nastaven požadavek manuálního triggeru. Jestliže ne, je funkce manual() ukonena. Jinak se vytvoí záznam, který se ihned uloží do pamti.

4.5 Ovení funkce V diplomové práci se mi nepodailo rozchodit všechny zde popisované funkce. U analogov digitální karty mám problém s DMA penosy (alokace konkrétní pamti pro tyto penosy) ze dvou analogov digitálních vstup. Další neodladná funkce je v komunikaci s displejem, kde se mi nepodailo v PharLapu nakonfigurovat RS232 a realtime výstup z CAN Dataloggeru mám omezený jen na vysílání zpráv, které picházejí ze sbrnic CAN.

- 69 -


Kapitola

5 5. Závrené zhodnocení

- 70 -


Celou diplomovou práci je možné rozdlit do dvou hlavních ástí: x

První ást diplomové práce se zabývá popisem real-time operaního systému PharLap. Jsou zde popsány jednotlivé kroky zavádní real-time ETS jádra do cílového embedded systému (inicializace: jádra, ETS monitoru, atd), poátení stavy systému, popsána aplikaní prostedí, rzné režimy naítání systému, zpsoby komunikace pi ladní, provozní a ETS knihovny, zpsob zpracování perušení a mnoho jiných.

x

V druhé ásti se zabývám stavbou a hlavn popisem programu, jak by ml vypadat. Tento popis je více zamen na prchod programem, vysvtlení jednotlivých funkcí a nástinem dalších zatím nedoprogramovaných ástí programu.

Do této doby jsem se s RTOS systémem PharLap nesetkal, byla to pro m výzva, a zaínal jsem tedy proto od „nuly“. Programoval jsem trial verzi tohoto systému, což sebou neslo jistá omezení. Tyto omezení se netýkají funknosti, ale asu. (Po instalaci programu PharLap, máte ti msíce na práci v Microsoft Visual C++, poté dojde k zablokování a vy musíte provést reinstalaci systému Windows – image disku ped instalací nestaí a jeden msíc na vývoj jednoho projektu - programu, poté si musíte založit nový projekt.)

Protože jsem ml ze zaátku velké problémy s rozchozením RTOS systému PharLap a poté se pidaly další problémy s rozchozením pidaných mících karet, které byly zapojeny do vyvíjecího testovacího poítae (u pvodního systému pestal fungovat IDE kanál). Pi pokusech o komunikaci s mící kartou na vývojovém poítai, jsem ml problémy s komunikací. Nevdl jsem, jestli mám špatn nastavený RTOS PharLap (neml jsem s tímto žádné zkušenosti) nebo špatn naprogramovaný program pro komunikaci s kartou. Bohužel to nebyla ani jedna z tchto dvou možností, ale až po dlouhé dob se pišlo na to (po vyzkoušení dalších velmi mnoha možností), že chyba byla mezi komunikací karty poítaem. Tento problém byl na sbrnici ISA, kde ho nikdo neekal, protože na této sbrnici, hned vedle, bžela grafická karta bez sebe menšího problému. Problém byl vyešen sníženým taktu této sbrnice.

- 71 -


Program a jeho jednotlivé funkce jsou zde popsány velmi podrobn proto, aby mj následovník ml co možná nejmenší problémy s pochopením jeho funkce a pokraováním v zapoatém vývoji. Budu se ješt snažit odladit/doprogramovat nkteré neodladné a nefunkní ásti programu do Státní závrené zkoušky.

- 72 -


Kapitola

6 6. Použitá literatura a pílohy

- 73 -


6.1 Seznam literatury a použitých odkaz [1]

Ardence – PharLap Manuals, [online] http://www.ardence.com

[2]

dataPartner - PharLap, [online] http://www.datapartner.cz

[3]

PC/104, [online] www.pc104.org

[4]

Herout, P Uebnice jazyka C, 3. vyd., Kopp 2001

[5]

Haasz, V., Roztoil, J., Novák, J. íslicové mící systémy, vydavatelství VUT

[6]

CAN Specification 2.0, Bosch 1991

[7]

Skrbek, M. Analysis software User manual, rev 1.0 2000

[8] Fried, T. Firmware, rev 1.0 2000 [9]

Novák, J. AD Board, rev 1.0 2000

[10] Novák, J. CAN board manual, rev 1.0 2000 [11] Novák, J. Data Logger unit user manual, rev 1.0 2000 [12] Novák, J. Data Logger display communication manual, rev 1.0 2000 [13] Novák, J. Interface Board manual, rev 1.0 2000 [14] Novák, J. DataFileSpec12, rev 1.3 2000

- 74 -

Analyzátor vozidlových datových komunikací

Recommend Documents