a microchip tcp ip stack implementációjának alkalmazása a

A Microchip TCP/IP Stack implementációjánakalkalmazása a gyakorlatban

Ivanov Péter

2004. május 18.

i

Tartalomjegyzék

1. Bevezeto 11.1. Köszönetnyilvánítás . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

2. Soros vonal 3

3. A TCP/IP Stack felépítése 43.1. A Stack rétegei . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

4. User Datagram Protocol (UDP) 7

5. A TCP/IP Stack konfigurálása 9

6. A TCP/IP Stack moduljai 136.1. Address Resolution Protocol modul . . . . . . . . . . . . . . . . . . . 14

6.1.1. ARP funkciók . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146.1.2. ARPTask funkciók . . . . . . . . . . . . . . . . . . . . . . . . . 16

6.2. User Datagram Protocol (UDP) modul . . . . . . . . . . . . . . . . . . 176.3. Stack Manager modul . . . . . . . . . . . . . . . . . . . . . . . . . . . 276.4. A soros-UDP átalakító modul . . . . . . . . . . . . . . . . . . . . . . . 276.5. HTTP szerver modul . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

6.5.1. Dinamikus honlap generálás . . . . . . . . . . . . . . . . . . . 356.5.2. HTTP CGI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

6.6. Microchip fájlrendszer (MPFS) . . . . . . . . . . . . . . . . . . . . . . 396.6.1. MPFS kép készítése . . . . . . . . . . . . . . . . . . . . . . . . . 406.6.2. MPFS könyvtár . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

6.7. FTP szerver modul . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 416.7.1. MPFS kép feltöltése FTP kliens segítségével . . . . . . . . . . . 42

7. Hardver 447.1. Alkatrészek . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

7.1.1. PIC18F452 mikrovezérlo . . . . . . . . . . . . . . . . . . . . . . 447.1.2. RTL8019AS ethernet vezérlo . . . . . . . . . . . . . . . . . . . 487.1.3. 24LC256 típusú soros EEPROM . . . . . . . . . . . . . . . . . . 487.1.4. MAX232A soros vonali illeszto . . . . . . . . . . . . . . . . . . 49

ii

8. Az eszköz használata és tesztelése 508.1. Az eszköz használata . . . . . . . . . . . . . . . . . . . . . . . . . . . . 508.2. Konfigurálás böngészoprogrammal . . . . . . . . . . . . . . . . . . . . 51

8.2.1. Hálózat beállítása . . . . . . . . . . . . . . . . . . . . . . . . . . 518.2.2. Soros vonal beállítása . . . . . . . . . . . . . . . . . . . . . . . 538.2.3. Statisztika . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

8.3. Az eszköz tesztelése . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

iii

Ábrák jegyzéke

1.1. A rendszer blokkvázlata . . . . . . . . . . . . . . . . . . . . . . . . . . 1

2.1. Egy bájt átvitele soros vonalon . . . . . . . . . . . . . . . . . . . . . . 3

3.1. A TCP/IP referencia modell rétegei . . . . . . . . . . . . . . . . . . . . 43.2. A referencia modell és a Microchip TCP/IP Stack rétegei . . . . . . . . 5

4.1. UDP csomag felépítése . . . . . . . . . . . . . . . . . . . . . . . . . . . 74.2. Az elo-fejléc felépítése . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

6.1. A Stack Manager algoritmusának folyamatábrája . . . . . . . . . . . . 286.2. A Serial2UDP_GetSerialData függvény folyamatábrája . . . . . . . . 316.3. A Serial2UDP_ProcessUDPData függvény folyamatábrája . . . . . . 326.4. Urlapok kezelése . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 386.5. MPFS képfájl felépítése . . . . . . . . . . . . . . . . . . . . . . . . . . . 396.6. MPFS FAT bejegyzés felépítése . . . . . . . . . . . . . . . . . . . . . . 406.7. MPFS adatblokk felépítése . . . . . . . . . . . . . . . . . . . . . . . . . 406.8. MPFS képfájl feltöltése FTP kliens segítségével . . . . . . . . . . . . . 43

7.1. Soros vonali illeszto és tápfeszültség stabilizátor kapcsolási rajza . . 457.2. A PIC18F452 típusú mikrovezérlo lábkiosztása . . . . . . . . . . . . . 467.3. A 24LC256 típusú soros EEPROM lábkiosztása . . . . . . . . . . . . . 497.4. A MAX232 típusú soros vonali illeszto lábkiosztása . . . . . . . . . . 49

8.1. A doboz oldal- és elölnézete . . . . . . . . . . . . . . . . . . . . . . . . 508.2. Az eszköz használata . . . . . . . . . . . . . . . . . . . . . . . . . . . . 518.3. Konfigurálás böngészoprogrammal: index . . . . . . . . . . . . . . . . 528.4. Hálózat beállítása böngészoprogrammal . . . . . . . . . . . . . . . . . 528.5. Soros vonal beállítása böngészoprogrammal . . . . . . . . . . . . . . 538.6. Statisztika megtekintése böngészoprogrammal . . . . . . . . . . . . . 548.7. Az eszköz tesztelése . . . . . . . . . . . . . . . . . . . . . . . . . . . . 548.8. Az UDP test program . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

iv

Táblázatok jegyzéke

5.1 Konfigurációs definíciók ill. változók . . . . . . . . . . . . . . . . . . . 12

6.1 TCP/IP Stack moduljai . . . . . . . . . . . . . . . . . . . . . . . . . . . 146.2. A soros-UDP átalakító modul konfigurációs változói . . . . . . . . . 296.3. A soros-UDP átalakító modul belso változói . . . . . . . . . . . . . . 296.4. A soros-UDP modul átalakító állapotai . . . . . . . . . . . . . . . . . . 33

1

1. fejezet

Bevezeto

Manapság az ethernet hálózat elterjedését láthatjuk a hétköznapi használatban ésaz iparban egyaránt. A csavart érpáros kábelek nagy távolságra vezethetok, olcsók,könnyen szerelhetok és az árnyékolatlan kábelek (UTP) is relatíve érzéketlenek azelektromos zavarokra, de ipari alkalmazásban általában árnyékolt kábeleket (STP)használnak.

A most bemutatásra kerülo rendszerrel egyszeruen és gyorsan képessé tehetjükPIC mikrokontrolleres alkalmazásunkat, hogy kommunikáljon az intraneten vagyinterneten. E szakdolgozatban egy a valóságban is felhasználható alkalmazást mu-tatok be, hogyan illeszthetjük a soros vonalon kommunikáló régebbi fejlesztésueszközünket ethernet hálózathoz. A rendszer leegyszerusített blokkvázlata az 1.1.ábrán látható.

1.1. ábra. A rendszer blokkvázlata

A Microchip kifejlesztette a PIC18-as mikrokontroller családhoz a TCP/IP Stack-etés egy komplett web szervert. Fejlesztéseit szabadon hozzáférhetové tette és letölt-heto az internetrol. Ezeket a forráskódokat használtam fel.

A programcsomaggal egy HTTP szervert építhetünk, aminek honlapját FTP-nfrissíthetjük. Szükség van egy PIC 18-as mikrovezérlore, egy NIC-re (például Realtek8019AS). Kell még egy C fordító, a program lefordításához. Én a PIC C18 demó verzi-óját használtam. Érdemes letölteni az MPLAB legfrissebb verzióját. Ez egy integrált

2

fejlesztoi környezet (IDE) amiben szerkeszthetjük a forrásfájlokat, lefordíthatjuk aprogramot és fel is tölthetjük a mikrovezérlobe. Kell még egy PIC programozó is. Énaz ICD2 nevezetu programozó és nyomköveto eszközt használtam.

A szögletes zárójelben levo számokkal mindig az irodalomjegyzékben szereplodokumentumokra hivatkozok.

1.1. Köszönetnyilvánítás

Ezúton szeretném megköszönni Dr. Kónya László tanár úrnak és KolingerAttilának a segítséget és a fejlesztéshez nélkülözhetetlen eszközöket.

3

2. fejezet

Soros vonal

Elsosorban az RS-232C szabványról lesz szó ebben a fejezetben. Ez az adatátviteliforma széles körben elterjedt és még most is nagyon sok eszköz használja az iparbanés a számítástechnikában ezt a módszert.

Az RS232 hátrányai közé tartozik, hogy „aszimetrikus”, tehát közös a föld, ezértzaj érzékeny és csak kis távolságra vezetheto. Nagyobb távolságok áthidalására azRS-422 ill. RS-485 szabványú adatátvitel használható.

Az átvitel aszinkron, full duplex és a bájtok átvitele mindig egy start bit elküldé-sével kezdodik, ezt követi 5–9 darab adatbit végül egy, másfél vagy ketto stop bit. Akilencedik bit lehet paritás bit is vagy a cél eszköz megcímzésére használhatjuk. Akilencedik bitet alapesetben RS-232C kapcsolatnál címzésre használni nem lehet (delehet például az RS-422-nél és RS-485-nél).

A legelterjedtebb a „8n1” típusú átvitel, ahol 8 adatbit egy stop bit küldéseill. fogadása lehetséges, paritás nélkül. Az általam elkészített program is ebben aformátumban kezeli az adatokat.

Az adatátviteli sebesség 75, 150, . . . , 2400, 4800, 9600, 19200, 38400, 57600,. . . baud lehet. A baud az átvitt jel értékében történo változások száma egy má-sodperc alatt. Tehát a sebesség megadásánál a baud mértékegység nem egyezik mega bit/másodperccel, mert az utóbbiba nem értendo bele a start-, stop- és paritás bitekátvitele.

Egy bájt (0xC8) átvitele látható a 2.1. ábrán (TTL szintuek a jelek).

2.1. ábra. Egy bájt átvitele soros vonalon

4

3. fejezet

A TCP/IP Stack felépítése

Számos TCP/IP implementáció követi a „TCP/IP referencia modell” nevu szoft-ver architektúrát. Azok a programok, amik erre a modellre alapulnak több rétegrevannak osztva, ezek a rétegek egymásra épülnek1 és minden réteg egy vagy többalatta lévo réteggel kommunikál. A TCP/IP referencia modell a 3.1. ábrán látható.

3.1. ábra. A TCP/IP referencia modell rétegei

A TCP/IP rétegek „aktívak”, vagyis nem csak akkor muködnek, ha kérés érkezikegy szolgáltatáshoz, hanem akkor is, idotúllépés történt vagy egy új csomag érkezett.

Egy olyan rendszer, ahol sok adat- és programmemória áll rendelkezésre könnyenteljesíti a kéréseket. Egy multitaszkos operációs rendszer extra képességei lehetovéteszik, hogy az implementáció moduláris legyen. A program viszont bonyolult lesz,ha csak egy 8 bites mikrovezérlo áll rendelkezésre néhány száz bájt RAM-mal és kor-látozott programmemóriával. Továbbá, egy multitaszkos operációs rendszer nélkülsok idot kell arra fordítani a programozás során, hogy a Stack független maradjon afo alkalmazástól.

Relatíve könnyu elkészíteni és helytakarékos az a TCP/IP Stack, amely bele vanintegrálva a fo alkalmazásba. De sok probléma léphet fel, amikor újabb funkciókatszeretnénk a programhoz hozzáadni.

1Az egymásra épülést angolul a „stacked” szóval fejezik ki, ezért hívják TCP/IP Stack-nek.

5

Ez a TCP/IP Stack moduláris, C programozási nyelven íródott és a Microchip C18és a HiTech PICC 18 fordítókkal is lefordítható. A forrásfájl automatikusan eldönti,hogy milyen fordítóval szeretnénk fordítani. A két fordító közötti különbségekboleredo problémákat a compiler.h fájlban levo definíciókkal küszöböljük ki. Ez aTCP/IP Stack csak PIC 18-as mikrovezérlokön fut.

3.1. A Stack rétegei

A 3.2 ábrán is látható, hogy a Microchip TCP/IP Stack is különbözo rétegekre vanosztva. A kód úgy lett megírva, hogy minden réteg külön forrásfájlban van, míg azAPI2 külön fejlécfájlban van.

3.2. ábra. A TCP/IP referencia modell és a Microchip TCP/IP Stack rétegeinek össze-hasonlítása

Ellentétben a referencia modellel, a Microchip TCP/IP Stack-ben egyes rétegeknem csak a közvetlenül alatta levo réteget érik el. A legnagyobb különbség a hagyo-mányos TCP/IP Stack implementációtól két új modul: StackTask és az ARPTask. AStackTask vezérli a Stack összes moduljának muködését az ARPTask pedig az ARPréteg szolgáltatásait valósítja meg.

Ez a Stack az általánosan ismert kooperatív multitaszk technikát alkalmazza,hogy független legyen a fo alkalmazástól. Egy kooperatív multitaszkos rendszer-ben több taszk muködik, minden taszk végrehajt egy feladatrészt, majd a vezérléstvisszaadja és a következo taszk fut. Ebben az értelmezésben a StackTask és az ARP-Task egy-egy kooperatív taszk. A foprogramba vagy az operációs rendszerbe is lehetimplementálni a kooperatív – vagy más típusú – multitaszkot megvalósító kódot.

A Stack úgy lett megtervezve, hogy független legyen bármilyen operációs rend-szertol, vagyis saját kooperatív multitaszk rendszere van. Ennek eredményekénthasználható bármilyen rendszerben függetlenül attól, hogy használ-e multitaszkosoperációs rendszert vagy sem. Azonban, ha a saját alkalmazásunk használja ezt a

2Application Programming Interfaces, vagyis a felhasználói program interfész.

6

TCP/IP Stack-et, alkalmaznunk kell a kooperatív multitaszk technikát a saját taszk-jaink megírásakor. Ez elérheto úgy is, hogy a feladatot több taszkra osztjuk vagy afeladatot egy FSM-nek (Finite State Machine, Véges Állapotú Automata) továbbítjukami a feladatot sok kis részfeladatra bontja és egymás után futtatja le oket. A HTTPszerver az utóbbi megoldást használja.

Jegyezzük meg, hogy ebben a TCP/IP Stack-ben nincs implementálva az összesolyan modul, ami egy átlagos TCP/IP Stack-ben implementálva van, de ha szük-ség van egy olyan funkcióra, ami nincs implementálva, bármikor megírható különtaszkként vagy modulként.

7

4. fejezet

User Datagram Protocol (UDP)

Az RFC 768-as [2] dokumentumban található az UDP protokoll leírása. Ez aprotokoll az Internet Protocol-ra (IP) épül. Elonye, hogy a programok nagyon egy-szeruen küldhetnek és fogadhatnak üzeneteket, de nincs garantálva, hogy az üzenetnem veszik el ill. nem duplázódik. Azok az alkalmazások amelyeknél adatfolyamokmegbízható továbbítására van szükség, a Transmission Control Protocol-t (TCP)használják.

4.1. ábra. UDP csomag felépítése

Az UDP csomagok felépítése a 4.1. ábrán látható.A forrás port opcionális mezo, akkor érdemes használni, ha a csomagot küldo

folyamat választ vár. Ha nincs használva, nullát kell a helyére írni.A cél port a cél címen belül egy folyamatot vagy programrészt jelent, de lehet más

jelentése is.A hossz a csomag oktetjeinek számát mutatja meg, beleértve a fejlécet és az ada-

tokat is. Tehát a legkisebb érték, amit felvehet: nyolc.Az ellenorzo összeg az IP fejlécbol készült „elo-fejléc”, az UDP fejléc és az adat egyes

komplemense 16 bitre kiegészítve. Azért hívják elo-fejlécnek, mert az IP fejlécbolmásolódnak az adatok.

Az elo-fejléc (4.2. ábra) az UDP fejléc elott van és tartalmazza a forrás- és célcímet,protokoll típusát és az UDP csomag hosszát. Ez az információ véd az eltévedt cso-magok ellen. Az ellenorzo összeg számítása hasonlít a TCP-ben használt ellenorzoösszeg számításhoz.

Ha a kiszámított ellenorzo összeg nulla, akkor az összeg egyes komplemense leszelküldve (FFFFh). Ha az ellenorzo összegként nullát küld a forrás, az azt jelenti, hogy

8

4.2. ábra. Az elo-fejléc felépítése

a küldo nem számolt összeget. Nyomkövetéskor alkalmazható vagy, ha a felsobbszintu protokollok nem használják ezt az összeget. Ebben a TCP/IP Stack-ben azellenorzo összeg számítás nincs implementálva.

Az UDP modulnak ismernie kell a forrás és cél internet címét és a protokolltípusát.

Ezt a protokollt használják az internetes név szerverek (DNS) és Trivial FileTransfer Protocol (TFTP).

Ha az Internet Protocol-on belül használjuk az UDP-t, akkor az a 17-es (oktálisan21) számú protokoll.

9

5. fejezet

A TCP/IP Stack konfigurálása

Ez a kooperatív multitaszk rendszer lehetové teszi, hogy a felhasználói alkalma-zás saját taszkokat futtasson. Eközben a TCP/IP Stack-kel nem is kell foglalkoznia.Ehhez természetesen az kell, hogy a felhasználó úgy írja meg programját, hogy akooperatív multitaszkos rendszerben muködjön. Az egyszeru konfigurálás érde-kében a program C definíciókat használ. A legtöbb paraméter engedélyezése, tiltásavagy beállítása a StackTsk.h fejléc fájlban lehetséges. Azok a paraméterek, amelyekmás fájlban találhatóak, azoknak zárójelben megadom a fájl nevét. Ha valamelyikparamétert változtattuk, a projektet – vagy egyes részeit – újra kell fordítani1.

Azonosító Értékek Használ MegjegyzésCLOCK_FREQ (compiler.h) Órajel

frekv.(Hz)

Tick.c Definiálja a rendszer óra-jel frekvenciáját, hogyki lehessen számolni azidozíto számláló értékét.

TICKS_PER_SECONDS 10-255 Tick.c Egy másodperc hánytaktusból áll.

TICK_PRESCALE_VALUE 2, 4, 8,16, 32, 64,128, 256

Tick.c Idozítéshez milyen elo-osztó legyen beállítva.

MPFS_USE_PGRM - MPFS.c Ha a programmemóriátakarjuk használni adat-tárolásra.

MPFS_USE_EEPROM - MPFS.c Ha külso sorosEEPROM-ot akarunkadattárolásra használni.

MPFS_RESERVE_BLOCK 0-255 MPFS.c Az MPFS fájlrendszerelott fenntartott bájtokszáma.

EEPROM_CONTROL Külsomem.kódja

MPFS.c Hogy meg tudjuk cí-mezni a külso EEPROM-ot.

1Az MPLAB fejlesztoi környezet érzékeli a változtatásokat és kezeli a függoségeket, csak aztfordítja le, ami szükséges.

10

Azonosító Értékek Használ MegjegyzésSTACK_USE_ICMP - StackTsk.c Ha nincs szükség

ICMP-re, ne definiáljuk.STACK_USE_SLIP - SLIP.c Ha nincs szükség SLIP-

re ne definiáljuk.STACK_USE_IP_GLEANING - StackTsk.c Ha nincs szükség IP

Gleaning-re ne definiál-juk.

STACK_USE_DHCP - DHCP.c,

StackTsk.c

Ha nincs szükség DHCP-re ne definiáljuk.

STACK_USE_FTP_SERVER - FTP.c Ha nincs szükség FTPszerverre ne definiáljuk.

STACK_USE_TCP - TCP.c,

StackTsk.c

Ha nincs szükség TCP-re ne definiáljuk. Auto-matikusan engedélyezi,ha valamelyik modulnakszüksége van TCP-re.

STACK_USE_UDP - UDP.c,

StackTsk.c

Ha nincs szükség UDP-re ne definiáljuk. Auto-matikusan engedélyezi,ha valamelyik modulnakszüksége van UDP-re.

STACK_CLIENT_MODE - ARP.c,

TCP.c

Ha definiáljuk a kliensmódú függvények enge-délyezodnek.

TCP_NO_WAIT_FOR_ACK - TCP.c A TCP várjon vagy ne azACK-re a következo cso-mag küldése elott.

MY_DEFAULT_IP_ADDR_BYTE? 0-255 felh. alk. Alap IP: 10.10.5.15MY_DEFAULT_MASK_BYTE? 0-255 felh. alk. Alap netmaszk:

255.255.255.0MY_DEFAULT_GATE_BYTE? 0-255 felh. alk. Alap átjáró: 10.10.5.15MY_DEFAULT_MAC_BYTE? 0-255 felh. alk. Alap MAC:

00:04:163:00:00:00MY_IP_BYTE? 0-255 felh. alk. Aktuális IP. Ha DHCP

engedélyezett akkor aszerver által adott konfi-guráció.

MY_MASK_BYTE? 0-255 felh. alk. Aktuális netmaszk.MY_GATE_BYTE? 0-255 felh. alk. Aktuális átjáró.MY_MAC_BYTE? 0-255 felh. alk. Aktuális MAC.

11

Azonosító Értékek Használ MegjegyzésMAX_SOCKETS 1-253 TCP.c Definiálja, hogy hány

TCP socket használható(a RAM mennyiségétolfügg). Fordítás köz-ben ellenorzi, hogyelegendo-e a TCP mo-duloknak a megadottérték.

MAX_UDP_SOCKETS 1-254 UDP.c Definiálja, hogy hányUDP socket használható(a RAM mennyiségétolfügg). Fordítás köz-ben ellenorzi, hogyelegendo-e a UDP mo-duloknak a megadottérték.

MAC_TX_BUFFER_SIZE 201-1500 TCP.c,

MAC.c

Definiálja a küldo pufferméretét.

MAX_TX_BUFFER_COUNT 1-255 MAC.c Definiálja a küldo puffe-rek számát.

MAX_HTTP_CONNECTIONS 1-255 HTTP.c Definiálja az egyszerrefenntartható HTTP kap-csolatok számát.

MPFS_WRITE_PAGE_SIZE

(MPFS.h)1-255 MPFS.c Definiálja a lapméretet

az MPFS fájlrendszer-hez.

FTP_USER_NAME_LEN (FTP.h) 1-31 FTP.c Definiálja az FTP fel-használónév maximálishosszát.

MAX_HTTP_ARGS (HTTP.c) 1-31 HTTP.c Definiálja az urlapok me-zoinek maximális szá-mát, beleértve a mezo ne-vét is.

MAX_HTML_CMD_LEN (HTTP.c) 1-128 HTTP.c Definiálja az urlappal át-adható sztring maximá-lis hosszát.

STACK_USE_SER2UDP - ser2udp.c Ha nincs szükség asoros-UDP átalakító mo-dulra ne definiáljuk.

TARGET_DEFAULT_

IP_ADDR_BYTE? (ser2udp.h0-255 ser2udp.c Alap cél IP cím: 10.10.5.5.

DEFAULT_TARGET_PORT

(ser2udp.h1-65535 ser2udp.c Alap cél port: 2222.

12

Azonosító Értékek Használ MegjegyzésDEFAULT_LOCAL_PORT

(ser2udp.h1-65535 ser2udp.c Alap forrás port: 2221.

INITWAIT_SEC (ser2udp.h 0-42949672

ser2udp.c ARP kérés elotti várako-zás ideje másodpercben.Alap: 4.

TIMEOUT_SEC (ser2udp.h 0-42949672

ser2udp.c ARP kérés után hánymásodpercig vár a vá-laszra. Alap: 4.

SER2UDP_USE_INTERRUPT

(ser2udp.h- ser2udp.c A soros adatok vételé-

hez használjon-e meg-szakítást a modul.

5.1. táblázat: Konfigurációs definíciók ill. változók

A fejlesztés során egy projektet érdemes használni. Projekt fájlból is van eloreelkészített a programcsomagban. Én az MPNICEE.pjt fájlt használtam. Ezt a fájltakkor érdemes használni, ha a Microchip C18 fordítót Realtek NIC-et és külso sorosEEPROM-ot használunk, továbbá szükségünk van HTTP, FTP szerverre és ICMP-re.Ugyanis ezeket tudja alapból az a program, amit ezzel a projekt fájllal fordítunk.Fontos megjegyezni, hogy a projekt fájlokban is lehet definíciókat megadni.

13

6. fejezet

A TCP/IP Stack moduljai

A moduláris felépítés miatt könnyen beállíthajuk, hogy milyen szolgáltatásokravan szükségünk. Egy modul letiltása csak annyiból áll, hogy a megfelelo definíció eléegy megjegyzés jelet teszünk és a forrásfájlokat eltávolítjuk a projektbol. A TCP/IPStack moduljainak rövid áttekintése:

Modul Fájl szükséges LeírásMAC MAC.c, Delay.c Közeghozzáférési rétegSLIP SLIP.c Közeghozzáférési réteg SLIP-

hezARP ARP.c, ARPTsk.c, MAC.c

vagy SLIP.c, Helpers.cAddress Resolution Protocol

IP IP.c, MAC.c vagy SLIP.c,Helpers.c

Internet Protocol

ICMP ICMP.c, StackTsk.c,

IP.c, MAC.c vagy SLIP.c,Helpers.c

Internet Control Message Pro-tocol

TCP StackTsk.c, TCP.c IP.c,

MAC.c vagy SLIP.c,

Helpers.c, Tick.c

Transmission Control Protocol

UDP StackTsk.c, UDP.c, IP.c,

MAC.c vagy SLIP.c,

Helpers.c

User Datagram Protocol

Stack Manager StackTsk.c, TCP.c, IP.c,

ICMP.c, ARPTsk.c, ARP.c,

MAC.c vagy SLIP.c, Tick.c,Helpers.c

Stack Manager (StackTask), amivezérli a TCP/IP Stack modul-jait.

HTTP Server HTTP.c, TCP.c, IP.c,

MAC.c vagy SLIP.c,

Helpers.c, Tick.c,

MPFS.c, XEEPROM.c

HyperText Transfer Protocolszerver

DHCP Client DHCP.c, UDP.c, IP.c,

MAC.c, Helpers.c, Tick.c

Dynamic Host ConfigurationProtocol

14

Modul Fájl szükséges LeírásIP Gleaning StackTsk.c, ARP.c,

ARPTsk.c, ICMP.c, MAC.c

vagy SLIP.c

IP cím konfiguráláshoz

FTP Server FTP.c, TCP.c, IP.c,

MAC.c vagy SLIP.cFile Transfer Protocol szerver

Serial2UDP ARP.c, UDP.c, MAC.c vagySLIP.c

Soros-UDP átalakító

6.1. táblázat: TCP/IP Stack moduljai

Most a soros-UDP átalakító modul által használt modulok részletes leírása kö-vetkezik. Az itt nem tárgyalt modulok (MAC, SLIP, IP, ICMP, TCP, DHCP) angolnyelvu leírása az AN833-as [1] dokumentumban található.

6.1. Address Resolution Protocol modul

Az ARP modul gondoskodik arról, hogy az IP címekbol megtudjuk, hogy milyenhardveres cím (MAC cím) tartozik hozzá és hogy más eszközök az IP címünkettudva, megkapják a MAC címünket.

Az Microchip TCP/IP Stack-jének ARP rétege két modulból áll: ARP.c és ARP-Task.c. Az ARP modulban (ARP.c) az ARP alapveto függvényeit definiálja. Az ARP-Task – ami az ARPTsk.c fájlban található – ezeket a függvényeket felhasználva va-lósítja meg az ARP szolgáltatást. Az ARPTask válaszol az ARP kérésekre és egyegyszintu tárban tárolja a más hosztok ARP válaszát. Az ARPTask modulban nincsmegvalósítva az idotúllépés kezelése, ezt a felsobb szintu modulokban kell megol-dani.

Az ARPTask kétféle módban muködhet: szerver illetve szerver/kliens. A szer-ver/kliens módban lehetséges ARP kérések generálása. Szerver módban ez a kódrésznincs befordítva. Általában az alkalmazások szerver módban futnak és érdemes isszerver módba fordítani, a kód méretének csökkentése érdekében. Továbbá szervermódban nem kerül lefoglalásra az egyszintu tár és ezzel RAM területet takaríthatunkmeg. Ha a STACK_CLIENT_MODE definiálva van szerver/kliens módban fog muködniaz ARPTask modul. A soros-UDP konverter szerver/kliens módban használja azARP modult.

6.1.1. ARP funkciók

ARPIsTxReady

Ez egy makró ami megállapítja, hogy adatok küldése lehetséges-e.Szintaxis: ARPIsTXReady()Paraméter: NincsVisszatérési érték: IGAZ: Ha legalább egy küldo puffer üres. HAMIS: Nincs üresküldo puffer.Elofeltétel: Nincs

15

Mellékhatás: NincsMegjegyzés: Ez csak egy makródefiníció a MACIsTxReady függvényre.Példa:

// Ha a küldő puffer üres, elküldünk egy ARP csomagot

if ( ARPIsTxReady() )

{

// ARP csomag küldése

ARPPut(&RemoteNode, ARP_REPLY);

}

ARPGet

Ez a funkció beolvas egy ARP csomagot és visszatéréskor megadja a szükségesinformációkat a csomagról.Szintaxis: BOOL ARPGet(NODE_INFO *remote, BYTE *opCode)Paraméter: remote [kimeno] A távoli eszközhöz tartozó információk, a MAC és az IPcím.opCode [kimeno] ARP kód. A paraméter lehetséges értékei a következok:ARP_REPLY Egy ARP válasz csomag érkezettARP_REQUEST Egy ARP kérés csomag érkezettARP_UNKNOWN Egy ismeretlen ARP csomag érkezett

Visszatérési érték: IGAZ: Ha egy érvényes ARP csomag érkezett és az a mi eszkö-zünknek van címezve. HAMIS: Ha ismeretlen ARP kódja van a csomagnak vagynem nekünk van címezve a csomag.Elofeltétel: MACGetHeader már meg volt hívva és a kapott MAC csomag típusaMAC_ARP

Mellékhatás: NincsMegjegyzés: Ez a funkció azt feltételezi, hogy az aktív pufferben van egy ARP cso-mag és a hozzáférési mutató az ARP csomag elejére mutat. Általában a magasabbszintu rétegek ellenorzik a MAC puffert és csak akkor hívják ezt a függvényt, ha ARPcsomagot érzékeltek. Ez a funkció beolvassa az egész ARP csomagot és felszabadítjaaz aktív puffert.Példa:

// Ha MAC csomag érkezett...

if ( MACGetHeader(\&RemoteNode, \&PacketType) )

\{

// Ha ez egy ARP csomag, beolvassuk

if ( PacketType == MAC\_ARP )

\{

// Ez egy ARP csomag

ARPGet(\&RemoteNode, \&ARPCode);

...

16

ARPPut

Ez a funkció feltölti a MAC puffert egy érvényes ARP csomaggal.Szintaxis: void ARPPut(NODE_INFO *remote, BYTE opCode)Paraméter: remote [bemeno] A távoli eszköz adatai, mint a MAC és az IP címopCode [bemeno] ARP kód. Lehetséges értékei a következok:ARP_REPLY ARP válaszként küldi el a csomagotARP_REQUEST ARP kérésként küldi el a csomagot

Visszatérési érték: NincsElofeltétel: ARPIsTxReady == TRUEMellékhatás: NincsMegjegyzés: Felépíti az ARP csomagot és elküldi.Példa:

// Megnézzük, hogy küldő puffer elérhető-e


{

// Igen, elküldjük

ARPPut(&RemoteNode, ARP_REQUEST);

...

}

6.1.2. ARPTask funkciók

ARPInit

Ez a funkció inicializálja az ARPTask modult és elokészíti az ARP kérések küldé-sére és megválaszolására.Szintaxis: void ARPInit()Paraméter: NincsVisszatérési érték: NincsElofeltétel: NincsMellékhatás: NincsMegjegyzés: Szerver/kliens módban ez a funkció inicializálja az egyszintu tárolót.Példa:

// Initialize ARPTask

ARPInit();

...

ARPResolve

Ez a funkció egy ARP kérést küld egy távoli eszköznek.Szintaxis: void ARPResolve(IP_ADDR *IPAddr)Paraméter: IPAddr [bemeno] A távoli eszköz IP címe, aminek a MAC címét szeret-nénk tudni.Visszatérési érték: NincsElofeltétel: ARPIsTxReady == TRUE

17

Mellékhatás: NincsMegjegyzés: Ez a funkció csak szerver/kliens módban elérheto.Példa:

// Ellenőrizzük, hogy a küldő puffer elérhető-e


{

// ARP kérés küldése

ARPResolve(\&RemoteNodeIP);

...

}

ARPIsResolved

Ez a funkció ellenorzi a belso tárolót és visszatérési értékként megadja a cél hosztMAC címét.Szintaxis: BOOL ARPIsResolved(IP_ADDR *IPAddr, MAC_ADDR *MACAddr)Paraméter: IPAddr [bemeno] A távoli eszköz IP címe, aminek a MAC címét szeret-nénk tudni.MACAddr [kimeno] A puffer ami a távoli hoszt MAC címét fogja tárolni.Visszatérési érték: IGAZ: Ha egyezo IP cím van a belso tárolóban és az átmásolódotta MACAddr változóba. HAMIS: Ha nincs egyezo IP cím a belso tárolóban. Ilyenkora MACAddr értéke nem változik.Elofeltétel: NincsMellékhatás: A belso tárolóból az átmásolt adatok eltávolításra kerülnek.Megjegyzés: Az ARPTask csak egyszintu tárolóval dolgozik, ezért a felsobb réteg-nek kell arról gondoskodnia, hogy másik ARP kérést ne küldjön, míg az elozore nemérkezett válasz. Ez a funkció csak szerver/kliens módban elérheto.Példa:

// Ellenőrizzük, hogy érkezett-e válasz

if ( ARPIsResolved(&RemoteIPAddr, &RemoteMACAddr) )

{

// MAC cím megvan. Más feladat következhet...

...

}

else

{

// Még nincs meg a MAC. Várunk...

...

}

6.2. User Datagram Protocol (UDP) modul

Az UDP réteg az UDP.c fájlban van implementálva. A fejléc fájlban (UDP.h) van-nak definiálva a réteg szolgáltatásai. Ebben a Stack architektúrában az UDP egy aktív

18

réteg. Veszi az UDP csomagot és a megfelelo UDP socket-et értesíti az adat érkezé-sérol. Az UDP modul kooperatív taszkként van implementálva és automatikusanmuködik a fo alkalmazástól függetlenül.

A réteg legfeljebb 254 UDP socket-et használhat. Ez az érték csak az elérhetomemóriától és a fordítótól függ. Több socket használatával több szimultán UDPkapcsolat használható. Fontos megjegyezni, hogy minden socket körülbelül 19 bytememóriát használ (érdemes ellenorizni az UDP.h fájlt) és minden socket növeli azUDP csomagok feldolgozásának idejét.

Ellentétben a többi socket implementációtól, a Microchip TCP/IP Stack-ben min-den socket egy küldo puffert használ. Ez csökkenti a RAM szükségletet, de problémátokozhat, ha néhány socket nem szabadítja fel a küldo puffert. Ebben az esetben atávoli hosztok és/vagy helyi alkalmazások nem tudnak kapcsolatba lépni az eszköz-zel. Ennek elkerülése érdekében a felhasználónak gondoskodnia kell arról, hogy azösszes socket számára elegendoen nagy puffer álljon rendelkezésre. A vételi oldalonis csak egy puffer van, ezért ha adatot olvasunk, az összes adatot be kell olvasni egytaszkban és üríteni a puffert, hogy a többi socket is tudja olvasni az adatát. Nem lehetazt tenni, hogy a taszk csak a puffer egy részét olvassa be és majd egy következohívás esetén dolgozza fel a maradékot.

A Microchip TCP/IP Stack-ben nincs implementálva az UDP ellenorzo összegképzés. Az ellenorzo összeg helyére mindig nulla érték kerül. Ezért minden UDP-thasználó modulnak magának kell gondoskodnia az adatok integritásáról.

UDPInit

Ez a funkció inicializálja az UDP modult és elokészíti a többszálú UDP kapcso-latokra.Szintaxis: void UDPInit()Paraméter: NincsVisszatérési érték: NincsElofeltétel: NincsMellékhatás: NincsMegjegyzés: Ezt a függvényt csak egyszer kell meghívni.Példa:

// Initialize UDP

UDPInit();

...

UDPOpen

Ez a funkció elokészíti egy UDP socket-et, hogy a megadott porton adatokattudjon továbbítani.Szintaxis: UDP_SOCKET UDPOpen(UDP_PORT localPort, NODE_INFO *remoteNode,TCP_PORT remotePort)

Paraméter: localPort [bemeno] A helyi UDP port, ahonnan az adat jön.remoteNode [bemeno] A távoli hoszt, ahova az adatokat küldjük.remotePort [bemeno] A távoli hoszt egy UDP portja, ahova az adatokat küldjük.

19

Visszatérési érték: Egy érvényes socket azonosító, ha volt szabad socket vagyINVALID_UDP_SOCKET, ha nem volt szabad socket.Elofeltétel: NincsMellékhatás: NincsMegjegyzés: Ez a funkció egyszerre használható helyi ill. távoli kezdeményezésuadattovábbításra. Nincs konkrét kapcsolódási séma az UDP-ben. Ha egy UDP socket-et megnyitottak, akkor az kész az adatok küldésére és fogadására is, egészen addig,amíg be nem zárják a socket-et.Példa:

switch(smState)

{

case SM_OPEN:

// Megpróbálunk egy DHCP szerverhez kapcsolódni

DHCPSocket = UDPOpen(68, &DHCPServerNode, 67);

if ( DHCPSocket == INVALID_UDP_SOCKET )

{

// Nincs szabad socket

// Hiba kiírása

}

else

// Egy DHCP üzenet elküldése

break;

...

UDPClose

Bezártja a megadott UDP socket-et és szabadnak jelöli.Szintaxis: void UDPClose(UDP_SOCKET socket)Paraméter: socket [bemeno] A bezárandó socket azonosítója.Visszatérési érték: NincsElofeltétel: NincsMellékhatás: NincsMegjegyzés: Ezt a függvényt csak egyszer kell meghívni.Példa:

switch(smState)

{

case SM_OPEN:




{


// Hiba kiírása

}

else

20

{


...

// Socket bezárása

UDPClose (DHCPSocket);

}

break;

...

UDPIsPutReady

Ez a makró állapítja meg, hogy a megadott socket kész-e az adatok küldésére.A socket akkor kész adatküldésre, ha legalább egy MAC küldo puffer üres. Amikorezt a makrót meghívjuk, automatikusan aktív socket-té válik.Szintaxis: BOOL UDPIsPutReady(UDP_SOCKET socket)Paraméter: socket [bemeno] Az ellenorizendo socket azonosítója.Visszatérési érték: IGAZ: Ha a megadott socket kész az adatok küldésére. HAMIS:Ha nincs szabad küldo puffer.Elofeltétel: NincsMellékhatás: NincsMegjegyzés: Egy socket mindig kész az adatküldésre, amíg van üres MAC küldopuffer. Amikor ellenorizzük a socket-et, az aktívvá válik és a többi UDP funkció ismuködoképes lesz: UDPGet, UDPFlush és UDPDiscard.Példa:

...

switch(smState)

{

case SM_OPEN:




{


// Hiba kiírása

}

else

{


smState = SM_BROADCAST;

break;

}

case SM_BROADCAST:

if ( UDPIsPutReady(DHCPSocket) )

{

// A socket kész az adatküldésre...

...

21

}

break;

...

UDPPut

Az aktív socket küldo pufferébe egy bájt adatot helyez.Szintaxis: BOOL UDPPut(BYTE byte)Paraméter: byte [bemeno] Az adat, amit a küldo pufferbe akarunk tenni.Visszatérési érték: IGAZ: Ha a megadott adatot sikerült a pufferbe tölteni és mégvan hely több adatnak. HAMIS: Ha az adatot sikerült a pufferbe tölteni, de nincshely több adatnak.Elofeltétel: UDPIsPutReady == TRUEMellékhatás: NincsMegjegyzés: Ha egy socket küldésre kész, akkor összes adatot be kell töltenünkvagy addig tölthetjük fel amíg teljesen tele nem lesz a socket puffere. A felhasználónem töltheti az adat egyik felét egy socket-be a másik felét egy másik socket-be.Fontos megjegyezni, hogy amikor betöltjük az adatokat, akkor az adatok küldésenem történik meg. Kivéve akkor, ha a puffer megtelik, ekkor a funkció automatikusanelkezdi az adatok küldését és HAMIS értékkel tér vissza. A felhasználói programkésobb próbálhat adatot betölteni. Ha az elküldendo adat kevesebb, mint a küldopuffer, a felhasználói programnak kell kezdeményezni a puffer ürítését az UDPFlushfunkció hívásával. Általában, érdemes a puffert üríteni, ha egy egységnyi adatotbetöltöttünk a pufferbe, attól függetlenül, hogy a puffer még nincs tele.Példa:

...

switch(smState)

{

case SM_OPEN:




{


// Hiba kiírása

}

else

{



break;

}

case SM_BROADCAST:


{


22

// Az UDPPut közvetlenül nem kapja meg az DHCPSocket paramétert

// Az UDPPut az aktív socket-et használja,

// amit az UDPIsPutReady() állít be, ez a DHCPSocket.

UDPPut(0x55);

...

}

break;

...

UDPFlush

Az aktív socket küldo puffert küldésre késznek állítja be.Szintaxis: void UDPFlush()Paraméter: NincsVisszatérési érték: NincsElofeltétel: Az UDPPut() függvény már meg volt hívva és a socket aktív, vagyis márfuttattuk a UDPIsPutReady() függvényt.Mellékhatás: NincsMegjegyzés: Ez a funkció küldésre késznek állítja a küldo puffert, de a küldés nemindul el egybol. A felhasználónak nem kell ellenoriznie a küldési folyamat állapotát.A NIC 15-ször próbálja meg a elküldeni az adatot (legalábbis a RTL8019AS, más NICesetén a NIC adatlapjában található ez az információ). Ha a socket puffer egyszermár ürítve volt és üres, a további UDPFlush hívásokat a program figyelmen kívülhagyja.Példa:

...

switch(smState)

{

case SM_OPEN:




{


// Hiba kiírása

}

else

{



break;

}

case SM_BROADCAST:


{


23

// Az UDPPut közvetlenül nem kapja meg az DHCPSocket

// paramétert. Az UDPPut az aktív socket-et használja,

// amit az UDPIsPutReady() állít be, ez a DHCPSocket.

UDPPut(0x55);

...

// Most elküldjük

UDPFlush();

}

break;

...

UDPIsGetReady

Ez a funkció megállapítja, hogy a megadott socket tartalmaz-e vett adatokat és asocket-et aktívnak jelöli ki.Szintaxis: BOOL UDPIsGetReady(UDP_SOCKET socket)Paraméter: socket [bemeno] A socket azonosítójaVisszatérési érték: IGAZ: Ha a megadott socket tartalmaz vett adatokat. HAMIS:Ha a megadott socket nem tartalmaz vett adatokat.Elofeltétel: Az UDPOpen() függvény már meg volt hívva.Mellékhatás: NincsMegjegyzés: NincsPélda:

...

switch(smState)

{

case SM_OPEN:




{


// Hiba kiírása

}

else

// A DHCP szervertől választ várunk

smState = SM_WAIT_FOR_DATA;

break;

case SM_WAIT_FOR_DATA:

if ( UDPIsGetReady(DHCPSocket) )

{

// Adatokat olvashatók a socket-ből. Kiolvassuk és

// feldolgozzuk...

...

}

break;

24

...

UDPGet

Az aktív socket vételi pufferébol egy bájt adatot olvas ki.Szintaxis: BOOL UDPGet(BYTE *byte)Paraméter: byte [kimeno] A beolvasott adatbájt.Visszatérési érték: IGAZ: Ha sikerült egy bájtot beolvasni. HAMIS: Ha nem sikerültaz adat beolvasása.Elofeltétel: UDPIsGetReady == TRUEMellékhatás: NincsMegjegyzés: Ha a socket-ben adatok vannak, a felhasználói programnak be kellolvasnia egy vagy több bájtot egy taszk ideje alatt és a socket puffert felszabadítani.Más socket-bol adatot kiolvasni addig nem szabad, amíg az elozo puffer nem lettfelszabadítva.Példa:

...

switch(smState)

{

case SM_OPEN:




{


// Hiba kiírása

}

else



break;



{


// feldolgozzuk...

// A buffer egy BYTE mutató

while( UDPGet(buffer) )

buffer++;

// Feldolgozzuk...

...

// Socket puffer ürítése

...

}

break;

...

25

UDPDiscard

Az aktív socket vételi pufferét felszabadítja.Szintaxis: BOOL UDPDiscard()Paraméter: NincsVisszatérési érték: IGAZ: Ha a vételi puffert sikerült felszabadítani. HAMIS: Ha avételi puffer egyszer már fel lett szabadítva.Elofeltétel: NincsMellékhatás: NincsMegjegyzés: NincsPélda:

...

switch(smState)

{

case SM_OPEN:




{


// Hiba kiírása

}

else



break;



{


// feldolgozzuk...

// A buffer egy BYTE mutató

while( UDPGet(buffer) )

buffer++;

// Feldolgozzuk...

...

// Socket puffer ürítése

UDPDiscard();

}

break;

...

UDPProcess

Ez a funkció egy taszkként muködik. Egy beérkezett UDP csomagról megálla-pítja, hogy melyik UDP socket-hez tartozik. Ezt a funkciót csak akkor kell meghívni,

26

ha egy UDP csomag érkezett.Szintaxis: BOOL UDPProcess(NODE_INFO *remote, WORD len)Paraméter: remote [bemeno] A távoli eszköz adatai, ahonnan az UDP csomag érke-zettlen [bemeno] Az UDP csomag teljes hossza a fejlécet is beleszámítvaVisszatérési érték: IGAZ: Ha a taszknak sikerült teljesen feldolgoznia a megadottcsomagot. HAMIS: Ha a taszknak csak részben sikerült feldolgoznia a megadottcsomagot.Elofeltétel: IPGetHeader == TRUE és IPProtocol = IP_PRO_UDPMellékhatás: NincsMegjegyzés: Ahogy fentebb is megjegyeztük, ez a funkció valósítja meg az UDPtaszk funkciót. Akkor kell meghívni, ha egy UDP csomag érkezett ez a funkció beol-vassa és feldolgozza azt. A funkció visszatérési értéke mutatja meg a hívónak, hogya StackTask állapotjelzojét meg kell-e változtatni. Ebben a implementációban mindigIGAZ értékkel tér vissza a funkció.

További információért a Stack Manager forráskódját érdemes megnézni, ami aStackTsk.c fájlban található. Fontos észben tartani, hogy ezzel a funkcióval nemkell törodni, ha a StackTask funkciót használjuk.Példa:

...

switch(smState)

{

case SM_STACK_IDLE:

if ( MACGetHeader(&RemoveMAC, &MACFrameType) )

{

if ( MACFrameType == MAC_IP )

smState = SM_STACK_IP;

...

return;

case SM_STACK_IP:

if ( IPGetHeader(&RemoteNode, &IPFrameType, &IPDataCount) )

{

if ( IPFrameType == IP_PROT_UDP )

smState = SM_STACK_UDP;

...

return;

case SM_STACK_UDP:

if ( UDPProcess(&RemoteNode, IPDataCount) )

smState = SM_STACK_IDLE;

return;

...

27

6.3. Stack Manager modul

Ahogy már korábban is említettem, ez a Stack különbözo modulok gyujteménye.Néhány modult (mint az IP, TCP, UDP és ICMP), akkor kell meghívni, ha olyan cso-mag érkezett. Annak az alkalmazásnak, ami a Microchip TCP/IP Stack-et használja,gondoskodnia kell arról, hogy ezek a modulok megfelelo idoközönként fussanak. AStack Manager modul csak a TCP/IP Stack moduljait vezérli.

A fo alkalmazásban nem kell foglalkoznunk a különbözo modulok meghívásával,csak a StackTask nevu taszkot kell meghívnunk. Ez a modul egy külön réteg – aStackTask réteg – aminek a forrása a StackTask.c fájlban található. Amikor ez a taszkfut, megkérdezi a hálózatelérési réteget, hogy érkezett-e valamilyen csomag. Haérkezett, akkor megnézi a fejlécét és a megfelelo modulnak átadja további feldolgozáscéljából.

Mielott a Stack Manager-t munkára fognánk, meg kell hívni a StackInit() funk-ciót, ami inicializálja a modult. Ha ez megtörtént a StackTask() függvényt kellperiodikusan meghívni, hogy a beérkezo csomagokat idoben elirányítsuk és eköz-ben az ido túllépést és hibákat is kezelni tudjuk. A StackTask pontos muködésénekalgoritmusa a 6.1. ábrán látható.

6.4. A soros-UDP átalakító modul

Mivel ezt a modult írtam én, ezért részletesen leírom a belso muködését. A modulhasználatához két darab UDP socket-re van szükség.

A soros vonalon érkezo adatokat megszakítással és polling eljárással is vételez-hetjük. Természetesen érdemes a megszakítás használatát engedélyezni a ser2udp.hfájlban. A soros vonalról érkezo adatok egy alapból 50 bájtos pufferbe kerülnek. Hamegtelik vagy enter (0xA, 0xD) karakter érkezik, akkor azonnal felépítjük és elküld-jük az UDP csomagot.

A soros adatok küldésekor sajnos nem lehet megszakítást használni, mert haaz UDP csomagot megkaptuk azt fel kell dolgozni és fel kell szabadítani a puffertugyanabban a taszkban, ahol érzékeltük, hogy UDP csomag érkezett. Ha lenne ele-gendo memóriánk, akkor az adatokat átmásolva megoldható lenne a megszakításosadatküldés.

Az AppConfig struktúrájába került új változók listája a 6.2. táblázatban látható.A 6.2. táblázatban látható változók a websrvr.c fájlban az InitAppConfig függ-

vényben kapnak egy kezdeti értéket, ill. ha létezik elmentett beállítás a külso sorosEEPROM-ban, akkor az értékük onnan töltodik be. Jelenleg sem soros adatfolyam-szabályozás sem paritás ellenorzés nincs implementálva.

A 6.3. táblázatban levo belso változókat a modul függvényei használják.

Serial2UDP_Init

A modul inicializálását ez a függvény végzi el.Szintaxis: Serial2UDP_InitParaméter: NincsVisszatérési érték: Nincs

28

6.1. ábra. A Stack Manager algoritmusának folyamatábrája

29

NODE_INFO target A céleszköz adatai: IP cím és MAC cím.WORD target_port A cél port száma.WORD local_port A helyi port száma.BYTE refresh A statisztikák megtekintésekor a frissítések közötti ido

másodpercben.BYTE baud Az baud-dal arányos kiszámított érték, ami az SPBRG

változóba kerül.BYTE FlowCtrl Értéke lehet 0: nincs szabályozás, 1: szoftveres szabá-

lyozás, 2: hardveres adatfolyam szabályozás. (Jelenlegnincs használva, késobbi fejlesztéshez fenntartva.)

BYTE Parity Értéke lehet 0: nincs paritás ellenorzés, 1: páratlan pa-ritás, 2: páros paritás ellenorzés. (Jelenleg nincs hasz-nálva, késobbi fejlesztéshez fenntartva.)

6.2. táblázat. A soros-UDP átalakító modul konfigurációs változói

static UDP_SOCKET UDPSocket Az adatok továbbításához használt socket.BYTE status A modul állapotát tároló változó. További

információk a 6.4. táblázatban.DWORD rxbytes, txbytes A fogadott és elküldött oktetek száma.static WORD count A bemeneti soros pufferben elküldésre vá-

rakozó bájtok száma.static BYTE buf[BUF_SIZE] A bemeneti soros puffer. Alapesetben 64

bájt méretu.static BYTE buf_end Az adatok száma a soros pufferben.static BYTE_VAL misc Egyes bitjei más-más jelentéssel bírnak. A 0.

bit: A SendSerialData függvény legköze-lebbi futásakor megpróbáljuk-e elküldeniaz adatokat.

6.3. táblázat. A soros-UDP átalakító modul belso változói

Elofeltétel: NincsMellékhatás: A modul inicializálása legalább 4 másodpercig (INITWAIT_SEC) tart.Megjegyzés: Eloször vár 4 másodpercet. Ennyi ido elég, hogy feléledjen a NIC ésérzékelje, hogy a kapcsolat él. (A késobbiekben érdemes lenne kódot átírni úgy,hogy a NIC interfészén keresztül kérdezze le, hogy él-e a kapcsolat.) Utána elküldegy ARP kérés csomagot, hogy megtudja a cél IP címhez tartozó MAC címet. Mégnégy másodpercig vár (TIMEOUT_SEC) utána „Hiba: MAC cím lekérdezése közbenidotúllépés történt” hibaállapotba lép. Ha sikerült a MAC lekérdezése megpróbálegy UDP socket-et megnyitni. Ennek sikertelensége esetén „Hiba: Nincs szabad UDPsocket”, ellenkezo esetben „Rendben” állapotba kerül. A függvényt csak egyszer kellmeghívni.Példa:

...

Serial2UDP_Init ();

30

...

Serial2UDP_GetSerialData

Beolvassa a soros vonalról jövo adatot és elhelyezi a buf pufferben, ha lehetséges.Ha a puffer megtelt vagy soremelés (0xD), kocsi vissza (0xA) karakter érkezett, akkora flush vátozót igaz értékre állítja. Ha a soros vonali adatok vételénél keret hibatörtént a modul „Hiba: RS-232 keret hiba” állapotba kerül. Ha az adatok vételekora vételi puffer felülírása következett be, akkor a „Hiba: Az RS-232 puffer felülírás”állapot áll be. A függvény folyamatábrája a 6.2. ábrán látható. Az ábrán a szaggatottvonal akkor érvényes, ha ezt a függvényt a Serial2UDP függvény hívja meg és nemmegszakítással muködik.Szintaxis: void Serial2UDP_GetSerialData ()Paraméter: NincsVisszatérési érték: NincsElofeltétel: NincsMellékhatás: NincsMegjegyzés: Megszakításos módban és a pollingolásnál is ez a függvény muködik.Pollingnál a Serial2UDP függvény hívja meg ezt a függvényt.Példa: Nincs

Serial2UDP_SendSerialData

Ha a buf puffer tele van (a flush bit 1 értéku), akkor elkészít egy UDP csomagotés elküldi a beállított IP címnek.Szintaxis: void Serial2UDP_SendSerialData ()Paraméter: NincsVisszatérési érték: NincsElofeltétel: NincsMellékhatás: NincsMegjegyzés: A Serial2UDP függvény hívja meg ezt a függvényt.Példa: Nincs

Serial2UDP_ProcessUDPData

A fogadott UDP csomagot azonnal elküldi a soros vonalon keresztül. Folyama-tábrája a 6.3. ábrán látható.Szintaxis: void Serial2UDP_ProcessUDPData ()Paraméter: NincsVisszatérési érték: NincsElofeltétel: NincsMellékhatás: NincsMegjegyzés: A Serial2UDP függvény hívja meg ezt a függvényt.Példa: Nincs

31

6.2. ábra. A Serial2UDP_GetSerialData függvény folyamatábrája

Serial2UDP

Ez egy kooperatív taszk, amit a fo ciklusban kell meghívni.Szintaxis: void Serial2UDP ()Paraméter: NincsVisszatérési érték: NincsElofeltétel: Inicializálás megtörtént.Mellékhatás: NincsMegjegyzés: A soros vonalon beérkezo adatokat a buf pufferben tárolja aSerial2UDP_GetSerialData () függvény segítségével (csak polling módszernél).

32

6.3. ábra. A Serial2UDP_ProcessUDPData függvény folyamatábrája

A SendSerialData () eljárással küldi el a buf pufferben tárolt adatokat a sorosvonalon és a ProcessUDPData () függvénnyel a megadott portra érkezo UDP cso-magokat egybol kiírja a soros vonalra.Példa:

...

StackTask();

HTTPServer();

Serial2UDP();

...

Serial2UDP_ReInit

A konfiguráció megváltozásakor kell meghívni.Szintaxis: void Serial2UDP_ReInit ()Paraméter: NincsVisszatérési érték: Nincs

33

Elofeltétel: NincsMellékhatás: NincsMegjegyzés: Szinte teljesen megegyezik az Serial2UDP_Init funkcióval, de az ARPkérés kiküldése elott nincs 4 másodperces várakozás.Példa:

Serial2UDP_GetStatusString

A modul állapotára vonatkozó stringre mutató mutatót ad vissza.Szintaxis: char *Serial2UDP_GetStatusString (void)Paraméter: NincsVisszatérési érték: Egy sztring mutató, ami megegyezik aSerial2UDP_StatusString változóban levo értékkel.Elofeltétel: NincsMellékhatás: NincsMegjegyzés: A sztring HTML kódokat tartalmaz, 0 kódú karakterrel van lezárvaés a programmemóriában van. A lehetséges állapotok szövegei a 6.4. táblázatbanláthatók.

Sorszám Angolul Magyarul0 Unknown Ismeretlen1 Ok Rendben2 Error: UDP socket not available Hiba: Nincs szabad UDP socket3 Error: Can’t resolve MAC add-

ress, time outHiba: MAC cím lekérdezése köz-ben idotúllépés történt

4 Error: Buffer is full Hiba: A puffer tele van5 Error: RS-232 Framing error Hiba: RS-232 keret hiba6 Error: RS-232 Overrun error Hiba: RS-232 puffer felülírás

6.4. táblázat. A soros-UDP modul átalakító állapotai

Példa:

...

WORD HTTPGetVar(BYTE var, WORD ref, BYTE* val)

{

switch(var)

{

case VAR_DEVSTATUS:

if (ref == HTTP_START_OF_VAR)

{

Serial2UDP_GetStatusString ();

ref = (BYTE)0;

}

*val = Serial2UDP_StatusString[(BYTE)ref];

if (Serial2UDP_StatusString[(BYTE)ref + 1] == ’\0’)

return HTTP_END_OF_VAR;

34

(BYTE)ref++;

return ref;

...

6.5. HTTP szerver modul

Ez a HTTP szerver kooperatív taszkként fut, amit a fo alkalmazásból kell meg-hívni. A szerver a HTTP.c forrásfájlban van implementálva és a felhasználói pro-gramban két segédrutint (angolul callback function) használhatunk. Az bemutatóalkalmazás forrásfájlját – a websrvr.c fájlt – használtam fel a saját programomírásához. Ez a HTTP szerver egy csökkentett tudású program, direkt beágyazottrendszerekhez íródott. A szerver tulajdonságai:

• Többszálú HTTP kapcsolatok

• Egy egyszeru fájlrendszert támogat (MPFS)

• A honlapokat a belso programmemóriában és külso EEPROM-ban is tárolhat-juk

• Tartalmaz egy PC-s programot MPFS képfájl létrehozásához

• A HTTP GET metódust támogatja (más metódusok könnyen hozzáadhatók)

• Egy módosított Common Gateway Interface-t (CGI) támogat

• Dinamikusan generálható a honlapok tartalma.

A HTTP szerver használatbavételéhez a következo lépéseket kell végrehajtani:

1. A StackTsk.h fájlban vagy a projekt beállításnál definiálni kell aSTACK_USE_HTTP_SERVER definíciót.

2. A StackTsk.h fájlban be kell állítani a MAX_HTTP_CONNECTIONS értékét.

3. A http.c és mpfs.c fájlokat hozzá kell adni a projekthez.

4. Attól függoen, hogy hol szeretnénk a weblapokat tárolni, definiálni kell azMPFS_USE_PGRM vagy az MPFS_USE_EEPROM kulcsszavakat. Ha külso EEPROM-ot használunk tárolóelemnek az xeeprom.c fájlt is hozzá kell adni a projekthez.

5. A main() függvényt módosítani kell, hogy a HTTP szerver muködjön.

Az összes weblapot egy MPFS (Microchip File System) fájlrendszerbe kell kon-vertálni. Ha az MPFS képfájlt külso EEPROM-ban tároljuk, akkor a felhasználóiprogramba implementálni kell az adatok rögzítéséhez szükséges függvényt.

A HTTP szerver alap honlapként az index.htm fájlt használja. Ha például egyböngészo a HTTP szerverhez fordul úgy hogy csak az IP címet adták meg a bön-gészonek az index.htm fájlt kapja meg a böngészo. Tehát minden MPFS képfájlbanlennie kell egy index.htm fájlnak. Ha szükséges az alap fájlnév megváltoztatható,ha a http.c forrásban a HTTP_DEFAULT_FILE_STRING definíciót átírjuk. Fontos, hogya weblap fájlok nevei ne tartalmazzák a következo karaktereket:

35

• aposztróf és idézojel (’ és ")

• kisebb-nagyobb jelek (< és >)

• kettos kereszt jel (#)

• százalék jel (%)

• szögletes és kapcsos zárójelek ([, }, [, {)

• szuro jel (|)

• vissza perjel (\)

• kalap jel

Ha egy fájl neve tartalmaz ezek közül egy karaktert, akkor az a honlap nem leszelérheto. A HTTP szerveren van egy lista a támogatott fájl típusokkal. Ezt az in-formációt a böngészo használja fel; ebbol állapítja meg, hogy hogyan értelmezzea kapott adatokat. A fájlok azonosítása a hárombetus kiterjesztés alapján történik.Alapból a HTTP szerver a következo fájltípusokat támogatja: .txt, .htm, .gif,.cgi, .jpg, .cla, .wav. Ha egy alkalmazásban olyan fájltípust akarunk hasz-nálni, ami nincs a listában, akkor a http.c fájlban httpFiles táblázatot kell módo-sítani utána a httpContents felsorolást. Az ismert fájltípusok listáját a stíluslapoktípussal bovítettem (.css).

6.5.1. Dinamikus honlap generálás

A HTTP szerver dinamikusan meg tudja változtatni a honlapok tartalmát. A CGI(.cgi kiterjesztésu legyen) fájlokban a %xx kulcsszó helyére tetszoleges adat helyet-tesítheto. A % jel egy vezérlo karakter. Az xx egy kétjegyu azonosító, hexadecimálisformában. Ügyeljünk arra, hogy az A-F karakterek nagy betuvel legyenek írva! Így256 féle változót használhatunk. Ha % jelet szeretnénk kiírni, írjunk egymás után kétszázalék jelet: %%.

Az eredeti Microchip megoldásban nem teljes értéku hexadecimális számok vol-tak megadhatók. A % jel után két darab decimális számot kellett írni, amit a pro-gramban hexadecimális számként kellet feldolgozni. Így 00-99 változó megadásalehetséges. Én írtam egy egyszeru konvertert, ami a hexadecimális stringet átalakítjaegy bájttá. Így 00-tól FF-ig adhatók meg az azonosítók.

HTTPGetVar

Ez a funkció egy segédfüggvény (callback function) a HTTP-hez. Ha HTTP szer-ver egy %xx szöveget talál egy CGI lapon, akkor meghívja ezt a funkciót. Ezt afunkciót a felhasználói programban kell megírni és különbözo változó adatokat tu-dunk vele továbbítani.Szintaxis: WORD HTTPGetVar(BYTE var, WORD ref, BYTE *val)Paraméter: var [bemeno] A változó azonosítója, aminek az állapotát akarjuk lekér-dezni.

36

ref [bemeno] Ez az érték jelzi, hogy ha ez az elso függvényhívás. Ekkor a változóértéke HTTP_START_OF_VAR. Ez elso hívás után már ez a változó a felhasználói alkal-mazásé. Egyszerre csak egy bájt átvitele lehetséges. Ez a változó teszi lehetové, hogytöbb bájt átvitele esetén a HTTP szerver nyomon kövesse az adatok átvitelét úgy,hogy ebben a változóban az átvitt adat indexét kell tenni és visszatéréskor is ezt aváltozót kell átadni. Az utolsó bájt átvitelekor HTTP_END_OF_VAR értéket kell vissza-térési értéknek megadni. A HTTP szerver egészen addig meghívja ezt a funkciót,amíg nem kap egy HTTP_END_OF_VAR értéket.val [kimeno] Egy bájt adat, amit küldeni szeretnénk.Visszatérési érték: A ref változó új értéke, amit a felhasználói alkalmazás állapítmeg. Ha HTTP_END_OF_VAR értéket ad vissza, legközelebb csak akkor hívódik meg,ha megint szükség van a változó értékére.Elofeltétel: NincsMellékhatás: NincsMegjegyzés: Ez a függvény egy változót kér a felhasználói alkalmazástól, de annaknem feltétlenül kell értékeket adni. Az hogy milyen információt ad át a függvény, aza hozzárendelt weblaptól függ.Példa: A soros-UDP átalakítóhoz készítettem a stats.cgi fájlt, ebben a következoolvasható:

<tr><td>Device status</td><td>%01</td></tr>

Amikor a HTTP szerver a fájl feldolgozása során a %01 szöveghez ér, meghívja akövetkezo funkciót: HTTPGetVar(1, HTTP_START_OF_VAR, &value). A felhasználóialkalmazásban levo websrvr.c fájlban van ez a funkció és ehhez hasonlóan néz ki:

WORD HTTPGetVar(BYTE var, WORD ref, BYTE* val)

{

switch(var)

{

...

case VAR_RXBYTES:

if (ref == HTTP_START_OF_VAR)

{

ltoa (rxbytes, TmpString);

ref = (BYTE)0;

}

*val = TmpString[(BYTE)ref];

if (TmpString[(BYTE)ref + 1] == ’\0’)

return HTTP_END_OF_VAR;

(BYTE)ref++;

return ref;

...

6.5.2. HTTP CGI

A CGI-nek egy módosított verziója használható ebben az implementációban.Ezzel az interfésszel a HTTP kliens egy funkciót tud meghívni a felhasználói alkal-

37

mazásban a HTML GET módszerével. További információk az RFC1866-os doku-mentumban [5] találhatók.

A HTTP szerver nem dekódolja az átadott URL-t. Ez azt jelenti, hogy ha az átadotturlapok mezoje speciális karaktereket tartalmaz (<, >, %, ékezetes karakterek, stb.),akkor a funkciónak átadott paraméter %xx formátumú sztringeket fog tartalmazni,ahol a xx az ASCII karakter hexadecimális kódja. Az urlapokat tartalmazó oldalakat.cgi kiterjesztéssel kell ellátni.

Fontos észben tartani, hogy amikor jelszavakat továbbítunk CGI segítségével, ajelszavakat kódolatlanul továbbítjuk, tehát azok „lehallgathatók”.

HTTPExecCmd

Ez egy segédfüggvény (callback function). Ha a HTTP szerver a GET módszerreltörténo lekérdezésnél több mint egy paramétert kap, akkor hívja meg ezt a funkciót.Ezt a funkciót a felhasználói alkalmazásnak kell tartalmaznia.Szintaxis: void HTTPExecCmd(BYTE **argv, BYTE argc)Paraméter: argv [bemeno] Ez egy sztring tömb. Az elso sztring (argv[0]) az urlapaction mezojének tartalma, a többi (argv[1..n]) a paraméterek.argc [bemeno] A paraméterek száma, beleszámítva az action mezot is.Visszatérési érték: A felhasználói alkalmazásnak be kell állítania az argv[0] válto-zót egy érvényes honlapnévre, ami a visszatérési eredményt tartalmazza.Elofeltétel: NincsMellékhatás: NincsMegjegyzés: Ezt a függvényt a HTTP szerver hívja meg. A felhasználói alkalma-zásnak ki kell tudnia szolgálnia az egymás utáni hívásokat. Alapesetben az argu-mentumok száma maximum 5 és az argumantumsztringek hossza legfeljebb 80lehet. Ha egy alkalmazásnak ennél több argumentum vagy hosszabb sztring kell,a MAX_HTTP_ARGS vagy a MAX_HTML_CMD_LEN definíciót kell megváltoztatni. Ezek ahttp.c fájlban találhatók.Példa: A setup.cgi fájlt is a soros-UDP átalakítóhoz készítettem. Ebben olvashatóa következo:

<form action="setup.cgi" method="get">

<table border=0>

<tr><td>Local IP</td>

<td><input type="text" name="0" value="%0C"></td></tr>

<tr><td>Local Port</td>

<td><input type="text" name="1" value="%0D"></td></tr>

<tr><td>Netmask</td>

<td><input type="text" name="2" value="%0E"></td></tr>

<tr><td>Gateway</td>

<td><input type="text" name="3" value="%0F"></td></tr>

<tr><td>Target IP</td>

<td><input type="text" name="4" value="%09"></td></tr>

<tr><td>Target Port</td>

<td><input type="text" name="5" value="%0A"></td></tr>

<tr><td>Refresh rate</td>

38

<td><input type="text" name="6" value="%06"></td>

<td>sec</td></tr>

<tr><td><input type="submit" name="7" value="Save"></td></tr>

</table>

</form>

Ennek a táblázatnak a második oszlopaiban adhatunk meg különféle szöveg for-mátumú adatokat. A képernyon látható kép a 6.4. ábrán van. Az utolsó sorban egygomb látható „Save” felirattal. Ha rákattintunk erre a gombra, akkor az urlapot a„GET” módszerrel elküldi a böngészo.

6.4. ábra. Urlapok kezelése

A HTTP kérés ez lesz: setup.cgi?0=10.10.5.15&1=2221&2=255.255.255.0&3=10.10.5.15&4=10.10.5.5&5=2222&6=5&7=SaveEnnek hatására HTTP szerver pe-dig a következo paraméterekkel meghívja a HTTPExecCmd függvényt:argc = 17 argv[0] = "setup.cgi"

argv[1] = "0" argv[2] = "10.10.5.15"

argv[3] = "1" argv[4] = "2221"

argv[5] = "2" argv[6] = "255.255.255.0"

argv[7] = "3" argv[8] = "10.10.5.15"

argv[9] = "4" argv[10] = "10.10.5.5"

argv[11] = "5" argv[12] = "2222"

argv[13] = "6" argv[14] = "5"

argv[15] = "7" argv[16] = "Save"

Ehhez természetesen MAX_HTTP_ARGS és a MAX_HTML_CMD_LEN értékét is meg kellnövelni. Az adatokat feldolgozó függvény pedig így néz ki:

void HTTPExecCmd(BYTE** argv, BYTE argc)

{

BYTE i;

BYTE var;

for (i = 1; i < argc; i += 2)

{

switch(argv[i][0] - ’0’)

{

case CGI_CMD_LOCALIP:

StringToIPAddress (argv[i + 1], &AppConfig.MyIPAddr);

39

break;

case CGI_CMD_LOCALPORT:

AppConfig.local_port = atoi (argv[i + 1]);

break;

...

case CGI_CMD_BUTTON:

// Ez a parameter adodik at utolsonak...

Serial2UDP_ReInit ();

SaveAppConfig ();

break;

}

...

}

Az egy karakterbol álló azonosítók használata leegyszerusíti a program kódját, ezértérdemes alkalmazni.

6.6. Microchip fájlrendszer (MPFS)

A HTTP szerver egy egyszeru fájlrendszert használ a honlapok tárolására. Afájlrendszer képe a mikrovezérlo memóriájában és egy külso soros EEPROM-ban istárolható. A fájlrendszer formátuma a 6.5. ábrán látható.

6.5. ábra. MPFS képfájl felépítése

A fenntartott terület mérete az MPFS_RESERVE_BLOCK definícióban van megadva.A fenntartott területet a felhasználói alkalmazás használhatja a konfigurációs értékektárolására. Egy MPFS tároló egy vagy több MPFS FAT (Fájl Elhelyezkedési Tábla,File Allocation Table) bejegyzést tartalmaz, amit egy vagy több adatblokk követ. AFAT bejegyzés határozza meg a fájl nevét, pozícióját a memóriában és a fájl állapotát.A FAT bejegyzés formátuma a 6.6. ábrán van.

40

Az állapotjelzo mutatja meg, hogy a bejegyzés használatban van, törölve van ill.a FAT végét is jelezheti. Minden FAT bejegyzés tartalmaz egy 16 vagy 24 bites címet.A cím hossza a felhasznált memória típusától függ.

Ha a belso programmemóriát használjuk „kis” (small) memóriamodellel, akkor16 bites címeket fog használni. Ha a belso programmemóriát használjuk viszont„nagy” (large) memóriamodellel, akkor 24 bites címeket fog használni. A külsoEEPROM eszközöknél mindig 16 bites címzési módszert használunk, függetlenül amemóriamodelltol.

Ebben a fájlrendszerben a fájlnevek 8+3 bájt hosszúak. A fájl neve 8 bájtos és akiterjesztés további 3 bájt hosszúságú. A 16 bites cím megadja az elso adatblokkot.Minden fájlnév nagybetukkel szerepel a könnyebb névkezelés érdekében.

Az adatblokk formátuma a 6.7. ábrán szerepel. A blokk végét egy speciális karak-ter jelzi; az EOF (End Of File), amit 0xFFFF (16 bites címzésnél) vagy 0xFFFFFF (24bites címzésnél) követ. Ha a fájl tartalmazza az EOF karaktert, akkor egy DLE (DataLink Escape) karakterrel jelezzük, hogy ez a fájl része. Ha a DLE karakter szerepelaz adatblokkban, akkor két DLE karakter jelzi, hogy az a fájl része.

6.6.1. MPFS kép készítése

A csomag része egy PC-s program (MPFS.exe), amivel MPFS képfájlokat hozha-tunk létre. A program képes bináris és C nyelvu adatok létrehozására is.

Az MPFS.exe használata: mpfs [/?] [/c] [/b] [/r<blokk>] [bemenet]

[kimenet], ahol

• /? hatására segítséget ír ki,

• /c paraméter segítségével C kódot kérhetünk,

• /b paraméterrel bináris kódot készít (ez az alapbeállítás),

• /r paraméterrel megadhatjuk hány bájtot szeretnénk fenntartani saját haszná-latra, (ez csak bináris módban muködik, alap: 32 bájt),

• bemenet a bemeno adatokat tartalmazó könyvtár,

6.6. ábra. MPFS FAT bejegyzés felépítése

6.7. ábra. MPFS adatblokk felépítése

41

• kimenet az MPFS képet tartalmazó fájl.

Például: mpfs /c Honlap honlap.c Így egy C fájlt kapunk benne a Honlapkönyvtárban lévo fájlok adatai. Bináris fájlt kapunk az mpfs Honlap honlap.binparancs hatására. A bináris fájl elején 32 bájt fenntartott. Ha megváltoztatjuk a fenn-tartott terület méretét ne felejtsük el a StackTsk.h fájlban a MPFS_RESERVE_BLOCKdefiníciót megváltoztatni.

Mielott a képfájlt létrehozzuk az összes honlapot egy könyvtárba kell másolni.Ha egy fájl kiterjesztése .htm, akkor a program az összes kocsi vissza, új sor karakterttörli, hogy csökkentse a képfájl méretét. Ha az MPFS képfájlt C adatként használjuk,akkor a projektünkhöz hozzá kell adni a C fájlt. Ha a képfájlt külso soros EEPROM-ban tároljuk, a bináris fájlt fel kell tölteni a memóriába. További információ a 41.oldalon az „FTP szerver modul” résznél.

Az MPFS képkészíto program nem ellenorzi az elkészült fájl méretét. Bináris adatkészítése esetén ellenorizni kell az adat méretét.

6.6.2. MPFS könyvtár

Az MPFS fájlrendszer eléréséhez szükséges könyvtár az MPFS.c fájlban van imp-lementálva. Az MPFS könyvtárat a HTTP és az FTP szerver használja a felhasználóialkalmazástól függetlenül. Az MPFS könyvtár jelenlegi verziójával nem lehet egy lé-tezo fájlrendszerhez új fájlokat adni ill. törölni. Bármilyen változás esetén egy újabbképfájlt kell létrehozni.

Ha a belso programmemóriát használjuk a tárolásra, az MPFS_USE_PGRM szót defi-niálni kell. Ha viszont külso EEPROM-ot használunk, a MPFS_USE_EEPROM kulcsszótkell definiálni. Egyszerre csak egyik definíció szerepelhet a StackTsk.h fájlban; en-nek ellenorzésére a futásido alatt egy ellenorzokód fut le.

A memória típusától függoen különbözo lappuffer méretet kell beállítani. Az alapméret (amit az MPFS_WRITE_PAGE_SIZE határoz meg) 64 bájt. Ha más pufferméretrevan szükség az MPFS_WRITE_PAGE_SIZE definíciót kell megváltoztatni.

Az MPFS könyvtárnak ez a verziója az xeeprom.c fájlt használja a külso EEPROMeléréséhez. Miközben egy fájlt olvas vagy ír kizárólagosan az MPFS irányítja az I2Cbuszt és nem engedélyezi más I2C eszközöknek – legyen az szolga vagy mester– a hozzáférést. Ha több I2C eszközt használunk, akkor a felhasználói alkalmazásírásakor ezt figyelembe kell venni.

6.7. FTP szerver modul

Ez a modul is egy kooperatív taszkként funkcionál és az FTP.c fájlban van aszerver forráskódja. Ez az FTP szerver nem tudja az összes szolgáltatást, ami az RFC 959-ben [6] le van leírva, mivel direkt beágyazott rendszerekhez lett tervezve, minimálisa mérete és a tudása. A modul jellemzoi:

• Egy szálú FTP kapcsolat. A felhasználó azonosítása az alkalmazás feladata,

• Automatikusan kezeli az MPFS fájlrendszert,

42

• A „PUT” paranccsal egy új MPFS kép töltheto fel,

• A fájlok egyenkénti feltöltése nem lehetséges.

A modul két részbol áll: maga az FTP szerver és a felhasználó azonosító függvény,ami a felhasználói alkalmazásnak kell tartalmaznia. Egy FTPVerify függvényt kellírnia a felhasználónak, ami ellenorzi az FTP felhasználót és a jelszót.

Itt is megjegyzem, hogy a jelszót kódolatlanul küldi el a számítógép, tehát azoka megfelelo eszközökkel „lehallgathatók”.

Az FTP szerver használatához a következoket kell megtettünk:

1. A STACK_USE_FTP_SERVER-t definiálni kell. A komment jelet el kell távolítani aStackTsk.h fájlban a definíció elol.

2. A definiált socket-ek számát növelni kell kettovel ugyancsak a StackTsk.hfájlban.

3. Az FTP.c és az mpfs.c fájlokat hozzá kell adni a projektünkhöz.

4. Vagy az MPFS_USE_PGRM MPFS_USE_EEPROM definíciót be kell állítani, attólfüggoen, hogy milyen tárolóelemet használunk. Ha külso EEPROM-ot, azxeeprom.c fájlt is adjuk hozzá a projektünkhöz.

5. Módosítsuk a main() függvényt, hogy az FTP szerver inicializáló függvényeés taszkja fusson.

Az FTP szerver 180 másodperc után jelez idotúllépést feltöltésnél és letöltésnélegyaránt. Ha egy kapcsolat 180 másodpercnél tovább van „IDLE” (tétlen) állapotban,akkor automatikusan megszakítja a szerver a kapcsolatot. Így a bennragadt klienseknem gátolhatják meg a további FTP muveleteket.

6.7.1. MPFS kép feltöltése FTP kliens segítségével

Az FTP szerver fo feladata ebben a Stack-ben, hogy távolról lehessen frissíteniaz MPFS képfájlt. A jelenlegi verzió csak akkor muködik, ha külso EEPROM-othasználunk adattárolásra.

Egy képfájl feltöltése látható a 6.8. ábrán. A vastagon szedett betuk a felhasználóáltal beírt adatokat jelzi. A jelszó természetesen nem látszódik a képernyon.

FTPVerify

Ez egy segédfüggvény (callback function), amit az FTP szerver akkor hív meg,ha kérést vesz a kapcsolat felépítésére. Ezt a funkciót a felhasználói alkalmazásnakkell tartalmaznia.Szintaxis: BOOL FTPVerify(char *login, char *password)Paraméter: login [bemeno] Egy sztring, ami tartalmazza a felhasználó nevét.password [bemeno] Sztring, ami a jelszót tartalmazza.Visszatérési érték: IGAZ: Ha a felhasználói név és a jelszó érvényes. HAMIS: Havagy a felhasználó neve, vagy a jelszó érvénytelen.

43

c:\> ftp 10.10.5.15

220 ready

User (10.10.5.15: (none)): ftp

331 Password required

Password: microchip

230 Logged in

ftp> put mpfsimg.bin

200 ok

150 Transferring data...

226 Transfer Complete

16212 bytes transferred in 0.01Seconds 16212000.00Kbytes/sec.

ftp> quit

221 Bye

6.8. ábra. MPFS képfájl feltöltése FTP kliens segítségével

Elofeltétel: NincsMellékhatás: NincsMegjegyzés: A felhasználónév hossza nullától kilencig változhat. Ha hosszabb fel-használónévre van szükség az FTP_USER_NAME_LEN definíciót kell megváltoztatni azftp.h fájlban.

A jelszó és az FTP utasítások hossza legfeljebb 31 karakter hosszú lehet. Hahosszabb jelszó és/vagy parancs szükséges, akkor a MAX_FTP_CMD_STRING_LEN defi-níciót kell megváltoztatni az FTP.c fájlban.Példa:

ROM char FTP_USER_NAME[] = "ftp";

#define FTP_USER_NAME_LEN (sizeof(FTP_USER_NAME)-1)

ROM char FTP_USER_PASS[] = "microchip";

#define FTP_USER_PASS_LEN (sizeof(FTP_USER_PASS)-1)

BOOL FTPVerify(char *login, char *password)

{

if ( !memcmppgm2ram(login, (ROM void*)FTP_USER_NAME,

FTP_USER_NAME_LEN) )

{

if ( !memcmppgm2ram(password, (ROM void*)FTP_USER_PASS,

FTP_USER_PASS_LEN) )

return TRUE;

}

return FALSE;

}

44

7. fejezet

Hardver

A „PIConNET” kártya kapcsolási rajzát és a nyomtatott áramkört a ChipCadKft. készítette. A kapcsolási rajz az 1. számú mellékleten látható. A rajzon látható93LC46B típusú soros EEPROM nem lett beforrasztva.

A kártyához készítettem egy soros vonali illesztot és egy egyszeru tápfeszült-ségstabilizátort, ami a 7.1. ábrán látható. A soros vonal illesztését egy MAX232Atípusú integrált áramkör valósítja meg. A rajzon MAX232 IC szerepel, a két IC kö-zött annyi a különbség, hogy a MAX232 mellé 1 µF-os kondenzátorokat kell tenni,míg a MAX232A megelégszik 100 nF-os kondenzátorokkal. A tápfeszültség stabili-zálását pedig egy 78L05 IC végzi el.

7.1. Alkatrészek

7.1.1. PIC18F452 mikrovezérlo

Ez egy FLASH programmemóriával rendelkezo RISC mikrokontroller10 MIPS tel-jesítményre képes és maximum 40 MHz-en muködhet. 32 kilobájt FLASH építettekbe a programmemóriának, 1536 bájt RAM és 256 bájt EEPROM van benne. Utasítás-készlete 75 utasításból áll és úgy optimalizálták, hogy a C programnyelven történofejlesztést megkönnyítse. 31 szintu verem van beépítve, ami ha szükséges szoftvere-sen bovítheto. A nyomtatott áramköri lapon felhasznált TQFP tok rajza a 7.2. ábránlátható. Az IC részletes leírása az angol nyelvu adatlapon [7] van.

Perifériák jellemzoi:

• A lábak áramleadása vagy -felvétele 25 mA lehet.

• Három külso megszakítást generáló láb áll rendelkezésre.

• Timer0 modul: 8 bit ill. 16 bites idozíto/számláló 8 bites programozható eloosz-tóval.

• Timer1 modul: 16 bites idozíto/számláló.

• Timer2 modul: 8 bites idozíto/számláló 8 bites periódus regiszterrel (idoalap aPWM-hez).

45

7.1. ábra. Soros vonali illeszto és tápfeszültség stabilizátor kapcsolási rajza

46

7.2. ábra. A PIC18F452 típusú mikrovezérlo lábkiosztása

• Timer3 modul: 16 bites idozíto/számláló.

• Opcionális másodlagos oszcillátor Timer1-es és Timer3-as modulokhoz.

• Két Capture/Compare/PWM modul. A modul háromféleképpen konfigurál-ható:

– Capture (mintavételezo) bemenetként (16 bites, maximum felbontás6, 25ns = TCY/16),

– Compare (összehasonlító) bemenetként (16 bites, maximum felbontás100ns = TCY),

– PWM kimenetként (felbontás 1 bittol 10 bitig változtatható, 8 bites felbon-tásnál fmax = 156kHz, 10 bites felbontásnál fmax = 39kHz).

• Szinkron soros port (Master Synchronous Serial Port, MSSP) modul. Hárommódban muködhet:

– 3 vezetékes SPI módban (mind a négyfajta SPI módban muködik),

– I2C mester módban,

– I2C szolga módban.

47

– Címezheto USART modul. RS-232 és RS-485 módot is támogatja.– Párhuzamos szolga port (PSP).

Analóg paraméterek:

• 10 bites AD konverter jellemzoi:

– Gyors mintavételezo képesség,– Muködik szundi (SLEEP) módban,– Linearitás ≤ 1 Lsb.

• Programozható feszültségesés jelzés (Programmable Low Voltage Detection,PLVD): megszakítás kérheto, ha leesik a feszültség.

• Tápfeszültség-kiesés esetén beállítható reset folyamat (Brown-out Reset, BOR).

Speciális jellemzok:

• Tipikusan százezerszer törölheto/írható a FLASH programmemória.

• Tipikusan egy milliószor törölheto/írható az adat EEPROM.

• A FLASH és az adat EEPROM legalább 40 évig megtartja tartalmát.

• A szoftverbol lehet írni/olvasni a programmemóriát.

• Fejlett beépített reset áramkör: Power-on Reset (POR), Power-up Timer(PWRT), Oscillator Start-up Timer (OST).

• Watchdog idozíto (WDT) saját RC oszcillátorral.

• Programozható kódvédelem.

• Tápegységkímélo szundi (SLEEP) mód.

• Változtatható oszcillátorbeállítások:

– az elsodleges oszcillátor négyszerezése (PLL használatával),– másodlagos órajel engedélyezése/tiltása.

• Soros programozás két lábon keresztül (In-Circuit Serial Programming, ICSP).

• Nyomkövetés két lábon keresztül (In-Circuit Debugging, ICD).

CMOS technológia elonyei:

• Alacsony teljesítményu, nagy sebességu FLASH/EEPROM technológia

• Széles tápfeszültség-tartomány (2.0–5.5V)

• Ipari- és kiterjesztett homérsékleti tartományok

• Alacsony teljesítményigény:

– kisebb, mint 1,6 mA, ha 5V a tápfeszültség és 4 MHz a frekvencia– 25 µA, ha 3V a tápfeszültség és 32 kHz a frekvencia– kisebb, mint 0,2 µA szundi üzemmódban

48

7.1.2. RTL8019AS ethernet vezérlo

Ez az IC valósítja meg a fizikai kapcsolatot az ethernet hálózattal. A régebbi ver-ziójú RTL8019-et továbbfejlesztették és 16 kilobájt SRAM-ot építettek be egy tokba.Full-duplex-es és 10 Mbit/s sebesség érheto el. Csavart érpáros (10baseT) és koaxiáliskábellel (10base5, 10base2) is használható, továbbá a már igen elavult AUI csatlako-zást is használhatunk. A PIConNET kártyán egy RJ45-ös csatlakozó lett kialakítva acsavart érpáros kapcsolathoz, továbbá van négy LED, amely a kapcsolat létrejöttétill. a hálózati forgalmat jelzi. További információ az IC adatlapján [8] található.

Ez az integrált áramkör a beépített SRAM-ot pufferként felhasználva ethernetkereteket küld ill. fogad manchester kódolással és kezeli az ütközéseket. Az OSI/ISOmodellben gyakorlatilag a fizikai- és adatkapcsolati réteget valósítja meg.

7.1.3. 24LC256 típusú soros EEPROM

Ebben a memóriában 32 kilobájt méretu EEPROM található és I2C buszon keresz-tül kommunikál a mikrokontrollerrel. Egy speciális formátumba csomagolva FTP-nkeresztül tölthetjük fel honlapunkat a memóriába, továbbá ebben az EEPROM-bantároljuk az alkalmazás beállításait. További információ az angol nyelvu adatlapon[11] van. A 7.3. ábrán látható a tok lábkiosztása.

A tok jellemzoi a következok:

• Kis fogyasztású CMOS technológiával készül:

– Az íráskor felvett áram 3 mA 5.5V-os tápfeszültségnél.

– Az olvasáskor felvett áram maximum 400 µA 5.5V-os tápfeszültségnél.

– Nyugalmi áram átlagosan 100 nA 5.5V-os tápfeszültségnél.

• Két vezetékes I2C kompatibilis soros busz.

• Kaszkádba kötheto maximum 8 eszköz.

• Belso idozítésu írási- és olvasási ciklusok.

• 64 bájt méretu lapok írása támogatott.

• Maximális írási ido 5 ms.

• Hardveres írás védelem.

• Schmitt Trigger-es bemenetek.

• Egymillió törlés/írás ciklus.

• Minimum 4 kV-os elektrosztatikus kisülés ellen védett.

• Adatmegtartási ido legalább 200 év.

• 8 érintkezos PDIP, SOIC, TSSOP, MSOP, DFN és 14 érintkezos TSSOP tokkal isgyártják.

49

7.3. ábra. A 24LC256 típusú soros EEPROM lábkiosztása

7.1.4. MAX232A soros vonali illeszto

A soros vonal illesztését végzi ez az integrált áramkör (lábkiosztása a a 7.4. ábránlátható). Az 5V-os TTL szintu jeleket ±12V-os szintre alakítja, ehhez négy darab100 nF-os kondenzátorra van szükség. Két darab bemenetet és két darab kimenetetkezel, ebbol csak egyet-egyet használtam fel. Az IC részletes leírása az adatlapján[10] olvasható.

7.4. ábra. A MAX232 típusú soros vonali illeszto lábkiosztása

50

8. fejezet

Az eszköz használata és tesztelése

8.1. Az eszköz használata

A kész eszközön három csatlakozó és öt LED található(8.1. ábra).

8.1. ábra. A doboz oldal- és elölnézete

Jelmagyarázat:

1. Soros vonal: egy DSUB9-es csatlakozó található a dobozon. Ezen keresztültörténik az RS-232 szabvány szerinti kommunikáció.

2. Ethernet: egy RJ45-ös foglalat van a csavart érpáros kábelnek.

3. Tápfeszültség: a protokollkonverternek 5-15V egyenfeszültségre van szüksége.

4. Link LED (sárga): Ha világít, a kapcsolat létrejött a két ethernet-es készülékközött.

5. RX LED (zöld): Ha villog, adatok érkeznek az ethernet hálózaton az eszközfelé.

6. TX LED (zöld): Ha villog, az eszköz adatokat küld az ethernet hálózaton.

7. OK LED (zöld): Ha világít, akkor az eszköz megfeleloen muködik.

8. ERROR LED (piros): Ha világít, akkor az eszköz muködése során hiba lépettfel.

51

Az eszköz használata a 8.2. ábrán látható. Az ethernet hálózat kialakítására szám-talan lehetoség van: lehet csak csavart érpáros technológiát használni vagy csavartérpáros kábeleket és optikai vagy mikrohullámú átvitelt is. Az áthidalható távolságakár több kilométer is lehet.

8.2. ábra. Az eszköz használata

8.2. Konfigurálás böngészoprogrammal

Az eszköz konfigurálását bármilyen böngészoprogrammal elvégezhetjük. Ala-pesetben az eszköz IP címe 10.10.5.15 hálózati maszkja 255.255.0.0. A http://10.10.5.15címet beírva a böngészobe a 8.3. ábrán látható képet kell látnunk. A „Help” linkrekattintva ennek a fejezetnek a kivonatos verzióját olvashatjuk el.

Az egyes linkekre kattintva beállíthatjuk a soros vonalat, a hálózatot ill. megte-kinthetjük a statisztikákat.

8.2.1. Hálózat beállítása

A „Network setup” linkre kattintva a 8.4. ábrán látható oldalon a következoketállíthatjuk be:

• Local IP: az eszköz IP címe (alap: 10.10.5.15).

• Local Port: az eszköz ezen a porton várja az adatokat (alap: 2221).

• Netmask: hálózati maszk (alap: 255.255.0.0).

• Gateway: ha a cél IP címe másik tartományba esik meg kell adni az átjárót (alap:10.10.5.15). Ha ugyanabban a hálózatban van, akkor az átjáró megegyezik azeszköz IP címével.

• Target IP: a soros vonalról érkezo adatokat ennek az IP címnek fogja továbbítani(alap: 10.10.5.5).

• Target Port: a soros vonalról érkezo adatokat a megadott portra küldi (alap:2222).

52

8.3. ábra. Konfigurálás böngészoprogrammal: index

8.4. ábra. Hálózat beállítása böngészoprogrammal

53

• Refresh rate: A statisztika megtekintésekor ennyi másodpercenként fog fris-sülni a lap (alap: 10).

A „Save” gombra kattintva az adatokat eltárolja a I2C buszos EEPROM-ba és azeszköz lekérdezi a megadott cél IP cím MAC címét.

8.2.2. Soros vonal beállítása

A „Serial port setup” oldalon (8.5. ábra) a soros vonal sebességét lehet beállítani.A sebesség 2400-tól 57600 baud-ig állítható. A „Save” gombra kattintva a beállításazonnal érvényes lesz és az értéket elmenti az EEPROM-ba.

8.5. ábra. Soros vonal beállítása böngészoprogrammal

8.2.3. Statisztika

A statisztikákat tartalmazó oldalon (a 8.6. ábra) láthatjuk az eszköz állapotát(rendben van ill. valamilyen hiba történt), a beállított paramétereket és az eddigátvitt adatok számát bájtban. Ez a HTML oldal automatikusan frissül alapesetben 10másodpercenként. Ez frissítési érték (Refresh rate) a hálózati beállításokat tartalmazólapon átállítható tetszoleges értékre.

54

8.6. ábra. Statisztika megtekintése böngészoprogrammal

8.3. Az eszköz tesztelése

Mivel csak egy eszközt készült el, ezért a teszteléshez számítógépen egy program-mal (UDP test) szimuláltam a másik eszközt és egy egyszeru terminálprogrammalküldtem és fogadtam a soros vonali adatokat. A 8.7. ábrán látható az eszköz és aszámítógép összekötése.

8.7. ábra. Az eszköz tesztelése

Az UDP test (8.8. ábra) nevu programot C++ nyelven írtam direkt azért, hogya készüléket tesztelni tudjam. A program egy fo ablakból áll, ami két részre vanosztva.

55

8.8. ábra. Az UDP test program

A bal oldalon található egy UDP kliens: a megadott IP címre és annak megadottportjára elküldi a szövegdobozban található szöveget.

A jobb oldalon az UDP szerver vezérelhetjük, ami a program futtatásakor au-tomatikusan elindul. A szerver megadott portjára érkezo adatokat a program egyszövegdobozban jeleníti meg.

A program muködését egyszeruen ki lehet próbálni: a szerver címének a loopbackeszköz címét kell megadni (például 127.0.0.1). Majd a kliensnek is ezt a címet és aszerver portját adjuk meg. Ha az elküld gombra kattintunk az üzenetnek meg kelljelennie a jobb oldali szövegdobozban.

56

Irodalomjegyzék

[1] Nilesh Rajbharti. The Microchip TCP/IP Stack, 2002.Fájl: tcpipstack/an833.pdf

[2] J. Postel. User Datagram Protocol, RFC 768, 1980.Fájl: rfc/rfc768.txt.pdf

[3] T. Bradley, C. Brown, A. Malis. Inverse Address Resolution Protocol, RFC 2390,1998.Fájl: rfc/rfc2390.txt.pdf

[4] David C. Plummer. An Ethernet Address Resolution Protocol – or – ConvertingNetwork Protocol Addresses to 48.bit Ethernet Address for Transmission on EthernetHardware, RFC 826, 1982.Fájl: rfc/rfc826.txt.pdf

[5] T. Berners-Lee. Hypertext Markup Language - 2.0, RFC 1866, 1995.Fájl: rfc/rfc1866.txt.pdf

[6] J. Postel, J. Reynolds. File Transfer Protocol, RFC 959, 1985.Fájl: rfc/rfc959.txt.pdf

[7] Microchip. PIC18FXX2 Data Sheet, DS39564B, 2002.Fájl: adatlapok/pic18fxx2/pic18fxx2.pdf

[8] Realtek. RTL8019AS, Realtek Full-Duplex Ethernet Controller with Plug and PlayFunction, Ver 2.0, 1996.Fájl: adatlapok/realtek/rtl8019asds.pdf

[9] Realtek. RTL8019 Realtek Full-Duplex Ethernet Controller with Plug and Play Func-tion, LS003.6, 1995.Fájl: adatlapok/realtek/rtl8019.pdf

[10] Maxim. MAXIM +5V-Powered, Multichannel RS-232 Drivers/Receivers, 19-4323;Rev 11; 2003.Fájl: adatlapok/MAX220-MAX249.pdf

[11] Microchip. 24LC256, DS21203K, 2003.Fájl: adatlapok/24lc256.pdf

a microchip tcp ip stack implementációjának alkalmazása a

Documents